increasing the python requirement (was Re: [rfc] upgrade pqm chroot to lucid)
Martin Pool
> version is used by which OS (at least which one is used on Babune or to
> build the installers, mentioning available 2.x version between parens):
>
> osx 10.5: 2.5 (2.6)
>
> osx 10.6: 2.6
> windows: 2.6
> freebsd: 2.6
> gentoo: 2.6
> hardy: 2.5 (2.4)
> jaunty: 2.6 (2.5, 2.4 probably but not installed on babune)
> karmic: 2.6 (2.5, 2.4)
> lucid: 2.6 (2.5)
> maverick: 2.6 (2.7 status unclear, I had to uninstall it)
> natty: err, no, not under babune yet[1] ;)
>
> > I'm not sure about the 2.3 series, but I would be perfectly fine if
> > bzr2.4+ was only restricted to python2.5/(2.6?) compatibility, and we
> > stopped worrying about python2.4.
>
> Indeed. I think we should decide on this before starting 2.4 so we can
> announce that 2.3 will be the last stable version to support 2.4 (2.5?
> 2.6 ?!?!).
>
> Given the overview above, and considering 2.3 will be released in
> February 2011, I wonder if we can drop 2.5 support (as well as 2.4)
> since hardy is becoming the last remaining platform requiring it.
>
> I don't think we can jump to 3.x but that's still something we should
> think about.
If it's true, and it seems to be true, that every platform important
to our developers is on at least python 2.5, perhaps it's useful to
drop the python 2.4 requirement from the moment we branch off bzr 2.4
in about February 2011. (Unfortunate coincidence of numbers.)
According to <http://sivang.blogspot.com/2009/11/setting-up-python26-on-ubuntu-804-lts.html>
python2.6 is in a PPA for Hardy if you really need it.
From memory 2.6 has relatively more relevant new features we'd like to
use than 2.5 does, so there is an incentive to bump our requirement
all the way to 2.6.
Before deciding when to go to 3.0 I'd like to take a spike on actually
doing the conversion, or getting bzr going under 2to3, so that we have
a better measure of how buggy or hard it's going to be.
--
Martin
Aaron Bentley
Hash: SHA1
On 11-01-04 05:33 AM, Martin Pool wrote:
> From memory 2.6 has relatively more relevant new features we'd like to
> use than 2.5 does, so there is an incentive to bump our requirement
> all the way to 2.6.
I've found context managers and the 'with' statement, (available via
__future__ in 2.5), are really significant in day-to-day programming.
Managing scopes via try/finally has always been a pain.
But don't let me stop you going to 2.6
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jM+gACgkQ0F+nu1YWqI3J7gCgiO8fregSRdkQT7jx/HlnELzY
MQkAnifF3PIACGIRdPJlO4e/sYdEFMUf
=So4R
-----END PGP SIGNATURE-----
Max Bowsher [via Archive Software & Mailing List Agustinus Rustantio]
> On 11-01-04 05:33 AM, Martin Pool wrote:
>> From memory 2.6 has relatively more relevant new features we'd like to
>> use than 2.5 does, so there is an incentive to bump our requirement
>> all the way to 2.6.
>
> I've found context managers and the 'with' statement, (available via
> __future__ in 2.5), are really significant in day-to-day programming.
> Managing scopes via try/finally has always been a pain.
>
> But don't let me stop you going to 2.6
etch (oldstable).
Granted, they're pretty old, but there's no doubt a large installed base
of such systems still.
I think we could probably get away with de-supporting them now, but we
should only do it if we have a really really good reason.
Max.
signature.asc (205 bytes) To unsubscribe from Archive Software & Mailing List Agustinus Rustantio, click here.
John Arbash Meinel
Hash: SHA1
On 1/4/2011 9:20 AM, Max Bowsher wrote:
> On 04/01/11 14:51, Aaron Bentley wrote:
>> On 11-01-04 05:33 AM, Martin Pool wrote:
>>> From memory 2.6 has relatively more relevant new features we'd like to
>>> use than 2.5 does, so there is an incentive to bump our requirement
>>> all the way to 2.6.
>>
>> I've found context managers and the 'with' statement, (available via
>> __future__ in 2.5), are really significant in day-to-day programming.
>> Managing scopes via try/finally has always been a pain.
>>
>> But don't let me stop you going to 2.6
>
> Going all the way to 2.6 would be de-supporting Ubunty hardy and Debian
> etch (oldstable).
>
> Granted, they're pretty old, but there's no doubt a large installed base
> of such systems still.
>
> I think we could probably get away with de-supporting them now, but we
> should only do it if we have a really really good reason.
>
> Max.
>
Note that it isn't like we are completely leaving them out in the cold.
We'll still be doing bzr 2.3 minor updates for quite a while
(6-18months). Given that we are EoLife-ing bzr 2.0, which IIRC is what
those platforms came with by default.
It seems reasonable that when we stop supporting the original version,
we can stop supporting the python version (it is old enough now, etc.)
Just a thought.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jR/QACgkQJdeBCYSNAAMXtgCg0i5djDvS0YzKg55bjiUApXH2
34QAnA5HY8zK7LDYs50Xi8A54GkIM6k3
=XZHa
-----END PGP SIGNATURE-----
Jelmer Vernooij
> On 1/4/2011 9:20 AM, Max Bowsher wrote:
> > On 04/01/11 14:51, Aaron Bentley wrote:
> >> On 11-01-04 05:33 AM, Martin Pool wrote:
> >>> From memory 2.6 has relatively more relevant new features we'd like to
> >>> use than 2.5 does, so there is an incentive to bump our requirement
> >>> all the way to 2.6.
> >>
> >> I've found context managers and the 'with' statement, (available via
> >> __future__ in 2.5), are really significant in day-to-day programming.
> >> Managing scopes via try/finally has always been a pain.
> >>
> >> But don't let me stop you going to 2.6
> >
> > Going all the way to 2.6 would be de-supporting Ubunty hardy and Debian
> > etch (oldstable).
> >
> > Granted, they're pretty old, but there's no doubt a large installed base
> > of such systems still.
> >
> > I think we could probably get away with de-supporting them now, but we
> > should only do it if we have a really really good reason.
> We'll still be doing bzr 2.3 minor updates for quite a while
> (6-18months). Given that we are EoLife-ing bzr 2.0, which IIRC is what
> those platforms came with by default.
>
> It seems reasonable that when we stop supporting the original version,
> we can stop supporting the python version (it is old enough now, etc.)
>
> Just a thought.
etch will hopefully be oldoldstable by the time bzr 2.4 is released.
Debian lenny (current stable) only has Python 2.5, so it'd be great if
bzr 2.4 could at least still support Python 2.5.
RHEL 6 has also just been released. Hopefully it will be in much wider
use by the time Bazaar 2.4 is released (RHEL 5 has python 2.4).
If bzr 2.4 introduced any format changes then not supporting Python 2.4
would be a much bigger deal IMO, because users would have to upgrade to
2.4 to interact with repositories in the newer format.
Cheers,
Jelmer
Vincent Ladeuil
> If bzr 2.4 introduced any format changes then not supporting Python 2.4
> would be a much bigger deal IMO, because users would have to upgrade to
> 2.4 to interact with repositories in the newer format.
Not anymore since you mentioned it :)
Iff we introduced a new format, we'll also have to support it for
python-2.4 [1]
We have plenty of time to discuss with the users involved. This includes
mentioning that interoperability inside a project is based on the format
used[2]. Add a smooth upgrade operation (still need work) and people have
plenty of time to migrate.
Even if we have to do such focused backports, I think the corresponding
effort is still worth the benefits of having to support only 2 different
versions of python instead of 4.
By reducing to 2.6/2.7 we also narrow the gap with python-3.x which
should make the transition easier.
Vincent
[1] So nice that python and bzr versions collide here :-/
[2] Obligatory Config reference:
1) Define a default format in project.conf
2) Deploy (each time a pull/update is made...)
....
4) Profit !
Anteru
> should make the transition easier.
As an occasional bug fixer and bzr user; I'd be more than happy to see
Bzr to move to Python 2.6 or even 3. The reason is that I typically run
a (more or less recent) 2.x installation for mucking around with various
libraries (2.6 on all Linux installations I use, and 2.7 on Windows) and
the latest stable 3.x for new development.
I haven't run into an issue where something I wanted to contribute to
Bzr got refused because it doesn't work with Python 2.3 or so, but for
me at least it would be much easier if I wouldn't have to worry about
those versions. Sure, I know there are people running RHEL 4 still and
are stuck with ancient Python installations by default -- but how
complicated is it to get a newer Python running side-by-side with the
old one? At least on Windows and Ubuntu, it's pretty easy to have Python
2.x and 3.x installed (on Windows, the Python version shouldn't matter
anyway as it's bundled with the Bzr installer.)
There's definitely nice stuff in 2.6 and 3.x in particular; and in the
future, the LLVM backend for 3.x might allow Bzr to gain quite a bit of
speed with no additional development effort.
Just my two cents,
Cheers,
Anteru
Ben Finney
> etch will hopefully be oldoldstable by the time bzr 2.4 is released.
For those not familiar with Debian's support policy, a release older
than “oldstable” means it has fallen off the train altogether and is not
receiving any updates from the Debian project.
So yes, hopefully Bazaar 2.4 will come after the release of Debian
Squeeze, which will push Debian Etch off the back and mean that its
users will then be knowingly using an unsupported release.
> Debian lenny (current stable) only has Python 2.5, so it'd be great if
> bzr 2.4 could at least still support Python 2.5.
+1.
--
\ “Men never do evil so completely and cheerfully as when they do |
`\ it from religious conviction.” —Blaise Pascal (1623–1662), |
_o__) Pensées, #894. |
Ben Finney
Toshio Kuratomi
> >>>>> Jelmer Vernooij <jel...@vernstok.nl> writes:
>
> > If bzr 2.4 introduced any format changes then not supporting Python 2.4
> > would be a much bigger deal IMO, because users would have to upgrade to
> > 2.4 to interact with repositories in the newer format.
>
> Not anymore since you mentioned it :)
>
> Iff we introduced a new format, we'll also have to support it for
> python-2.4 [1]
>
> We have plenty of time to discuss with the users involved. This includes
> mentioning that interoperability inside a project is based on the format
> used[2]. Add a smooth upgrade operation (still need work) and people have
> plenty of time to migrate.
>
> Even if we have to do such focused backports, I think the corresponding
> effort is still worth the benefits of having to support only 2 different
> versions of python instead of 4.
>
python-2.4 that strikes a great balance as far as I'm concerned.
I still have to keep bzr running on RHEL5 for people who use it there until
RHEL5 EOLs and the big thing is *not* performance optimizations, new
software that targets new APIs, and such... end users understand that those
types of things may require a newer version of python/bzr. It really is just --
"I'm running RHEL5 and I need to interoperate with the repository format on
launchpad to checkout the latest version of gwibber" or "I'm running bzr
smart server on a RHEL5 server and a few of the clients pushing repos get
errors because they default to the new format."
-Toshio
Barry Warsaw
>There's definitely nice stuff in 2.6 and 3.x in particular; and in the
>future, the LLVM backend for 3.x might allow Bzr to gain quite a bit of
>speed with no additional development effort.
Sadly, I think the Unladen Swallow is an ex-parrot, er defunct project.
-Barry
John Arbash Meinel
Hash: SHA1
...
>> Not anymore since you mentioned it :)
>>
>> Iff we introduced a new format, we'll also have to support it for
>> python-2.4 [1]
>>
>> We have plenty of time to discuss with the users involved. This includes
>> mentioning that interoperability inside a project is based on the format
>> used[2]. Add a smooth upgrade operation (still need work) and people have
>> plenty of time to migrate.
>>
>> Even if we have to do such focused backports, I think the corresponding
>> effort is still worth the benefits of having to support only 2 different
>> versions of python instead of 4.
One thing to consider, is if there is a new repo format, to provide it
as a plugin to bzr <=2.3.
>>
> If you do backports of new formats to the version of bzr that supports
> python-2.4 that strikes a great balance as far as I'm concerned.
>
> I still have to keep bzr running on RHEL5 for people who use it there until
> RHEL5 EOLs and the big thing is *not* performance optimizations, new
> software that targets new APIs, and such... end users understand that those
> types of things may require a newer version of python/bzr. It really is just --
> "I'm running RHEL5 and I need to interoperate with the repository format on
> launchpad to checkout the latest version of gwibber" or "I'm running bzr
> smart server on a RHEL5 server and a few of the clients pushing repos get
> errors because they default to the new format."
>
> -Toshio
There are no immediate plans to implement a new format. But it is
certainly something that we would be unlikely to backport into an old
stable release.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jl5oACgkQJdeBCYSNAAOZ9ACgir5vm8yjOAClsx41JNRPHoJm
FoUAn3k8Pgk2wIl9oCR42QQ4DKvqAaVN
=8wPb
-----END PGP SIGNATURE-----
John Arbash Meinel
Hash: SHA1
On 1/4/2011 12:33 PM, Vincent Ladeuil wrote:
>>>>>> Jelmer Vernooij <jel...@vernstok.nl> writes:
>
> > If bzr 2.4 introduced any format changes then not supporting Python 2.4
> > would be a much bigger deal IMO, because users would have to upgrade to
> > 2.4 to interact with repositories in the newer format.
>
> Not anymore since you mentioned it :)
>
> Iff we introduced a new format, we'll also have to support it for
> python-2.4 [1]
>
> We have plenty of time to discuss with the users involved. This includes
> mentioning that interoperability inside a project is based on the format
> used[2]. Add a smooth upgrade operation (still need work) and people have
> plenty of time to migrate.
>
> Even if we have to do such focused backports, I think the corresponding
> effort is still worth the benefits of having to support only 2 different
> versions of python instead of 4.
>
> By reducing to 2.6/2.7 we also narrow the gap with python-3.x which
> should make the transition easier.
>
> Vincent
- From what I've seen if you restrict it to 2.6/2.7 then it is *possible*
to support 3.x in the same code base (without running 2to3). I think it
used one of the compat libs that let you from "compat" import to_bytes,
and then you wrap all your constants in to_bytes('foo'). Then again,
with extensions and everything else, I would be pretty surprised if we
ever got that to work. And it would potentially make for pretty ugly code.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jmIMACgkQJdeBCYSNAANK2QCguIK0Z9iLd1xpLWfl9lFp48OE
18YAnA2WSGcNJfeQSQsV/VZdoNqU6dp2
=6lJ9
-----END PGP SIGNATURE-----
Toshio Kuratomi
> >> Even if we have to do such focused backports, I think the corresponding
> >> effort is still worth the benefits of having to support only 2 different
> >> versions of python instead of 4.
>
> One thing to consider, is if there is a new repo format, to provide it
> as a plugin to bzr <=2.3.
>
> >>
> > If you do backports of new formats to the version of bzr that supports
> > python-2.4 that strikes a great balance as far as I'm concerned.
> >
> > I still have to keep bzr running on RHEL5 for people who use it there until
> > RHEL5 EOLs and the big thing is *not* performance optimizations, new
> > software that targets new APIs, and such... end users understand that those
> > types of things may require a newer version of python/bzr. It really is just --
> > "I'm running RHEL5 and I need to interoperate with the repository format on
> > launchpad to checkout the latest version of gwibber" or "I'm running bzr
> > smart server on a RHEL5 server and a few of the clients pushing repos get
> > errors because they default to the new format."
> >
> > -Toshio
>
> There are no immediate plans to implement a new format. But it is
> certainly something that we would be unlikely to backport into an old
> stable release.
>
proposing?
-Toshio
John Arbash Meinel
Hash: SHA1
On 1/4/2011 4:53 PM, Toshio Kuratomi wrote:
...
>> There are no immediate plans to implement a new format. But it is
>> certainly something that we would be unlikely to backport into an old
>> stable release.
>>
> A plugin would be fine (as long as it works ;-). Is that what you're
> proposing?
>
> -Toshio
I'm saying that if we do introduce a new format, and have discontinued
python2.4 compatibility, it shouldn't be hard to write a plugin for
older bzr to interoperate with newer ones.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jpSUACgkQJdeBCYSNAAN4LACgvgjeEEWvW1AiyZkYNG7nigZj
PKYAnipz9MhkbV+OyodEzRDkLTqolkdH
=vcs1
-----END PGP SIGNATURE-----
Toshio Kuratomi
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/4/2011 4:53 PM, Toshio Kuratomi wrote:
> ...
>
> >> There are no immediate plans to implement a new format. But it is
> >> certainly something that we would be unlikely to backport into an old
> >> stable release.
> >>
> > A plugin would be fine (as long as it works ;-). Is that what you're
> > proposing?
> >
> > -Toshio
>
> I'm saying that if we do introduce a new format, and have discontinued
> python2.4 compatibility, it shouldn't be hard to write a plugin for
> older bzr to interoperate with newer ones.
>
developers) to create a plugin so we should plan on doing that rather than
support the entire codebase on older python" or "it would be easy for some
interested party to create a plugin if they choose to"?
I ask because well... I'll be able to move the servers I care about to RHEL6
(and python-2.6) so I probably won't scratch that itch. But I know that
I'll get bug reports asking why the bzr on RHEL5 doesn't work with launchpad
and I hate closing bugs as CANTFIX.
Thanks,
-Toshio "who feels bad asking if someone else plans to do work on some piece
of free software but knows he lacks the time to meet even his current free
software commitments :-("
Martin Pool
>>>>>> Jelmer Vernooij <jel...@vernstok.nl> writes:
>
> > If bzr 2.4 introduced any format changes then not supporting Python 2.4
> > would be a much bigger deal IMO, because users would have to upgrade to
> > 2.4 to interact with repositories in the newer format.
That's a very good point.
> Not anymore since you mentioned it :)
>
> Iff we introduced a new format, we'll also have to support it for
> python-2.4 [1]
We could adopt that rule, though it's not one we've had to date.
In the case of 2a, we did quite a lot of internal restructuring so
that bzr could take advantage of operations that were fast in the new
format. If we do a new major format (as opposed to just adding some
minor options) then that would be quite a large patch to backport.
Taking such a large patch into a stable series seems to me to run a
real risk of breaking plugins or introducing new bugs, which are
things we really want to avoid in the stable series. We could split
off a new "2.2 with format 3a support" branch, but that has a cost
too.
Alternatively we could try to add "slow but safe" support for the new
format to the old series, in a way that doesn't change APIs and that
changes the code as little as possible, but this
It's possible that would seem like an unacceptable amount of churn for
people who are running say 2.2 and who want to get only safe bug
fixes.
We could also do a kind of backport along a different vector by taking
say bzr 2.5.0 and undoing any python>2.4 specific work.
Any of these seem like a high price to pay if the benefit is just
getting to use some nicer python2.5/2.6 source constructs.
--
Martin
Gordon Tyler
Hash: SHA1
On 1/4/2011 6:44 PM, Martin Pool wrote:
> Any of these seem like a high price to pay if the benefit is just
> getting to use some nicer python2.5/2.6 source constructs.
There's also improvements/bugfixes in newer python runtimes/VMs to be
considered.
Ciao,
Gordon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNI7MOAAoJEIrPJfWinA2ugUMH/3Va2ezSG5LJ3vofdDiSaz9w
ajywu3nprKx6KUHU6YNk/Cn6NmAIDo7ibOooj++tpDyasji8+u92fMY4cxGm/y7k
S2TxgQVsvQLxjz4hoVSSiFG/eTI6BefzilKSWylA6xvpkMnYOKg+LDrsgC0lvL+E
3E4y7Erus8hrOZgZgCr/KtyskCvMC4ptS80bV9nLQLNy869gyB3LkX57cqe9cKa8
KMKWvfRVcDvh9CRIQ74xQf9PY9i8UJFdyOUZgH0LgsXePtyLgFJKI/0C8JiFgil5
hxz1LP6alDomfB1ldnPj3Z0s8ZvkZTxsvW8jnBkCtYC/QUQSX2l8sqO42JTw+Ek=
=Mqjv
-----END PGP SIGNATURE-----
Martin Pool
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/4/2011 6:44 PM, Martin Pool wrote:
>> Any of these seem like a high price to pay if the benefit is just
>> getting to use some nicer python2.5/2.6 source constructs.
>
> There's also improvements/bugfixes in newer python runtimes/VMs to be
> considered.
Right, but most of them will be obtained by just building against the
latest available Python for any particular platform, which we normally
already do.
Some of them require calling new APIs, which again we already normally
do, conditionally on the API being available.
I don't think there are any bug fixes from 2.x we could only obtain by
dropping support for older Pythons.
I suppose improvement that are only in Python 3.x do fit here, but
that's a somewhat separate discussion: "when should we support 3.x?",
and then only secondarily "will dropping 2.4/5 help us support 3.x"?
It seems like it will help a bit but it's not the main thing.
Let's suppose someone came up with a branch that cleanly supported 2.6
and 3.x, and they said they found it impossibly hard to also support
2.4 from the same codebase. Quite possibly this would be faster on
3.x than we are at the moment on 2.x. Eventually we'll support 3.x.
Will we do it as soon as bzr2.4, if it means no more support for
python 2.5? I think it could be a reasonable tradeoff.
On the other hand, when we come to try that work it might turn out
that it's hard to support both 2.6 and 3.x, or on the other hand that
supporting 2.5 is no harder than supporting 2.6. I've seen anecdotes
supporting any of these positions so I think the only thing is to
actually try it in bzr.
It seems like Ubuntu may go to python3 in early 2012, at which time
some people will still be using RHEL5 on Python2.4. So we may not be
able to avoid the dilemma.
--
Martin
Toshio Kuratomi
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/4/2011 6:44 PM, Martin Pool wrote:
> > Any of these seem like a high price to pay if the benefit is just
> > getting to use some nicer python2.5/2.6 source constructs.
>
> There's also improvements/bugfixes in newer python runtimes/VMs to be
> considered.
>
affect the code you write. Example:
python-2.5+ is more efficient with garbage collecting that python-2.4. But
you don't have to change your code to take advantage of python-2.5's
improvements -- you just have to run it on python-2.5 instead of python-2.4.
Those are things that matter to the people putting together distributions
that bzr runs on and might also be something to include in the documentation
about bzr (ie: "While bzr will run on python-2.4, running it on python-2.7
will result in increased speed and less memory consumed") but don't come
with the same upfront decision thatincorporating source constructs like the
"with" statement has.
Andrew Bennetts
> On 1/4/2011 6:44 PM, Martin Pool wrote:
> > Any of these seem like a high price to pay if the benefit is just
> > getting to use some nicer python2.5/2.6 source constructs.
>
> There's also improvements/bugfixes in newer python runtimes/VMs to be
> considered.
I know of some performance improvements in the VM, but we get those
simply by running under CPython 2.6. No effort (aside from supporting
2.6, which we already do) from us is necessary.
What sort of bug fixes do you have in mind? There are some bugs in the
standard library that we have to work around, and having one less major
version of the standard library to deal with would ease that burden a
little. e.g. the recent fix for HTTPS under Python 2.7 would probably
have been easier and cleaner if we didn't need to support 2.4. I don't
think that is a particularly large cost though.
It's interesting to grep for “python2.4” and “[Pp]ython 2.4” in our
source. It finds a fair few scattered workarounds for various issues,
but we wouldn't gain much now from deleting them.
The main thing I'm tempted by is context managers, but given that
bzrlib.cleanup provides an adequate alternative that works under 2.4
even that's not so important.
I agree with Martin that these benefits don't seem to outweigh the
enormous costs of backporting significant changes to a 2.4 compatible
version.
-Andrew.
Gordon Tyler
Hash: SHA1
On 1/4/2011 7:24 PM, Toshio Kuratomi wrote:
> On Tue, Jan 04, 2011 at 06:53:50PM -0500, Gordon Tyler wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 1/4/2011 6:44 PM, Martin Pool wrote:
>>> Any of these seem like a high price to pay if the benefit is just
>>> getting to use some nicer python2.5/2.6 source constructs.
>>
>> There's also improvements/bugfixes in newer python runtimes/VMs to be
>> considered.
>>
> If I'm understanding what you're saying, most improvements to the VMs don't
> affect the code you write. Example:
>
> python-2.5+ is more efficient with garbage collecting that python-2.4. But
> you don't have to change your code to take advantage of python-2.5's
> improvements -- you just have to run it on python-2.5 instead of python-2.4.
True. I was forgetting that you could just run code written for
python-2.4 under python-2.6 and gain the benefits of the new runtime.
Ciao,
Gordon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNI7zyAAoJEIrPJfWinA2usqkH/jWO0pDzEgVC2SrNAJ2d3VjQ
RfYTPO89pE43ahxUunrl+npBpfyV70UPwNrXoa4Vvc/QjNK2hwfMQfUJqOm9Faso
7I4I11rQ38e5gUw/Vy2jSoo04IKKr93kYtHkIVgbmPMm6wczzHmOG1S2dJL9HDDu
Vve9Aq/Xej5fQOjA15At0LOuDVegAdpEuVJZkotYXwXmRveFjfjLsCmhHTZikubN
tO+yPGwJn54Pl0WtzxrynAOvx0/+WUbn3oI1nynYCLU6DYhYD1CJ3XMvYfbK0TpX
x2Zp3jtw6LuuIaK2l/xji3tTA5CfOfUmkuFoiUxSuafKoU7xtAvBBv96rvDjNvU=
=6a2Z
-----END PGP SIGNATURE-----
Martin Pool
> Alternatively we could try to add "slow but safe" support for the new
> format to the old series, in a way that doesn't change APIs and that
> changes the code as little as possible, but this
.... is a bit like writing the format over again a second time. Or
perhaps the core storage objects (that were previously not referenced)
could use the same code as in trunk, but you would need different glue
to connect them to the Repository format, etc. Because you would be
writing a fair bit of new code specifically to adapt the new format to
the old structure, there may be bugs in that code that aren't caught
by testing trunk and again that's something we want to avoid in stable
series.
Of course it depends quite a lot on just what changes are introduced
by the new format.
I think, if you were going to deploy this, it might make sense to put
the new format into a plugin that works with the old format, which
would have no risk of destabilizing people who aren't using that
plugin. But the issue that it's extra work still remains, so
> Any of these seem like a high price to pay if the benefit is just
> getting to use some nicer python2.5/2.6 source constructs.
Based on the thread to date it seems like the best course now is to
keep supporting python2.4 unless there's a stronger reason than just
wanting to use new 2.5/2.6 syntax. Getting a single codebase that
also works on 3.x might be such a reason, if it turns out that is
actually necessary.
I do remember sometimes getting test failures because I forgot about
something that either doesn't exist or is buggy in python2.4. But for
me it's not very frequent and not creating so much pain it would be
worth causing trouble for people using old distros, or the hassle of
backporting new formats.
--
Martin
Gordon Tyler
Hash: SHA1
On 1/4/2011 7:30 PM, Andrew Bennetts wrote:
> What sort of bug fixes do you have in mind? There are some bugs in the
> standard library that we have to work around, and having one less major
> version of the standard library to deal with would ease that burden a
> little. e.g. the recent fix for HTTPS under Python 2.7 would probably
> have been easier and cleaner if we didn't need to support 2.4. I don't
> think that is a particularly large cost though.
I don't know of any in particular, I was merely talking in the general
sense.
> The main thing I'm tempted by is context managers, but given that
> bzrlib.cleanup provides an adequate alternative that works under 2.4
> even that's not so important.
I haven't seen bzrlib.cleanup so I may be talking out of my ass here,
but `with` is probably a cleaner solution and there is a not
insignificant benefit to clean readable code. In other words, how much
cruft is there in the current source to satisfy python-2.4 requirements
that could be done in a cleaner fashion under python-2.5/2.6 and make it
much easier to understand and work with?
> I agree with Martin that these benefits don't seem to outweigh the
> enormous costs of backporting significant changes to a 2.4 compatible
> version.
Backporting is *nice* but is it *necessary*?
I'm mostly playing devil's advocate here to maybe trigger some
realization about assumptions that may have been made. I understand the
necessity of backwards-compatibility only too well having to maintain
JDK1.4-compatibility in my work projects (while eyeing all the nice
stuff in JDK1.6) due to irritating customers who insist on using
appservers that are *years* out of date. ;)
Ciao,
Gordon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNI8C6AAoJEIrPJfWinA2uiKwH/RluTTdfgo9NzCWT5AcNdNUR
YOu/moP+3UvfiUzW6a3omus+kquA2+EiebHRUkeWlZ/yeie672MHUvvKyfXT8wFn
xQJtfpl8vO5/ML1UynUwICixIr8f8v88smgbIRY3lo9Nxl1rZIPjFZRgldnZkgch
kWotM/cs8xctm2OvEWxmMqMXW9JSeJ6zU0au+mXY84R2UyR6KG6j1z3Xama9cUo5
NCNpSCIFC6amLFqfni6CI4y9Ksg6/hP9fHpyjCBTDt7ifVQShFz3iaRTgf5ejCrG
OxlceHh/TBTOottTHas0PjdU/kt48Hpcgw/aTO2L8oQUxM/z0IUCP/cKwIrAf4o=
=pReu
-----END PGP SIGNATURE-----
David Muir
>> Any of these seem like a high price to pay if the benefit is just
>> getting to use some nicer python2.5/2.6 source constructs.
> Based on the thread to date it seems like the best course now is to
> keep supporting python2.4 unless there's a stronger reason than just
> wanting to use new 2.5/2.6 syntax. Getting a single codebase that
> also works on 3.x might be such a reason, if it turns out that is
> actually necessary.
>
> I do remember sometimes getting test failures because I forgot about
> something that either doesn't exist or is buggy in python2.4. But for
> me it's not very frequent and not creating so much pain it would be
> worth causing trouble for people using old distros, or the hassle of
> backporting new formats.
>
FWIW, RHEL5 will still have "phase 1" support until the end of this year.
It might be good to at least wait until then before dropping 2.4 support.
David
Toshio Kuratomi
>
> I suppose improvement that are only in Python 3.x do fit here, but
> that's a somewhat separate discussion: "when should we support 3.x?",
> and then only secondarily "will dropping 2.4/5 help us support 3.x"?
> It seems like it will help a bit but it's not the main thing.
>
> Let's suppose someone came up with a branch that cleanly supported 2.6
> and 3.x, and they said they found it impossibly hard to also support
> 2.4 from the same codebase. Quite possibly this would be faster on
> 3.x than we are at the moment on 2.x. Eventually we'll support 3.x.
> Will we do it as soon as bzr2.4, if it means no more support for
> python 2.5? I think it could be a reasonable tradeoff.
>
python2 and python3 stacks even though we don't have parallel python2.4
python2.5 python2.6 python2.7 stacks. We consider them separate enoguh
languages that we need to have both of them.
In RHEL, neither RHEL5 nor RHEL6 ships with python3. We (Fedora EPEL
Project) ship python3 for RHEL5 in the EPEL5 repository and likely will also
ship it in the EPEL6 repository so we might be able to update if needed.
There's a few caveats to that though:
1) python3 makes releases just like python2 -- so you may ship python-3.2
compatible code but some distributions may only have python-3.1. (EPEL5 is
currently shipping python-3.1 since 3.2 isn't released yet. python-3.0
isn't recommended so hopefully you wouldn't have to worry about it. EPEL
tries to follow the same release methodology as RHEL so EPEL wouldn't ship
python-3.2 as it'll break people depending on the python3 package to not
break compatibility).
2) In RHEL6, there's a bzr package in RHEL proper. Unfortunately, that
means if bzr is ported to python3, RHEL6 will have to continue to ship the
old version that runs on python2. (There lots of permutations here, of
course -- if bzr runs on both python2.6 and python3.x then RHEL6 can ship
updates since it comes with python2.6. If there's only a python3 version of
bzr, RHEL6 could choose (I'm not sure it's likely, though) to ship a python3
stack sufficient to ship the new bzr. The bzr maintainer in RHEL may decide
that they just aren't able to ship an updated bzr due to API changes
in bzrlib no matter whether the newer bzr supports python2.6 or not...)
> On the other hand, when we come to try that work it might turn out
> that it's hard to support both 2.6 and 3.x, or on the other hand that
> supporting 2.5 is no harder than supporting 2.6. I've seen anecdotes
> supporting any of these positions so I think the only thing is to
> actually try it in bzr.
>
I very much agree with you here. Until someone takes a stab at converting
the code and testing it under python3 you won't really know what versions
can be supported.
-Toshio
Vincent Ladeuil
<snip/>
> If you do backports of new formats to the version of bzr that supports
> python-2.4 that strikes a great balance as far as I'm concerned.
Be sure to voice your concern again *if* and *when* we start talking
about a new format.
> I still have to keep bzr running on RHEL5 for people who use it there until
> RHEL5 EOLs and the big thing is *not* performance optimizations, new
> software that targets new APIs, and such... end users understand that those
> types of things may require a newer version of python/bzr. It really is just --
> "I'm running RHEL5 and I need to interoperate with the repository
> format on launchpad to checkout the latest version of gwibber"
I expect that you'll run into problems from the gwibber side asking for
versions of software components not supported by RHEL5 before you
encounter the same issues with bzr (and again, make sure you make your
issues known as you've done here).
> or "I'm running bzr smart server on a RHEL5 server and a few of
> the clients pushing repos get errors because they default to the
> new format."
This is easier to address as it "only" require that bzr can decide which
format should be the default at a project level (which is not
implemented yet, bialix made a proof-of-concept plugin to ensure this at
a user level so we know it's doable).
But in both cases, while I agree bzr should address both needs, it's
also a project community issue to ensure that all members are aware of
the necessary constraints to interoperate.
Vincent
Vincent Ladeuil
> On Tue, Jan 04, 2011 at 04:54:29PM -0600, John Arbash Meinel wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 1/4/2011 4:53 PM, Toshio Kuratomi wrote:
>> ...
>>
>> >> There are no immediate plans to implement a new format. But it is
>> >> certainly something that we would be unlikely to backport into an old
>> >> stable release.
>> >>
>> > A plugin would be fine (as long as it works ;-). Is that what you're
>> > proposing?
>> >
>> > -Toshio
>>
>> I'm saying that if we do introduce a new format, and have discontinued
>> python2.4 compatibility, it shouldn't be hard to write a plugin for
>> older bzr to interoperate with newer ones.
>>
> Thanks,
> -Toshio "who feels bad asking if someone else plans to do work on some piece
> of free software but knows he lacks the time to meet even his current free
> software commitments :-("
Hehe, right to the point.
This is the core of the discussion, should we continue to spread our
efforts maintaining compatibility with an increasing number of python
versions or do we start dropping compatibility with the oldest ones. And
if we drop them, who's left in the cold and what can we do.
> Just one clarification -- are you saying, "it would be easy for us
> (bzr developers) to create a plugin so we should plan on doing
> that rather than support the entire codebase on older python" or
> "it would be easy for some interested party to create a plugin if
> they choose to"?
Well, we are in the same boat as you as far as resources are concerned
:)
But whatever new format we create, we will have a bunch of associated
tests, which should help lower the maintenance effort on the plugin
side (modulo test backports, yada yada, at least the specs will be
clearly defined).
> I ask because well... I'll be able to move the servers I care about to RHEL6
> (and python-2.6) so I probably won't scratch that itch.
And if enough users, reasonably, take the same approach, then this
discussion may be enough...
> But I know that I'll get bug reports asking why the bzr on RHEL5
> doesn't work with launchpad and I hate closing bugs as CANTFIX.
+1
Vincent
Paul Sladen
> But whatever new format we create,
My personal hope is that any additional format(s) that Bzr may gain
support for, will be ones that are /already/ supported by other,
existing tools---thus lowering the requirement that Bzr *must* be
available because it would be the only way to access that repository.
If the burden and stress of being the exclusive/only means of access
to a user's data is removed for a particular OS combination is
removed, then this probably frees up the situation significantly in
terms of what to consider supporting and where to focus energies on.
-Paul
Barry Warsaw
><nod> python3 is an interesting target. In Fedora, we have parallel
>python2 and python3 stacks even though we don't have parallel python2.4
>python2.5 python2.6 python2.7 stacks. We consider them separate enoguh
>languages that we need to have both of them.
The same is true for Debian/Ubuntu.
>1) python3 makes releases just like python2 -- so you may ship python-3.2
>compatible code but some distributions may only have python-3.1. (EPEL5 is
>currently shipping python-3.1 since 3.2 isn't released yet. python-3.0
>isn't recommended so hopefully you wouldn't have to worry about it. EPEL
>tries to follow the same release methodology as RHEL so EPEL wouldn't ship
>python-3.2 as it'll break people depending on the python3 package to not
>break compatibility).
The situation in Python 3 is a little different though due to the language
moratorium (PEP 3003). This primarily covers core syntax, builtins, and
semantics, so it doesn't address all the compatibility issues you'll hit, but
it does help. I personally think that Python 3.2 is the first version that
folks should consider writing against natively with new code bases, and it
makes a good target for porting Python 2 code.
>> On the other hand, when we come to try that work it might turn out
>> that it's hard to support both 2.6 and 3.x, or on the other hand that
>> supporting 2.5 is no harder than supporting 2.6. I've seen anecdotes
>> supporting any of these positions so I think the only thing is to
>> actually try it in bzr.
>>
>I very much agree with you here. Until someone takes a stab at converting
>the code and testing it under python3 you won't really know what versions
>can be supported.
Yep. I do fear that there will be a fair amount of yak shaving necessary
though, as you find you need missing support in third party libraries. That's
really valuable to the community as a whole, but might seem like waste to bzr
hackers. Still, I think you should budget for a certain amount of porting
and patching work in bzr's dependencies (and even possibly the stdlib).
-Barry
Toshio Kuratomi
> I expect that you'll run into problems from the gwibber side asking for
> versions of software components not supported by RHEL5 before you
> encounter the same issues with bzr (and again, make sure you make your
> issues known as you've done here).
>
launchpad, of course. There's other things that have less volatile deps
that live on launchpad that people will want to contribute to but could have
problems getting if the format changes but isn't available in their client.
> > or "I'm running bzr smart server on a RHEL5 server and a few of
> > the clients pushing repos get errors because they default to the
> > new format."
>
> This is easier to address as it "only" require that bzr can decide which
> format should be the default at a project level (which is not
> implemented yet, bialix made a proof-of-concept plugin to ensure this at
> a user level so we know it's doable).
>
That would be helpful. I haven't been following his work but would it be
able to address either of these two cases?
(Client with a newer default format):
$ bzr init-repo blah
$ cd blah
$ bzr branch bzr://older.repository/format/server/
$ bzr init newproject
$ cd newproject ; touch hi
$ bzr add hi ; bzr commit
$ bzr push bzr+ssh://older.repository/format/server/
I'm guessing not as the format is laid down on disk before talking to the
server that would have project information.... Unless you're talking about
project information being installed by someone's IT dept (or downloaded from
the internet) before the person starts working... that would be
non-transparent and therefore a bit "unclean" for the end-user though.
-Toshio
Max Bowsher
Hah :-) I have actually previously hypothesized that 'bzr init-repo'
could default to creating an 'undecided' format repository, which would
then lazily turn itself into a real repository dependent on the
rich/poor-rootness and CHK/XML-inventoryness of the first revision
stored to it.
This would have saved a fair bit of annoyance during that period when
most Launchpad projects were transitioning to 2a.
Max.
John Arbash Meinel
Hash: SHA1
I'm curious on your thoughts on this.
I did come across this:
http://www.python.org/dev/peps/pep-3146/
Which is marked as approved.
and
http://groups.google.com/group/unladen-swallow/browse_thread/thread/f2011129c4414d04
Which seems to say that the Google Engineers who originally started it,
got caught up in other work, but had some time again to work on it.
There was a message from Collin in Nov that it was a priority "this
quarter". And Brett posted just Jan 5th an update as well.
It does seems to be pretty slow going. And from what I can find LLVM
turned out to not be as great as they had hoped. (Its native
intermediate representation VM is slow and doesn't support all IR, and
after everything was turned on, it got memory bloat without a lot of
performance improvement.)
Interestingly that thread also seems to recommend looking at PyPy.
(Which just recently finally passed its benchmarks of being faster at
compiling itself than cPython compiling PyPy.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0k8tkACgkQJdeBCYSNAAM/OgCeOU//yf/w+MggGGCYUpzIGFp2
WMkAoKRzc2XIY7rPz3YgMkvpOEV9EqNO
=ui5b
-----END PGP SIGNATURE-----
Barry Warsaw
Hash: SHA256
On Jan 05, 2011, at 04:38 PM, John Arbash Meinel wrote:
>I'm curious on your thoughts on this.
>
>I did come across this:
>http://www.python.org/dev/peps/pep-3146/
>
>Which is marked as approved.
originally discussed at the language summit (but my memory about stuff like
that sucks, and I'm too lazy^H^H^H^Hbusy right now to check :).
>and
>http://groups.google.com/group/unladen-swallow/browse_thread/thread/f2011129c4414d04
>
>Which seems to say that the Google Engineers who originally started it,
>got caught up in other work, but had some time again to work on it.
fjords :). OTOH, we all know how these spare-time projects go. I do hope it
gets renewed momentum for Python 3.3 because I think it could be a very
compelling carrot for folks to migrate to Python 3.
>It does seems to be pretty slow going. And from what I can find LLVM
>turned out to not be as great as they had hoped. (Its native
>intermediate representation VM is slow and doesn't support all IR, and
>after everything was turned on, it got memory bloat without a lot of
>performance improvement.)
spending much more time fixing basic LLVM bugs than working on the Python
integration.
>Interestingly that thread also seems to recommend looking at PyPy.
>(Which just recently finally passed its benchmarks of being faster at
>compiling itself than cPython compiling PyPy.)
might have to make the time soon!
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNJPYrAAoJEBJutWOnSwa/D9cQAI+m5setZ5Y7RBz9wYoElL6o
OVFCmzE/3ccTouhaPS7TmMw0PyrmfMqMSgIT8Ui7B960wcbvVigPaOOmq3Lwpa9W
W404qkzHERFfKotLutAT7kqBx1YLqI5+G/VVFkjc7saLIbgt5M3dBcXQzDfDYtAY
x6alNi5+kQuHJ11VBXnSKOTPNS5yoTvvI6YSaYet9OpHHjvLDC8gJoNeX8LSkIpN
kVaSJjJuDXcZ9rJWdCdvhNoWCVZZ7OzI74SujZkAOx9Nc26ZpOsUQ/RnqziwqUjS
AmusPo2kCD6OrQ/31Vz3naZpQQYJLIIuWCfQFOIE4ITE8rJ01rAtZn/RZGcTximb
5xI2cTeW/dcefZysZfpoH3KUTvOiPjMxTQQYS2SOyjWOreYH0NuaKyzLwZWdEI7w
oxhnV/9+xUcpM2CLoNqMStlXm59EeByA5KNjCNSCpHORa49GzHYmZgR2SIrebehN
IFdbMy0uxHWrdN3LrUUTSbOL/Vv0fF8tkkBfcVkvRhzquvSoDfKhye+VI4lkbWSQ
VjPXzcJCUMvLzhpBKmW8qRukeNZWF3RCXd6q78IWwJDg5bEfyeICUCLNLITNRHq8
yvu9yTK+XF8ldwhxysaF23FRUb/k4tYSlQXPmcRGQCs2E9JQ9zDJHj8eW/GFxzLY
jPNr76IykKSIvX/PClkz
=nztG
-----END PGP SIGNATURE-----
Andrew Bennetts
[...]
> Interestingly that thread also seems to recommend looking at PyPy.
> (Which just recently finally passed its benchmarks of being faster at
> compiling itself than cPython compiling PyPy.)
PyPy is also now faster at almost all Twisted benchmarks they've tried
too. So definitely worth looking at I think.
-Andrew.
Martin Pool
>> The main thing I'm tempted by is context managers, but given that
>> bzrlib.cleanup provides an adequate alternative that works under 2.4
>> even that's not so important.
>
> I haven't seen bzrlib.cleanup so I may be talking out of my ass here,
> but `with` is probably a cleaner solution and there is a not
> insignificant benefit to clean readable code. In other words, how much
> cruft is there in the current source to satisfy python-2.4 requirements
> that could be done in a cleaner fashion under python-2.5/2.6 and make it
> much easier to understand and work with?
There's some unnecessary code due to supporting old Python's but I
think not a huge amount. See spiv's note about grepping for mentions
of them (though this won't cover all of them.)
Cleanups are basically just
self.addCleanup(callable)
so the lifetime is that of an object, rather than a lexical block. In
some cases this is actually better; in others, using it is not a
burden; probably in some case with would be cleaner.
string.format <http://docs.python.org/whatsnew/2.6.html#pep-3101-advanced-string-formatting>
would be nice in 2.6 but there's not really any cruft because of
lacking it.
>> I agree with Martin that these benefits don't seem to outweigh the
>> enormous costs of backporting significant changes to a 2.4 compatible
>> version.
>
> Backporting is *nice* but is it *necessary*?
It's necessary if we add a new format and if we want to let people on
python2.4 (RHEL5) interact with branches in that format. We don't
have work currently underway that adds a new format, but there are
things we want to do with looms/lightweight branches/etc that might
add one.
> I'm mostly playing devil's advocate here to maybe trigger some
> realization about assumptions that may have been made. I understand the
> necessity of backwards-compatibility only too well having to maintain
> JDK1.4-compatibility in my work projects (while eyeing all the nice
> stuff in JDK1.6) due to irritating customers who insist on using
> appservers that are *years* out of date. ;)
Yeah, I've been there too. I don't think in the specific case of bzr
it is causing people much pain.
So the current bottom line of this discussion seems to be:
* using python2.5 and 2.6 features only rates as a "would be nice"
from developers
* dropping 2.4 support in trunk and then releasing a new format (or
something else that mandates a major upgrade) will cause pain to a
small but nontrivial subset of users
* dropping 2.4 is not worthwhile at the moment
* we can reconsider dropping 2.4 at the time that supporting it
becomes annoying
* eventually we want to move to 3.x
* do determine whether moving to 3.x requires dropping 2.4 (or 2.x
altogether) needs more study, and probably actually trying it
Therefore I think the actual actions are:
* it's fine to run pqm on lucid (which is where this thread started)
so the main integration tests will be under python2.6
* we should test python2.4 under Babune
* during 2011 we should try to get at least a branch of bzr running
under python3
--
Martin
Martin Pool
Interesting point.
--
Martin
jbo...@amathaine.com
>
> From memory 2.6 has relatively more relevant new features we'd like to
> use than 2.5 does, so there is an incentive to bump our requirement
> all the way to 2.6.
>
> Before deciding when to go to 3.0 I'd like to take a spike on actually
> doing the conversion, or getting bzr going under 2to3, so that we have
> a better measure of how buggy or hard it's going to be.
>
If you were to go all the way to 2.6 I'd definitely volunteer to start
running the codebase through 2to3 regularly and contributing patches.
Being able to explicitly distinguish between bytes and strings is
probably the hardest part we'll face.
Martin Pool
That seems to imply you think it will actually be infeasible or too
hard to run through 2to3 if we keep compatibility with 2.4?
--
Martin
jbo...@amathaine.com
>
> That seems to imply you think it will actually be infeasible or too
> hard to run through 2to3 if we keep compatibility with 2.4?
>
Well, 2.6 is intended as the baseline. Things like dict.has_key()
don't even exist in 3.x, whereas it's pretty common to find in 2.4 and
even 2.5 codebases.
There was a thread some months ago pointing out some of the issues;
off the top of my head 2to3 for example will complain about not using
hashlib, we won't be able to explicitly mark bytestrings (ie, use
bytes() or b''), etc.
Plus there a a heap of changes in the standard library that need to be
accounted for (say, the introduction the ssl module which might clear
up some of our transport code or the dropping of the md5 and sha
modules which might affect authentication code). Some of those just
won't go across since deprecated modules are dropped completely in the
3.x library.
The recommended transition strategy is, roughly:
# Port your code to Python 2.6.
# Make sure all the tests pass using that version.
# Run your code under Python 2.6 with the -3 flag.
# Fix any warnings.
# Run the tests again (still under Python 2.6).
# Run the 2to3 tool.
# Run your tests under Python 3.
# Fix any problems.
# Repeat until all tests pass.
The main point for maintenance is to only write Python 2.6 code and
use 2to3 to generate a 3.x version as part of the build process. You
don't really need to create a 3.x fork until such time as you decide
to abandon Python 2.x entirely.
Vincent Ladeuil
<snip/>
> The recommended transition strategy is, roughly:
> # Port your code to Python 2.6.
> # Make sure all the tests pass using that version.
> # Run your code under Python 2.6 with the -3 flag.
> # Fix any warnings.
> # Run the tests again (still under Python 2.6).
> # Run the 2to3 tool.
> # Run your tests under Python 3.
> # Fix any problems.
> # Repeat until all tests pass.
> The main point for maintenance is to only write Python 2.6 code and
> use 2to3 to generate a 3.x version as part of the build process. You
> don't really need to create a 3.x fork until such time as you decide
> to abandon Python 2.x entirely.
That was my understanding (well, mostly based on a gut feeling rather
than really informed).
Martin and Andrew have good arguments about the apparent low cost of
maintaining compatibility with 2.4/2.5, so I think we should just try
the -3 flag and 2to3 and see.
This means keeping trunk in 2.x and experiment with a fork based on the
2to3 results.
If we decide to target 3 more aggressively later, we can still change
our mind and switch to maintaining trunk in 3 and a fork based on the
3to2 results.
Vincent
Toshio Kuratomi
> >>>>> John Barstow <jbo...@amathaine.com> writes:
>
> <snip/>
>
> > The recommended transition strategy is, roughly:
>
> > # Port your code to Python 2.6.
> > # Make sure all the tests pass using that version.
> > # Run your code under Python 2.6 with the -3 flag.
> > # Fix any warnings.
> > # Run the tests again (still under Python 2.6).
> > # Run the 2to3 tool.
> > # Run your tests under Python 3.
> > # Fix any problems.
> > # Repeat until all tests pass.
>
> > The main point for maintenance is to only write Python 2.6 code and
> > use 2to3 to generate a 3.x version as part of the build process. You
> > don't really need to create a 3.x fork until such time as you decide
> > to abandon Python 2.x entirely.
>
> That was my understanding (well, mostly based on a gut feeling rather
> than really informed).
>
> Martin and Andrew have good arguments about the apparent low cost of
> maintaining compatibility with 2.4/2.5, so I think we should just try
> the -3 flag and 2to3 and see.
>
modules from upstream is that most projects have python-2.4 compatible code.
Then they use distribute (the setuptools fork) to run 2to3 from the setup.py
if python3 is being used. Now, I think bzr may be harder since it actually
does need to work with real bytes a lot but I'm not sure that dropping
python-2.4 compatibility makes that easier to manage. It's just something
someone's going to need to try to port.
> This means keeping trunk in 2.x and experiment with a fork based on the
> 2to3 results.
>
> If we decide to target 3 more aggressively later, we can still change
> our mind and switch to maintaining trunk in 3 and a fork based on the
> 3to2 results.
>
Note that although conceptually this is better, the 3to2 author thinks that
3to2 can never do as good of a job as 2to3 because python3's features are
a superset of python2's. So, he thinks that you'll always end up doing more
manual work if you go this route.
-Toshio
John Arbash Meinel
Hash: SHA1
At least one issue is that 2to3 doesn't work particularly well with
2.4/5 based code. Stuff like not being able to do b'foo'.
AIUI there is a compatibility shim that someone wrote, which lets you do
something like:
from compat import bytes
mystr = bytes('foo')
And on v3 it translates 'bytes()' to:
return s.encode('ascii')
And on v2 it translates to
return s
Sort of thing.
Which means a lot of invasive code changes to be able to support 2.4 +
3.0 via 2to3.
>
>> This means keeping trunk in 2.x and experiment with a fork based on the
>> 2to3 results.
>>
>> If we decide to target 3 more aggressively later, we can still change
>> our mind and switch to maintaining trunk in 3 and a fork based on the
>> 3to2 results.
>>
> Note that although conceptually this is better, the 3to2 author thinks that
> 3to2 can never do as good of a job as 2to3 because python3's features are
> a superset of python2's. So, he thinks that you'll always end up doing more
> manual work if you go this route.
>
> -Toshio
You can always not use features that aren't available in py2.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0mTE4ACgkQJdeBCYSNAAN9IACcCtQstzAduNUbjDlYslqERPsT
zxcAn0rMg76BB0VdvaeHusOT1d7fa1yi
=qSj+
-----END PGP SIGNATURE-----
jbo...@amathaine.com
<jo...@arbash-meinel.com> wrote:
> Which means a lot of invasive code changes to be able to support 2.4 +
> 3.0 via 2to3.
>
> You can always not use features that aren't available in py2.
>
If we ever get to the point where we're coding in 3.x, I think I'd
expect 2.7 to be the minimum supported version which has backported
enough 3.x features to make 3to2 viable.
However, I would expect our minimum version to go from 2.4 -> 2.6 ->
2.7 -> 3.x, unless 3.x unexpectedly gains critical mass for some
reason. Meaning that by the time we switch to writing 3.x code we
won't be supporting 2.x anymore (though I'm sure someone will maintain
a branch off the last official 2.x release for some years).