Re: Python versions for Ubuntu 10.10 (Maverick Meerkat)
[Barry Warsaw, 2010-05-28]
> On May 23, 2010, at 03:58 PM, Piotr Ożarowski wrote:
> >[Barry Warsaw, 2010-05-22]
> >[¹] f.e. changes in API, absolute imports in 2.7 would be one of those,
> > right now I don't see such changes in 2.7, but I didn't play much
> > with it yet
>
> Contrary to what PEP 328 implies, absolute imports are *not* the default in
> Python 2.7. Default import semantics will only change in Python 3.
That's why I wrote "right now I don't see such changes in 2.7" ;-P
[...]
> >[³] without seeing the bigger picture (i.e. not being a long term
> > maintainer for given package), it's really easy to make a mistake,
> > even if a package builds fine on all architectures, passes all tests
> > (with 100% test coverage), is lintian and piuparts clean, module imports
> > fine, works fine... you still can end with bugs like LP:418280 (and I
> > can easily imagine breaking lots of other packages by such bugs).
> > Note that I assume Ubuntu maintainer *did* check all these things
> > before uploading.
>
> Of course, that tells me that there's a bigger problem here. :) IIUC, you're
> saying the Ubuntu maintainer probably did all the right things and yet stuff
> was still broken.
I'm saying in both cases maintainer did something that worked in package
A but is completely broken in package B (although it doesn't FTBFS).
> If that's the case, then it seems like there's no other way
> to find these breakages short of just trying to make the transition happen and
> waiting for bug reports.
... or you can hit maintainer with a clue bat ;-)
> LP #418280 does seem like a process bug: a package that previously was
> unbundled got added to the stdlib, making the separate package obsolete.
> The one I can think of for Python 2.7 would be argparse.
now imagine what will happen if foo module in stdlib and in external
package has different API (due to different implementation or simply
different version), example: json module
[...]
> What do we need to do to make Python 2.7 supported in experimental?
technically? update python-defaults package. Right now we shouldn't do
it as experimental is the only place where we can test packages with 2.6
set as default. Once 2.6 will be default in unstable, 2.7 can be added to
supported in experimental.
[...]
> >> >* how many of them will work on huge changes that packages need in order
> >> > to work with PEP3147?
> >>
> >> I don't know. What exactly needs to change?
> >
> >f.e. helper tools are not ready for it; we didn't agree how to share .py
> >files on hard disk yet; some packages started adding 3.x support in the
> >binary package which provides 2.X module (and it looks like python3
> >maintainer wants to separate them)... is that enough for a start? (I'm
> >afraid the list will be much longer)
>
> It's a good start, but I would really like to start enumerating these in a
> place that isn't as volatile as an email thread. Can you suggest a good place
> on the Debian wiki to do this? If not, I will make a place for it on
> wiki.python.org or wiki.ubuntu.com.
how about http://wiki.debian.org/Python3 ?
[...]
> Upstream certainly tries not to cause backward incompatibility between point
> releases, but as you know, developing software is a dirty, ugly, inexact
> business. :)
I know. That's the reason why I think packages should be updated by
people who use them.
[...]
> So what broke for you in 2.6.4 -> 2.6.5?
fix (don't worry, not "fix" ;) in codecs module (issue #691291)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: