Hello all. So, python 2.7 is in bugfix only mode. 'trunk' is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python? The answer would seem to be "one doesn't". But must it be that way? When Morris stopped producing the Oxford III model back in '57 in favor of new developments, it didn't spell the end for it. The plant was sold to India and the Hindustan Ambassador<http://en.wikipedia.org/wiki/Hindustan_Ambassador> continues to be developed and produced to this day. It even has fuel injection. The Morris Motor Company isn't around anymore. So, here is my suggestion: Let's move the current 'trunk' into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love. Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole. Open-source it, if you will. Svn.python.org already plays host to some other, less official, projects such as stackless, so why not this? What do you think? Kristján
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com>
So, here is my suggestion:
Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love. Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole.
Without that rigmarole I wouldn't consider using such a product. I also don't know who would, and I think you'll have a hard time marketing a branch that doesn't receive the attention that the others do. I think it would be bad to associate an untested, free-for-all version of Python with python.org.
On Oct 27, 2010, at 10:22 PM, Kristján Valur Jónsson wrote:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python? The answer would seem to be “one doesn’t”. But must it be that way?
When Morris stopped producing the Oxford III model back in ’57 in favor of new developments, it didn’t spell the end for it. The plant was sold to India and the Hindustan Ambassador continues to be developed and produced to this day. It even has fuel injection. The Morris Motor Company isn’t around anymore.
So, here is my suggestion: Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love. Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole. Open-source it, if you will. Svn.python.org already plays host to some other, less official, projects such as stackless, so why not this?
The python community has already decided many times over that Python2 is dead and Python3 is the future. So if you want to continue maintaining Python2, that means you need to fork it. I think you'd be best off doing so on your own infrastructure: convincing the python developers to support such a thing is quite unlikely, and furthermore, completely unnecessary. Unlike the Oxford III, you don't need to be "sold" python2: it's open source, you can fork it without any official approval. So, just do it. I wish you best of luck, though: most unofficial forks die a lonely death. But, if enough people feel like you do, it could become successful. But I really doubt anyone else is going to want to use it any python2 afterlife without stringent quality assurance, multi-platform support releases, and other rigamarole. You'd have to set up all that stuff for yourself if you possibly hope to attract users. I can't think of any possible use for an unreliably maintained version of python2... James
Le jeudi 28 octobre 2010 05:12:09, James Y Knight a écrit :
The python community has already decided many times over that Python2 is dead and Python3 is the future. ... I think you'd be best off doing so on your own infrastructure: convincing the python developers to support such a thing is quite unlikely, and furthermore, completely unnecessary.
*I* don't really care to Python 2.x anymore: I consider Python 2.7 as mature and very stable. New features can still be developed as Python or C extensions (browse the Python package index to get some examples). I don't want to touch the Python2 core (the interpreter or the standard library) because it is too expensive (in time). I prefer to focus on Python3 because Python3 core has a better design: strict separation between bytes and characters, no more short integer type, no more old style class, etc. It's easier to work on Python3 core. Backport a patch from Python3 to Python2 takes between 10 minutes and 3 hours (or maybe more on complex patches) because the function names, C macros, even file names, (...), has changed. And I don't know automatic tools to convert a Python3 patch to a Python2 patch (eg. a "3to2" tool, for patches). I don't want to spend 3 hours or more on a "dead project". But when I find a bug in Python3, I immediatly check if it does also exist in Python2. And if both version are affected, I try to fix all versions (if it doesn't break the API). -- Victor Stinner http://www.haypocalc.com/
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com>
Svn.python.org already plays host to some other, less official, projects such as stackless, so why not this?
What are the benefits of hosting such a project on svn.python.org instead of somewhere else? (such as GitHub or BitBucket) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com/>
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge. Second, it would be an official nod from the python community that, yes, we are not actively developing 2.x anymore, we want to focus on 3.x but we acknowledge that there are members of our community that cannot, for various reasons, move to 3.x, but still want to be able to improve their platform and share those improvements with others. James Y Knight said: The python community has already decided many times over that Python2 is dead and Python3 is the future But the patient is very much alive and kicking, no matter what the good doctor declares. Python 2.x is in widespread use, with gazillion lines of .py code. In, there is another gazillion lines of .c and .cpp code both in extensions and embedding applications in use. I’m quite happy with the community at large moving its development focus to 3.x but it is a bit harsh to deprive those left behind of the keys to the old house. Cheers, K From: Daniel Stutzbach [mailto:daniel@stutzbachenterprises.com] Sent: Thursday, October 28, 2010 11:45 To: Kristján Valur Jónsson Cc: Python-Dev (python-dev@python.org) Subject: Re: [Python-Dev] Continuing 2.x already plays host to some other, less official, projects such as stackless, so why not this?
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge.
svn lets you merge across repos, I believe.
Second, it would be an official nod
How would it "official" if you were the only one maintaining it? -- Regards, Benjamin
On Wed, 27 Oct 2010 23:05:37 -0500 Benjamin Peterson <benjamin@python.org> wrote:
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge.
svn lets you merge across repos, I believe.
And, most of all, we're soon switching to hg (real soon now :-)). Regards Antoine.
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com>
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge.
py3k will soon be moving to Mercurial, so svnmerge would not be helpful for much longer. On the plus side, since Mercurial is a Distributed Version Control System, if you setup an unofficial continuation of Python 2 on the host of your choice, it will be easy for you to pull patches from py3k. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com/>
Am 28.10.2010 06:13, schrieb Daniel Stutzbach:
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com <mailto:kristjan@ccpgames.com>>
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge.
py3k will soon be moving to Mercurial, so svnmerge would not be helpful for much longer. On the plus side, since Mercurial is a Distributed Version Control System, if you setup an unofficial continuation of Python 2 on the host of your choice, it will be easy for you to pull patches from py3k.
I believe we'll eventually have the ability to create user repos as well, so that Kristjan can simply put his branch into one of these and still have it on hg.python.org. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Wed, Oct 27, 2010 at 11:48 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 28.10.2010 06:13, schrieb Daniel Stutzbach:
2010/10/27 Kristján Valur Jónsson <kristjan@ccpgames.com <mailto:kristjan@ccpgames.com>>
Firstly, the ease of integrating changes. It would be possible to port those bugfixes that release-27 gets, and also backport selected things from py3k using the tools already in place such as svnmerge.
py3k will soon be moving to Mercurial, so svnmerge would not be helpful for much longer. On the plus side, since Mercurial is a Distributed Version Control System, if you setup an unofficial continuation of Python 2 on the host of your choice, it will be easy for you to pull patches from py3k.
I believe we'll eventually have the ability to create user repos as well, so that Kristjan can simply put his branch into one of these and still have it on hg.python.org.
Georg
Huge +1 from me- I think this would be an excellent development. Geremy Condra PS- this should not be taken as an endorsement of the original proposal, I simply don't use 2.x anymore and don't have an opinion on it.
Kristján Valur Jónsson writes:
Second, it would be an official nod from the python community that, yes, we are not actively developing 2.x anymore, we want to focus on 3.x but we acknowledge that there are members of our community that cannot, for various reasons, move to 3.x, but still want to be able to improve their platform and share those improvements with others.
I don't see an insuperable problem in principle with hosting it on python.org (for the practical reasons you give, it would be helpful), but I think the repository belongs in /projects/v2-afterlife, not in /projects/python.
I’m quite happy with the community at large moving its development focus to 3.x but it is a bit harsh to deprive those left behind of the keys to the old house.
If you mean the current set of 2.x branches in the repository, no, that's not an "old" house, that's the same house we still live in. It contains the official history of each 2.x branch. The continuing development you propose is unofficial, and doesn't belong there.
Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love. Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole. Open-source it, if you will.
If you don't plan to make a release eventually, why would anybody care? If you do plan to make a release eventually, please say so. That would then be the point where I can point out that I will not be available to make Windows binaries for such a release. Also, if you do plan to make a release, please also indicate how you would label it. Regards, Martin
Who is the target audience for a Python 2.8? What exactly would a Python 2.8 accomplish? If Python 2.8 doesn't include new features, well, then what's the point? Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions. So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7). If Python 2.8 is about adding new features, then it has to be about backporting those features from Python 3. Adding new feature only to a Python 2.8 *isn't* Python, it's a fork of Python. Of course, it's open source and you're always allowed to do that, but you would need to be clear that this isn't "Python". IOW, a distro like Ubuntu would likely never package such a thing as "/usr/bin/python". What specific features that are showing up in say Python 3.2 are so compelling that they need to show up in Python 2.8, *and* would compel folks who are pinned to Python 2 to spend the resources to support it? Porting and certifying a code base against a new Python version is always work, sometimes a significant amount of work. What would be so compelling about a Python 2.8 that users, package authors, and distros would be willing to undertake this work? I'd *much* rather this enthusiasm be spent on making Python 3 rock, and in porting third party code to Python 3. -Barry
On Oct 28, 2010, at 04:17 PM, exarkun@twistedmatrix.com wrote:
On 04:04 pm, barry@python.org wrote:
I'd *much* rather this enthusiasm be spent on making Python 3 rock, and >in porting third party code to Python 3.
Enthusiasm isn't fungible.
Maybe so, but I think it's actually more fun to be working on something other people will actually use. ;) -Barry
Barry Warsaw writes:
Maybe so, but I think it's actually more fun to be working on something other people will actually use. ;)
I think that the point is that the people will be doing this are supporting software to pay for Johnny's piano lessons, not for personal pleasure. I imagine many, perhaps most, of them would rather be coding and/or Python 3, too!
On Thu, Oct 28, 2010 at 9:04 AM, Barry Warsaw <barry@python.org> wrote:
Who is the target audience for a Python 2.8? What exactly would a Python 2.8 accomplish?
If Python 2.8 doesn't include new features, well, then what's the point? Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions. So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
If Python 2.8 is about adding new features, then it has to be about backporting those features from Python 3. Adding new feature only to a Python 2.8 *isn't* Python, it's a fork of Python.
Thinking about language features and core type this seems reasonable, but with the standard library this seems less reasonable -- there's lots of conservative changes to the standard library which aren't bug fixes, and the more the standard library is out of sync between Python 2 and 3 the harder maintaining software that works across those versions becomes. Though one opportunity is to distribute modules from the standard library under new names (e.g., unittest2), and at least in Python 2 you don't have to do anything fancy or worry about the standard library has catching up to the standard library forked module. Library installers seem particularly apropos to this discussion, as everyone seems excited to get them into the standard library and distributed with Python, but with the current plan that will never happen with Python 2. -- Ian Bicking | http://blog.ianbicking.org
On Thu, 28 Oct 2010 10:25:28 -0700 Ian Bicking <ianb@colorstudy.com> wrote:
Thinking about language features and core type this seems reasonable, but with the standard library this seems less reasonable -- there's lots of conservative changes to the standard library which aren't bug fixes, and the more the standard library is out of sync between Python 2 and 3 the harder maintaining software that works across those versions becomes.
For the same reason that new features only get in 3.2 and not in 3.1 or 2.7, for example. I know people would like both stability *and* new features in the same codebase, but that doesn't work. There's a reason most decently managed software projects have separate bugfix branches and feature branches. That's the same old discussion and it isn't specific to Python. (and, believe me, not having to backport new 3.x features to the 2.x branch makes our work much easier than it was; people generally seem to underestimate the amount of care needed for such things, especially in areas where 2.x is significantly more complex - old-style classes, two parallel buffer APIs, misleading implicit conversions...) Regards Antoine.
(and, believe me, not having to backport new 3.x features to the 2.x branch makes our work much easier than it was; people generally seem to underestimate the amount of care needed for such things, especially in areas where 2.x is significantly more complex - old-style classes, two parallel buffer APIs, misleading implicit conversions...)
I completely agree with that point. I find it unlikely that those who do regular maintenance of Python will join a continuing-2.x effort. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/2010 12:04 PM, Barry Warsaw wrote:
Who is the target audience for a Python 2.8? What exactly would a Python 2.8 accomplish?
If Python 2.8 doesn't include new features, well, then what's the point? Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions. So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
If Python 2.8 is about adding new features, then it has to be about backporting those features from Python 3.
I think that assumption may not be warranted. If the current core folks are focused only on developing Python 3, but others are working on a notional 2.8, there is no necessary correlation any longer between the two. In particular, the judgement of the current core about various tradeoffs in the Python 2 codebase won't be as relevant as it has been, in particular because the overarching drive (add features / warnings etc. which ease / encourage migration to Python 3) won't be in the forefront of the new group's perspective.
Adding new feature only to a Python 2.8 *isn't* Python, it's a fork of Python.
- From the perspective of this notional group of 2.8 developers, that particular horse is out of the barn already: it is called "Python 3".
Of course, it's open source and you're always allowed to do that, but you would need to be clear that this isn't "Python".
Pythonic is in the eye of the beholder.
IOW, a distro like Ubuntu would likely never package such a thing as "/usr/bin/python".
For the set of folks who might care about the retro-forked 2.8, I doubt that will matter. For instance, although I'm not (necessarily) in that camp, I choose not to use the system python for any app I deploy: the system packagers make tradeoffs which are inappropriate for my applications, and I don't want to risk having a sysadmin-driven update break them. I always build Python from source and install under '/opt'. Distros who desire to package not-yet-or-maybe-ever-ported-to-Python-3 apps will have to make their own choices. Perhaps the retro-fork is available via a PPA or "extras" repository, and installs explictly as '/usr/bin/python2'.
What specific features that are showing up in say Python 3.2 are so compelling that they need to show up in Python 2.8, *and* would compel folks who are pinned to Python 2 to spend the resources to support it? Porting and certifying a code base against a new Python version is always work, sometimes a significant amount of work. What would be so compelling about a Python 2.8 that users, package authors, and distros would be willing to undertake this work?
I can imagine features (and particularly library changes) which aren't even on the radar for Python 3, which provide real value to to folks maintaining the notional 2.8, and hence which get developed there first; perhaps they get forward-ported later to a future Python 3 release.
I'd *much* rather this enthusiasm be spent on making Python 3 rock, and in porting third party code to Python 3.
Sure you would -- you're already invested there. I would like to be there, but can't take off the several months required to port the whole stack under my own code. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzJtxMACgkQ+gerLs4ltQ7iTACglNlfMd+zEx0isiTAvTECGT6h VccAmgMHBMGkLQaqONU9CC5wY9uso63V =Qpxy -----END PGP SIGNATURE-----
On Fri, Oct 29, 2010 at 3:47 AM, Tres Seaver <tseaver@palladion.com> wrote:
I think that assumption may not be warranted. If the current core folks are focused only on developing Python 3, but others are working on a notional 2.8, there is no necessary correlation any longer between the two. In particular, the judgement of the current core about various tradeoffs in the Python 2 codebase won't be as relevant as it has been, in particular because the overarching drive (add features / warnings etc. which ease / encourage migration to Python 3) won't be in the forefront of the new group's perspective.
That's a fair point actually, but it would be a decision for the possible-but-not-yet-existing group to take as they formed. Given the likely divergence in design goals, it would probably be best to just bite the bullet and declare it a fork of Python 2.7 (py2x 2.8? RetroPython 2.8?). It would hardly be the first such fork - other flavours of 2.x with design goals that differ from those of python-dev certainly have a long history (Stackless, wpython, etc). There are also IP issues to consider in setting up such a group though. The PSF takes care of it for python.org, but those contributor agreements wouldn't necessarily cover a new fork. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi all. This has been a lively discussion. My desire to keep 2.x alive in some sense is my own and I don't know if anyone shares it but as a member of this community I think I'm allowed to voice it. So, just to clarify my particular position, let me explain where all this comes from. I am the maintainer of a private fork of Stackless Python 2.7, used by EVE Online. Since I started doing this, we have moved from version 2.1 to 2.3, 2.5 and finally a few months ago to 2.7. Python is embedded into the C application so we use the C API extensively. For a long while now I have been contributing a few improvements and patches to both the interpreter core and the standard library. These are changes that stem from solving particular problems that we face in our rather extensive use of python, and range from crash bugs to performance optimizations as well as the occasional feature. Usually the process is something like this: 1) We identify a problem that needs fixing. 2) We then spend some development effort on finding the right fix for it. 3) We then reflect: Shouldn't this be contributed back to standard Python? That means a) others will benefit b) It reduces the diff of our fork from the central branch. 4) I spend some time reworking the change, submit a patch to the 2.x version that eventually gets accepted or rejected by the community 5) And in the last few years, should a change be accepted, I am then often asked port the change to 3.x, which I normally do. (and sometimes even correctly using svnmerge...) This has been a happy and a personally fulfilling process, because who doesn't like to contribute to Python? Now, of late some of this has changed. Changes, (except those that pass as "bugfixes") are no longer accepted into the 2.x branches. Should the change apply to 3.x, then I have to locally port it to 3.x, and submit it to that branch. Some changes don't really apply to 3.x at all and have no place to go. So people using a platform similar to mine won't benefit. The result is that there is a much higher threshold for any of our improvements to make it back to the community and much less personal pleasure derived from it. What finally drove me to write the original post, was that working with the new bytearray and memoryview object in 2.7 made me realize that they don't interoperate with other classes in a natural way and so nullify their advantages. My straightforward patches to 2.7 to remedy this situation (issues 10211 and 10212) were met with the usual "it's not a bugfix" reply. So, I'm frustrated. I work with 2.7 on a day to day basis, and will continue to do so for quite some time. It's a great product with some shortcomings, and I'd like to contribute to it but such contributions aren't welcome anymore. I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go. Cheers, Kristján -----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com@python.org [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Barry Warsaw Sent: Friday, October 29, 2010 0:04 To: python-dev@python.org Subject: Re: [Python-Dev] Continuing 2.x Who is the target audience for a Python 2.8? What exactly would a Python 2.8 accomplish? If Python 2.8 doesn't include new features, well, then what's the point? Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions. So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Hi all. This has been a lively discussion. My desire to keep 2.x alive in some sense is my own and I don't know if anyone shares it but as a member of this community I think I'm allowed to voice it. So, just to clarify my particular position, let me explain where all this comes from.
I am the maintainer of a private fork of Stackless Python 2.7, used by EVE Online. Since I started doing this, we have moved from version 2.1 to 2.3, 2.5 and finally a few months ago to 2.7. Python is embedded into the C application so we use the C API extensively. For a long while now I have been contributing a few improvements and patches to both the interpreter core and the standard library. These are changes that stem from solving particular problems that we face in our rather extensive use of python, and range from crash bugs to performance optimizations as well as the occasional feature. Usually the process is something like this: 1) We identify a problem that needs fixing. 2) We then spend some development effort on finding the right fix for it. 3) We then reflect: Shouldn't this be contributed back to standard Python? That means a) others will benefit b) It reduces the diff of our fork from the central branch. 4) I spend some time reworking the change, submit a patch to the 2.x version that eventually gets accepted or rejected by the community 5) And in the last few years, should a change be accepted, I am then often asked port the change to 3.x, which I normally do. (and sometimes even correctly using svnmerge...) This has been a happy and a personally fulfilling process, because who doesn't like to contribute to Python?
And all of that work has been appreciated obviously (in case that wasn't obvious =).
Now, of late some of this has changed. Changes, (except those that pass as "bugfixes") are no longer accepted into the 2.x branches. Should the change apply to 3.x, then I have to locally port it to 3.x, and submit it to that branch. Some changes don't really apply to 3.x at all and have no place to go. So people using a platform similar to mine won't benefit. The result is that there is a much higher threshold for any of our improvements to make it back to the community and much less personal pleasure derived from it.
What finally drove me to write the original post, was that working with the new bytearray and memoryview object in 2.7 made me realize that they don't interoperate with other classes in a natural way and so nullify their advantages. My straightforward patches to 2.7 to remedy this situation (issues 10211 and 10212) were met with the usual "it's not a bugfix" reply.
Which is the correct reply.
So, I'm frustrated. I work with 2.7 on a day to day basis, and will continue to do so for quite some time. It's a great product with some shortcomings, and I'd like to contribute to it but such contributions aren't welcome anymore.
Well, they are welcome, just in Python 3.2 instead of Python 2.7 (when they apply to Python 3.2 in the first place). We have had a bugfix version in development as well as the new features version for ages. It just so happens that a bunch of people have not decided when they plan to switch to the new features version yet.
I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go.
It's called a fork. I realize you are trying to avoid that "dirty" word, Kristján, and I appreciate it, but you are describing a fork. Python 2.7 is the last sanctioned version of the Python 2.x series, period. Any non-bugfix changes will not go in there as policy dictates. And with there being no way Python 2.8 will happen (I know we as a group have said "slim chance" since Python 3.0 came out, uptake of Python 3 is such I am willing to personally say "never" for a python-dev sanctioned Python 2.8), that means it will take a fork, whether it be internal to CCP or public somewhere, it will still be a fork. And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine. And as pointed out by folks, once Hg kicks in and we have user repos you can even host it on hg.python.org yourself to give it some semblance of authority if you want. I understand the desire to have the final version of the Python 2.x to be as perfect as it can be, but that will never happen. Every release of Python is imperfect. There will always be mistakes we made that require incompatible changes to rectify. It's life and that's just a part of software development. I think people need to stop viewing the difference between Python 2.7 and Python 3.2 as this crazy shift and view it from python-dev's perspective; it should be viewed one follows from the other at this point. You can view it as Python 3.2 is the next version after Python 2.7 just like 2.7 followed to 2.6, which makes the policies we follow for releases make total sense and negates this discussion. It just so happens people don't plan to switch to the newest release immediately as the backward-incompatible changes are more involved than what people are used to from past releases. So to summarize, we are not changing our minds on Python 2.8; there won't be a Python 2.8 sanctioned by python-dev ever. Python 3.2 is the next version after Python 2.7 and the typical policy of bugfix/feature release rules apply as normal. People who want to iron out some inconsistencies in Python 2.7 by forking it and renaming it to prevent people from thinking python-dev made the release are welcome to and there won't be any ill will or hard feelings if that does occur. -Brett
Cheers,
Kristján
-----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com@python.org [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Barry Warsaw Sent: Friday, October 29, 2010 0:04 To: python-dev@python.org Subject: Re: [Python-Dev] Continuing 2.x
Who is the target audience for a Python 2.8? What exactly would a Python 2.8 accomplish?
If Python 2.8 doesn't include new features, well, then what's the point? Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions. So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
Brett Cannon writes:
I think people need to stop viewing the difference between Python 2.7 and Python 3.2 as this crazy shift and view it from python-dev's perspective;
That phrasing *is* harsh. People also need to work with code bases that are incompatible with Python 3.2 for various reasons, and will be very expensive to port to 3.2. Some, perhaps many, of those people *do* consider Python 3 to be the way to go, and I imaginge they are already going that way when they can. Nevertheless, their bread-and- butter projects are feeling pain; their world is going out of whack. It is a "crazy shift" (or "crazy-making" shift) for them. And for now the book writers have to feel the same way; a lot of Python-2-based applications are going to be perfectly happy to stay that way with Python 2.7 for years to come. The book writers need (as a commercial matter) to serve the new engineers who will be hired to maintain *and extend* those products. I suspect there will be a substantial market for Python 2 content in Python books until 2015 (although Mark Lutz should be able to sit back and just collect royalties on that part of his book starting in 2012).
You can view it as Python 3.2 is the next version after Python 2.7 just like 2.7 followed to 2.6,
Kristján acknowledges that. He's looking for some relief from his *current* headache. Mark's position is different. His words suggest that he thinks that Python.org owes the users something, although if pressed I imagine he'd present some argument that more users will lead to development of a better language. I think the developers universally consider that to be objectively false: Python 3 is a much better language, and is on track to be a much better environment for development -- of itself and of applications -- in 2013 than Python 2 could conceivably be.
On Oct 28, 2010, at 10:59 PM, Stephen J. Turnbull wrote:
Mark's position is different. His words suggest that he thinks that Python.org owes the users something, although if pressed I imagine he'd present some argument that more users will lead to development of a better language. I think the developers universally consider that to be objectively false: Python 3 is a much better language, and is on track to be a much better environment for development -- of itself and of applications -- in 2013 than Python 2 could conceivably be.
There is tension here. python-dev wants Python to succeed, and now Python == Python 3.x. That means end-of-lifing Python 2.x, for many reasons, not the least of which is that more Python 2.x releases are a disincentive for folks to move their projects to Python 3.x. However there are many many more users of Python 2.x than Python 3.x. Many may never upgrade for the life of these projects, because if it ain't broke, why fix it? It doesn't matter how much better Python 3 is than Python 2. It isn't better enough. I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api. In this regard the existence of Python 3 is a disadvantage, not an advantage for my new code, regardless of how much better a language or dev environment it may be. Of course I made the choice to support both 2 and 3, but it was largely informed by the fact that other dependancies for my projects currently only support Python 2 and I don't have the spare time to port them right now. So at least right now, for me, Python 3 is not helping make new projects easier, it is the contrary unfortunately. Yeah, I am getting older and the years are going by faster, but gosh 2013 still feels like a ways off. -Casey
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api.
One thing that *might* be interesting to explore for Python 3.3 would be something like `python3 --1` or some such switch that would help Python 2 code run more easily in Python 3. This might be a hook to 2to3 or other internal changes that help some of the trickier bits of writing cross-compatible code. I don't know what those things enabled by --1 would be. Some syntactic things might be fairly easy though largely inconsequential (e.g. print() -> print). It might be that large changes like bytes/string dwarfs syntactic sugar. I had a brief conversation with Michael Foord yesterday and he's writing code that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, but possible. IMHO, those are the kinds of directions we should be thinking about, to help existing code more easily make the jump to Python 3. -Barry
On Fri, Oct 29, 2010 at 12:21 PM, Barry Warsaw <barry@python.org> wrote:
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api.
One thing that *might* be interesting to explore for Python 3.3 would be something like `python3 --1` or some such switch that would help Python 2 code run more easily in Python 3. This might be a hook to 2to3 or other internal changes that help some of the trickier bits of writing cross-compatible code.
More useful IMHO would be things like "from __past__ import print_statement", still requiring some annotation of code to make it run, but less invasive than translating code itself. There's still major things you can't handle like that, but if something is syntactically acceptable in both Python 2 and 3 then it's a lot easier to apply simple conditionals around semantics. This would remove the need, for example, for people to use sys.exc_info() to avoid using "except Exception as e". -- Ian Bicking | http://blog.ianbicking.org
That's a much better idea! Sent from my digital lollipop. On Oct 29, 2010, at 3:31 PM, Ian Bicking <ianb@colorstudy.com> wrote:
On Fri, Oct 29, 2010 at 12:21 PM, Barry Warsaw <barry@python.org> wrote: On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api.
One thing that *might* be interesting to explore for Python 3.3 would be something like `python3 --1` or some such switch that would help Python 2 code run more easily in Python 3. This might be a hook to 2to3 or other internal changes that help some of the trickier bits of writing cross-compatible code.
More useful IMHO would be things like "from __past__ import print_statement", still requiring some annotation of code to make it run, but less invasive than translating code itself. There's still major things you can't handle like that, but if something is syntactically acceptable in both Python 2 and 3 then it's a lot easier to apply simple conditionals around semantics. This would remove the need, for example, for people to use sys.exc_info() to avoid using "except Exception as e".
-- Ian Bicking | http://blog.ianbicking.org
2010/10/29 Barry Warsaw <barry@python.org>:
I had a brief conversation with Michael Foord yesterday and he's writing code that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, but possible.
If the application does not involve a lot of I/O, 2.4 -> 3.2 support by using a unique code base is possible and not that ugly. At least, that's what happened with psutil: http://code.google.com/p/psutil/issues/detail?id=75&can=1&q=python%203&colspec=ID%20Summary%20Type%20Opsys%20Status%20Milestone%20Opened%20Owner%20Progress#c9 My personal choice is to encourage the same approach where possible. Regards, --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil
Barry Warsaw wrote:
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
I like Python 3, I am using it for my latest projects, but I am also keeping Python 2 compatibility. This incurs some overhead, and basically means I am still really only using Python 2 features. So in some respects, my Python 3.x support is only tacit, it works as well as for Python 2, but it's not taking advantage of Python 3 really. I haven't run into a situation yet where I really want to or have to use Python 3 exclusive features, but then again I'm not really learning to use Python 3 either, short of the new C api.
One thing that *might* be interesting to explore for Python 3.3 would be something like `python3 --1` or some such switch that would help Python 2 code run more easily in Python 3. This might be a hook to 2to3 or other internal changes that help some of the trickier bits of writing cross-compatible code.
I don't know what those things enabled by --1 would be. Some syntactic things might be fairly easy though largely inconsequential (e.g. print() -> print). It might be that large changes like bytes/string dwarfs syntactic sugar. I had a brief conversation with Michael Foord yesterday and he's writing code that works in 2.4 through 3.2, so for *some* code bases, it's tricky and ugly, but possible.
IMHO, those are the kinds of directions we should be thinking about, to help existing code more easily make the jump to Python 3.
+1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
Casey Duncan writes:
However there are many many more users of Python 2.x than Python 3.x. Many may never upgrade for the life of these projects, because if it ain't broke, why fix it? It doesn't matter how much better Python 3 is than Python 2. It isn't better enough.
And the "don't fix what ain't broke" people are well supported, by explicit policy and by the personal dedication of developers like Victor Stinner.
In this regard the existence of Python 3 is a disadvantage, not an advantage for my new code, regardless of how much better a language or dev environment it may be.
You mean, at this very instant. Pay now, profit later is the definition of "investment." In the past, while I'm sure you worked real hard, you didn't have to pay the price of the *community's* investment because you were free to start new projects in the way best fitted to current features. Now, with a large codebase to maintain and extend, you have to share the community's costs by either living with Python 2, which won't improve from now on, or shifting to Python 3, which entails big porting costs for many projects.[1] Or you can participate in a new project to fork from python.org and continue development of Python 2. You have a wealth of choice there. The problem[2] is that you're not getting a free ride on the fast track this time. Well, that party was nice while it lasted, but now it's over. The next party is going to be at the Python 3 Lounge, and you're invited. Sure, you gotta get up and go to work tomorrow, but Friday's comin'! Footnotes: [1] But I can't say it's obvious that they're huge on average. There's clearly a lot of variance in porting costs. [2] This is a community problem; it's not something you did to yourself. But it's also been judged unavoidable if Python is to continue to grow.
On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote:
I think people need to stop viewing the difference between Python 2.7 and Python 3.2 as this crazy shift and view it from python-dev's perspective; it should be viewed one follows from the other at this point. You can view it as Python 3.2 is the next version after Python 2.7 just like 2.7 followed to 2.6, which makes the policies we follow for releases make total sense and negates this discussion. It just so happens people don't plan to switch to the newest release immediately as the backward-incompatible changes are more involved than what people are used to from past releases.
Brett, with all due respect, this is not a reasonable position. You are making it sound like the popular view of 3.2 is a "crazy shift" is based on a personal dislike of python-dev or something. The fact is that the amount of effort required to port to 3.2 is extreme compared to previous upgrades, and most people still aren't willing to deal with it. It is a crazy shift. Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Let's say that 20% of the code on PyPI is just junk; it's unfair to expect 100% of all code ever to get ported. But, still: with this back-of-the-envelope estimate of the rate of porting, it will take over 50 years before a decisive majority of Python code is on Python 3. By contrast, there are 536 packages with ::2.6, and 177 with ::2.7. (Trying to compare apples to apples here, since I assume the '2' tag is much more lightly used than '3' to identify supported versions; I figure someone likely to tag one micro-version would also tag the other.) 2.7 was released on July 3rd, so let's be generous and say approximately 6 months. That's 30% of packages, ported in 6 months, or 60% per year. This means that Python 3 is two orders of magnitude crazier of a shift than 2.7. I know that the methods involved at arriving at these numbers are not particularly good. But, I think that if their accuracy differs from that of the download stats, it's better: it takes a much more significant commitment to actually write some code and upload it than to accidentally download 3.x because it's the later version. Right now, Kristján is burning off his (non-fungible) enthusiasm in this discussion rather than addressing more 2.x maintenance issues. If 3.x adoption takes off and makes a nice hockey stick graph, then few people will care about this in retrospect. In the intervening hypothetical half-century while we wait to see how it pans out, isn't it better to just have an official Python branch for the "maybe 2.8" release? Nobody from the current core team needs to work on it, necessarily; either other, new maintainers will show up or they won't. For that matter, Kristján is still talking about porting much of his work to 3.x anyway. In the best case (3.x takes over the world in 6 months) a 2.x branch won't be needed and nobody will show up to do the work of a release; some small amount of this work (the stuff not ported to 3.x) will be lost. In the medium case (3.x adoption is good, but there are still millions of 2.x users in 5 years) it will accumulate some helpers that will make migrating to 3.x even smoother than with 2.7. In the worst case (straw man: 3.x adoption actually declines, and distros start maintaining their own branches of 2.7) I'm sure everyone will be glad that some of this maintenance effort took place and there's some central place to continue it. I'm perfectly willing to admit that I'm still too pessimistic about this and I could be wrong. But given the relatively minimal amount of effort required to let 2.x bugs continue to get fixed under the aegis of Python.org rather than going through the painful negotiation process of figuring out where else to host it (and thereby potentially losing a bunch of maintenance that would not otherwise happen), it seems foolhardy to insist that those of us who think 2.x is going to necessitate another release must necessarily be wrong.
On Fri, 29 Oct 2010 02:55:55 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Let's say that 20% of the code on PyPI is just junk; it's unfair to expect 100% of all code ever to get ported. But, still: with this back-of-the-envelope estimate of the rate of porting, it will take over 50 years before a decisive majority of Python code is on Python 3.
Well, no. A decisive majority would be much smaller than that. There are probably between 2% and 5% of the CheeseShop entries which are widely used dependencies. When these 2 to 5% all get ported, you have a decisive majority. Yes, perhaps more than 50% of 2.x code will never get ported. But, perhaps more than 50% of 1.5.2 code never got upgraded either. That doesn't make it any decisive; just dead (or pining for security fixes in some old rusty "RedHat Enterprise Linux" server, if you prefer).
Right now, Kristján is burning off his (non-fungible) enthusiasm in this discussion rather than addressing more 2.x maintenance issues.
By the same argument, we are also burning off our (non-fungible) enthusiasm trying to answer people like you and Kristján. Perhaps we should stop answering you and instead concentrate on improving 3.x? ;) Regards Antoine.
On Fri, 2010-10-29 at 09:11 +0200, Antoine Pitrou wrote:
On Fri, 29 Oct 2010 02:55:55 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Let's say that 20% of the code on PyPI is just junk; it's unfair to expect 100% of all code ever to get ported. But,
still:
with this back-of-the-envelope estimate of the rate of porting, it will take over 50 years before a decisive majority of Python code is on Python 3.
Well, no. A decisive majority would be much smaller than that. There are probably between 2% and 5% of the CheeseShop entries which are widely used dependencies. When these 2 to 5% all get ported, you have a decisive majority.
Yes, perhaps more than 50% of 2.x code will never get ported. But, perhaps more than 50% of 1.5.2 code never got upgraded either. That doesn't make it any decisive; just dead (or pining for security fixes in some old rusty "RedHat Enterprise Linux" server, if you prefer).
Ouch! Having spent much of the last week doublechecking fixes for CVEs in the builds of python 2.2, 2.3 and 2.4 in the various older RHEL releases, that cuts deep :) Red Hat's security team monitors vulnerabilities in Python, and we do continue to support these releases in the context of our products, even though they're no longer supported by the wider Python development community. As with the the security work done by python-dev on the more up-to-date Python releases, it's tedious and painstaking work (we do have customers paying us to do it, though) If you have concerns about specific security flaws that may affect the older releases of python that are no longer supported by python.org but are within a product supported by Red Hat, please email secalert@redhat.com See: https://www.redhat.com/security/team/contact/ for more information. Hope this is helpful Dave
Right now, Kristján is burning off his (non-fungible) enthusiasm in this discussion rather than addressing more 2.x maintenance issues. If 3.x adoption takes off and makes a nice hockey stick graph, then few people will care about this in retrospect. In the intervening hypothetical half-century while we wait to see how it pans out, isn't it better to just have an official Python branch for the "maybe 2.8" release? Nobody from the current core team needs to work on it, necessarily; either other, new maintainers will show up or they won't. For that matter, Kristján is still talking about porting much of his work to 3.x anyway.
That might be - however, I think it is (now) clear that talking about this on python-dev isn't going to make it happen, at least not now. Nobody has really stepped forward to manage a Python 2.8 project; more specifically, Kristjan explicitly said that he will *not* do a Python 2.8 release. As Brett (IMHO correctly) analyzed: Kristjan wants a fork, a place where he can publish his Python changes. Not sure if anybody else has that desire, but if so, these people should get together and set something up. As for the specific implementation of the fork: people proposed that Kristjan should wait for the hg switchover, and can then easily host the fork anywhere (e.g. on bitbucket, or as a private clone on python.org). Assuming there are other contributors (outside of python-committers) to this fork as well, hosting it on bitbucket is probably easier since it will allow to give push permissions to non-core committers.
I'm perfectly willing to admit that I'm still too pessimistic about this and I could be wrong. But given the relatively minimal amount of effort required to let 2.x bugs continue to get fixed under the aegis of Python.org
I think here you are strongly mistaken. It is not a relatively minimal effort. Having to support another branch would be very very painful.
it seems foolhardy to insist that those of us who think 2.x is going to necessitate another release must /necessarily/ be wrong.
Predictions are always difficult to make. It may be that 2.x will necessitate another release (by some criteria), but I truly hope that you are wrong in predicting that such a release will actually happen. Regards, Martin
On Fri, 29 Oct 2010 02:55:55 -0400, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
I'm perfectly willing to admit that I'm still too pessimistic about this and I could be wrong. But given the relatively minimal amount of effort required to let 2.x bugs continue to get fixed under the aegis of Python.org rather than going through the painful negotiation process of figuring out where else to host it (and thereby potentially losing a bunch of maintenance that would not otherwise happen), it seems foolhardy to insist that those of us who think 2.x is going to necessitate another release must necessarily be wrong.
Your argument was interesting, but you conclude by talking only about bugs. We are continuing to bugfix 2.x in the form of 2.7 bugfix releases. If at the end of the five years the 2.x user community is large enough that additional *bugfix* releases of 2.7 are worth the effort, we will, I'm sure, continue to produce them. What *new features* are needed in 2.x? I think the effort required to set up and maintain a fork is a good measure of whether or not such features are *valuable enough* to be worth doing. If they are, someone will do it. If not....not. -- R. David Murray www.bitdance.com
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote:
I think people need to stop viewing the difference between Python 2.7 and Python 3.2 as this crazy shift and view it from python-dev's perspective; it should be viewed one follows from the other at this point. You can view it as Python 3.2 is the next version after Python 2.7 just like 2.7 followed to 2.6, which makes the policies we follow for releases make total sense and negates this discussion. It just so happens people don't plan to switch to the newest release immediately as the backward-incompatible changes are more involved than what people are used to from past releases.
Brett, with all due respect, this is not a reasonable position. You are making it sound like the popular view of 3.2 is a "crazy shift" is based on a personal dislike of python-dev or something. The fact is that the amount of effort required to port to 3.2 is extreme compared to previous upgrades, and most people still aren't willing to deal with it. It is a crazy shift. Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Let's say that 20% of the code on PyPI is just junk; it's unfair to expect 100% of all code ever to get ported. But, still: with this back-of-the-envelope estimate of the rate of porting, it will take over 50 years before a decisive majority of Python code is on Python 3. By contrast, there are 536 packages with ::2.6, and 177 with ::2.7. (Trying to compare apples to apples here, since I assume the '2' tag is much more lightly used than '3' to identify supported versions; I figure someone likely to tag one micro-version would also tag the other.)
Just my two cents: First off, unless you have a lot of information I don't, there's no reason at all to believe that Python3's adoption will be linear- if anything it seems very likely to be a power law curve, just like the adoption trends we see for other software projects. Secondly, speaking of power law curves, not all packages on PyPI are equally important as measured by downloads. If even the top 2% of most downloaded projects on PyPI got ported to Python3 it would represent a majority of downloads, and that pattern seems consistent with what you see in other software repositories. The net result of this is that even if you're right and the growth is linear AND the 1.5% statistic is accurate- again, I doubt it- it is conceivable that within two years an overwhelming majority of downloads of Python software could be of projects with full Python3 support. From a user perspective that's fairly close to indistinguishable from a community-wide transition to Python3. Thirdly, only counting PyPI is probably not a very good way to measure popularity in the wider community, as PyPI's overall usage is fairly small. Just to name a few examples, sqlalchemy had been pulled just 2,000 times from PyPI, but 86,000 times from Ubuntu's repo, pyparsing had just 295 downloads on PyPI but 62,000 from Ubuntu, etc. With a few exceptions- especially modules that pride themselves on being pure Python- this is pretty indicative of the general relationship between PyPI and these other repositories. I don't know how the adoption rate figures would look if we took those into account, but if you want to portray the trend accurately that's something you're likely to have to do. So, to cut down a long-winded and overly pedantic response: I'm pretty sure that you're not going to get accurate estimates out of that methodology, assuming that accurate results are what you're after. Geremy Condra
On Fri, Oct 29, 2010 at 11:12 AM, geremy condra <debatem1@gmail.com> wrote:
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote:
[snip]
First off, unless you have a lot of information I don't, there's no reason at all to believe that Python3's adoption will be linear- if anything it seems very likely to be a power law curve, just like the adoption trends we see for other software projects.
[snip] Just a correction, I'm predicting that Python3's adoption will be exponential and that it's popularity relative to other software projects will move up according to a power law curve, not that it's overall adoption will be power law. Thanks for pointing this out, Titus. Geremy Condra
On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote:
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz
Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Just my two cents:
Just one further informational note about using pypi in this way for statistics... In the porting work we've done within Fedora, I've noticed that a lot of packages are python3 ready or even officially support python3 but the language classifier on pypi does not reflect this. Here's just a few since I looked them up when working on the python porting wiki pages: http://pypi.python.org/pypi/Beaker/ http://pypi.python.org/pypi/pycairo http://pypi.python.org/pypi/docutils -Toshio
On 10/29/2010 2:41 PM, Toshio Kuratomi wrote:
On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote:
On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz
Let's take PyPI numbers as a proxy. There are ~8000 packages with a "Programming Language::Python" classifier. There are ~250 with "Programming Langauge::Python::3". Roughly speaking, we can say that is 3% of Python code which has been ported so far. Python 3.0 was released at the end of 2008, so people have had roughly 2 years to port, which comes up with 1.5% per year. Just my two cents:
Just one further informational note about using pypi in this way for statistics... In the porting work we've done within Fedora, I've noticed that a lot of packages are python3 ready or even officially support python3 but the language classifier on pypi does not reflect this. Here's just a few since I looked them up when working on the python porting wiki pages:
http://pypi.python.org/pypi/Beaker/ http://pypi.python.org/pypi/pycairo http://pypi.python.org/pypi/docutils
If you could (successfully) encourage the authors of such packages to update their PyPI classifiers, I and other Python 3 users would greatly appreciate it. That is aside from having better data for this and similar discussions. -- Terry Jan Reedy
Brett Cannon wrote:
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go.
It's called a fork. I realize you are trying to avoid that "dirty" word, Kristján, and I appreciate it, but you are describing a fork. Python 2.7 is the last sanctioned version of the Python 2.x series, period. Any non-bugfix changes will not go in there as policy dictates. And with there being no way Python 2.8 will happen (I know we as a group have said "slim chance" since Python 3.0 came out, uptake of Python 3 is such I am willing to personally say "never" for a python-dev sanctioned Python 2.8), that means it will take a fork, whether it be internal to CCP or public somewhere, it will still be a fork.
And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine.
I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series. It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
2010/10/29 M.-A. Lemburg <mal@egenix.com>:
Brett Cannon wrote:
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go.
It's called a fork. I realize you are trying to avoid that "dirty" word, Kristján, and I appreciate it, but you are describing a fork. Python 2.7 is the last sanctioned version of the Python 2.x series, period. Any non-bugfix changes will not go in there as policy dictates. And with there being no way Python 2.8 will happen (I know we as a group have said "slim chance" since Python 3.0 came out, uptake of Python 3 is such I am willing to personally say "never" for a python-dev sanctioned Python 2.8), that means it will take a fork, whether it be internal to CCP or public somewhere, it will still be a fork.
And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine.
I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series.
He's not saying we shouldn't welcome them; we just don't want to it attached to python-dev. -- Regards, Benjamin
Benjamin Peterson wrote:
2010/10/29 M.-A. Lemburg <mal@egenix.com>:
Brett Cannon wrote:
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
I'm not sure what I'm actually proposing. But I certainly wasn't thinking of a new "fork" of python. And not a new version 2.8 that gets all new 3.x features backported. I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go.
It's called a fork. I realize you are trying to avoid that "dirty" word, Kristján, and I appreciate it, but you are describing a fork. Python 2.7 is the last sanctioned version of the Python 2.x series, period. Any non-bugfix changes will not go in there as policy dictates. And with there being no way Python 2.8 will happen (I know we as a group have said "slim chance" since Python 3.0 came out, uptake of Python 3 is such I am willing to personally say "never" for a python-dev sanctioned Python 2.8), that means it will take a fork, whether it be internal to CCP or public somewhere, it will still be a fork.
And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine.
I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series.
He's not saying we shouldn't welcome them; we just don't want to it attached to python-dev.
That new team could be part of python-dev, couldn't it ? Not necessarily the mailing list, but the team of Python developers. Much like the (new) py3k developers joined in when that project was kicked off. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
2010/10/29 M.-A. Lemburg <mal@egenix.com>:
Benjamin Peterson wrote:
He's not saying we shouldn't welcome them; we just don't want to it attached to python-dev.
That new team could be part of python-dev, couldn't it ? Not necessarily the mailing list, but the team of Python developers. Much like the (new) py3k developers joined in when that project was kicked off.
Perhaps, but it would debatable how much infrastructure (ie buildbots, tracker) would be available to them. -- Regards, Benjamin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/2010 10:21 AM, Benjamin Peterson wrote:
2010/10/29 M.-A. Lemburg <mal@egenix.com>:
Benjamin Peterson wrote:
He's not saying we shouldn't welcome them; we just don't want to it attached to python-dev.
That new team could be part of python-dev, couldn't it ? Not necessarily the mailing list, but the team of Python developers. Much like the (new) py3k developers joined in when that project was kicked off.
Perhaps, but it would debatable how much infrastructure (ie buildbots, tracker) would be available to them.
"Infrastructure" sounds to me like code for "money". How much of the PSF's money, for instance, comes from organizations whose primary interest is still Python2? How many of them are only or principally only interested in Python3? Then again, how much of the PSF's budget goes toward infrastructure? (I honestly don't know the answers to any of these questions). For "donated" infrastructure, surely the individuals providing CPU / bandwidth / diskspace make that call, and not python-dev. If a new retro-fork development community emerges, its members will include folks who have a vested interest in continuing Python 2.x development, and hence can donate (or recruit) such in-kind contributions. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzK9LEACgkQ+gerLs4ltQ5obQCdEaSgkZ+vG8RlzCHQTzhLEyCb jkYAn00pBS0aPZ0AS05hKqbP3/TpA4pb =AHme -----END PGP SIGNATURE-----
"Infrastructure" sounds to me like code for "money".
No, it's rather "volunteer time". Of course, people keep proposing that this should be replaced by hired time that gets paid from donations, but all such proposals so far got stuck at implementation details (i.e. it's actual work that nobody has done).
How much of the PSF's money, for instance, comes from organizations whose primary interest is still Python2? How many of them are only or principally only interested in Python3? Then again, how much of the PSF's budget goes toward infrastructure?
The first two questions are difficult to answer: the PSF doesn't maintain records of what Python versions are of primary interest to sponsor members. A significant portion of the donations comes from the conference surplus (being saved for the also-likely risk of a massive conference loss); in this case, it's even difficult to identify the donors (as you can't really attribute the surplus to being from, say, attendee fees, as opposed to conference sponsors). As for the budget that goes into infrastructure: you'll find the details in the treasurer reports, but it is comparatively minor and goes primarily into hardware purchases. Connectivity and colocation is donated by companies who may not have an actual interest in Python at all (e.g. XS4ALL, which do this out of a general support for free software and in positive recollection of their former employee Thomas Wouters).
For "donated" infrastructure, surely the individuals providing CPU / bandwidth / diskspace make that call, and not python-dev.
Yes, and I have already stated my opinion. Other pydotorg'ers will surely voice their opinion when they get asked to help. Regards, Martin
On Fri, Oct 29, 2010 at 06:57:54PM +0200, "Martin v. L?wis" wrote:
"Infrastructure" sounds to me like code for "money".
No, it's rather "volunteer time". Of course, people keep proposing that this should be replaced by hired time that gets paid from donations, but all such proposals so far got stuck at implementation details (i.e. it's actual work that nobody has done).
How much of the PSF's money, for instance, comes from organizations whose primary interest is still Python2? How many of them are only or principally only interested in Python3? Then again, how much of the PSF's budget goes toward infrastructure?
The first two questions are difficult to answer: the PSF doesn't maintain records of what Python versions are of primary interest to sponsor members. A significant portion of the donations comes from the conference surplus (being saved for the also-likely risk of a massive conference loss); in this case, it's even difficult to identify the donors (as you can't really attribute the surplus to being from, say, attendee fees, as opposed to conference sponsors).
As for the budget that goes into infrastructure: you'll find the details in the treasurer reports, but it is comparatively minor and goes primarily into hardware purchases. Connectivity and colocation is donated by companies who may not have an actual interest in Python at all (e.g. XS4ALL, which do this out of a general support for free software and in positive recollection of their former employee Thomas Wouters).
I'd just like to add my 2c that AFAICT the volunteer effort that goes into Python, and in particular into python-dev and the infrastructure foo, absolutely *dwarfs* all other aspects of "official" Python and PSF (including $$ in all forms). So, good job, -dev guys! But they're already pretty overwhelmed. Independent of talk, unless there's a proposal to continue 2.x that actually involves someone *new* stepping up to put in hugely substantial and ridiculously large amounts of seriously expert time, I don't see the point of talking about it. cheers, --titus p.s. I would be happy to enter into discussions on how to clone Martin and others, though. I just need some epithelial cells, I think. And about $20 bn dollars, and relocation to Israel (which I think has the best combination of tech and human use guidelines for cloning). Martin's permission is not *strictly* necessary but should probably be obtained, too. p.p.s. The PSF isn't foolish enough to let me speak for them, in case anyone is wondering. -- C. Titus Brown, ctb@msu.edu
It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ?
I propose to stop this discussion of theoretical projects, and only restart it when someone actually proposes to lead such a project. I might not personally stop anybody from doing such a project, but I surely will not support him. This thread was started by a specific proposal from Kristjan, and Kristjan got a specific suggestion on how to proceed (namely, wait for the Mercurial switchover, then publish his changes in a branch). So despite the more general subject (which I think is still mostly hypothetical), the real issue Kristjan raised has been resolved, AFAICT (although Kristjan has not yet voiced an opinion of whether he finds that resolution acceptable). Regards, Martin
"Martin v. Löwis" wrote:
It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ?
I propose to stop this discussion of theoretical projects, and only restart it when someone actually proposes to lead such a project.
Fair enough. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 29 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
I have a specific, easy to implement proposal. I would like one more version tag added to the Roundup tracker. My proposed name is "Python 2.7+" but I don't care what it is called. It would be used to tag bug reports and patches that apply only to the 2.x line and are considered not appropriate for the 2.7.x release. In order to keep them out of the way, I suppose they could be marked as "postponed" and closed. It's possible that no one will step up to handle these issues and integrate them into a Python 2.7+ release (official or fork). However, given the cost to add such a tag, I think it would be a shame to lose the manpower used to produce such bug reports and patches. Neil
On 10/30/2010 6:32 PM, Neil Schemenauer wrote:
I have a specific, easy to implement proposal. I would like one more version tag added to the Roundup tracker. My proposed name is "Python 2.7+" but I don't care what it is called.
As a tracker gardener, I disagree. I would expect such to cause more trouble than it is worth.
It would be used to tag bug reports and patches that apply only to the 2.x line and are considered not appropriate for the 2.7.x release.
Bug reports *are* appropriate.
In order to keep them out of the way, I suppose they could be marked as "postponed" and closed.
The few issues that would get such a 2.7+ tag can just as well be marked 2.7/closed/postponed.
It's possible that no one will step up to handle these issues
Which would make new the version tag YAGNI -- Terry Jan Reedy
On Sun, Oct 31, 2010 at 10:41 AM, Terry Reedy <tjreedy@udel.edu> wrote:
The few issues that would get such a 2.7+ tag can just as well be marked 2.7/closed/postponed.
Using closed+postponed as the resolution for 2.x specific feature requests sounds fine. Feature requests that are also applicable to 3.x can just be bumped to refer to the in-development 3.x version (with beta 1 less than 2 weeks away, that will typically be 3.3 now). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I've been sitting on the sideline seeing this unfold. We've seen some different viewpoints on the matter and I'm happy to see that I'm not the only one lamenting the proclaimed death of the 2.x linage. However, As correctly stated by Martin, I merely voiced a suggestion and I have gotten helpful counter-suggestions. A private branch is fine (More correctly a fork, even, as people have pointed out) and Hg is going to support user-branches. In the meantime, however, unless someone strongly objects, I'm probably going to set up a temporary branch off /release27-maint under /stackless/sandboxes/ until the Hg switchover. Name undecided yet. Cheers, Kristján
-----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com@python.org [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of "Martin v. Löwis" Sent: 29. október 2010 22:13 This thread was started by a specific proposal from Kristjan, and Kristjan got a specific suggestion on how to proceed (namely, wait for the Mercurial switchover, then publish his changes in a branch). So despite the more general subject (which I think is still mostly hypothetical), the real issue Kristjan raised has been resolved, AFAICT (although Kristjan has not yet voiced an opinion of whether he finds that resolution acceptable).
2010/11/1 Kristján Valur Jónsson <kristjan@ccpgames.com>:
I've been sitting on the sideline seeing this unfold. We've seen some different viewpoints on the matter and I'm happy to see that I'm not the only one lamenting the proclaimed death of the 2.x linage. However, As correctly stated by Martin, I merely voiced a suggestion and I have gotten helpful counter-suggestions. A private branch is fine (More correctly a fork, even, as people have pointed out) and Hg is going to support user-branches. In the meantime, however, unless someone strongly objects, I'm probably going to set up a temporary branch off /release27-maint under /stackless/sandboxes/ until the Hg switchover. Name undecided yet.
No objection from me; branches in svn are for experimental stuff and this is what you are proposing. -Brett
Cheers, Kristján
-----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com@python.org [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of "Martin v. Löwis" Sent: 29. október 2010 22:13 This thread was started by a specific proposal from Kristjan, and Kristjan got a specific suggestion on how to proceed (namely, wait for the Mercurial switchover, then publish his changes in a branch). So despite the more general subject (which I think is still mostly hypothetical), the real issue Kristjan raised has been resolved, AFAICT (although Kristjan has not yet voiced an opinion of whether he finds that resolution acceptable).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On 10/29/2010 9:42 AM, M.-A. Lemburg wrote:
I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series.
Given the number of issues on the tracker, I think it would be great if there were some new 2.7-focused developers that would work on fixing 2.7-specific bugs and helping with fixes (including by backporting) to 2.7/3.x bugs.
It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ?
Where is such a team? It is a moot point until they show up. As to a possible successor to 2.7: this seems hardly worth discussing until 1) 2.7 has been out for at year and maybe more; 2) there actually are such new developers working on 2.7 maintenance; and 3) there actually is a proposal to respond to. If new features were limited to backports of features in 3.x, especially in the library, then I *personally* could see something being released as 'python 2.8'. I will be surprised it these preconditions come about. I suspect that most 2.7 users and most *nix distributions would be happy to have a stable increasingly de-bugged 2.7 be Python 2 for several years. -- Terry Jan Reedy
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs. Sent from my digital lollipop. On Oct 29, 2010, at 3:38 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 10/29/2010 9:42 AM, M.-A. Lemburg wrote:
I don't see why we should not welcome a team of new developers who want to continue working on the 2.x series.
Given the number of issues on the tracker, I think it would be great if there were some new 2.7-focused developers that would work on fixing 2.7-specific bugs and helping with fixes (including by backporting) to 2.7/3.x bugs.
It's obvious that a large proportion of the existing python-dev'ers will not participate in such a project, but why should we try to stop someone else to work on it ?
Where is such a team? It is a moot point until they show up.
As to a possible successor to 2.7: this seems hardly worth discussing until 1) 2.7 has been out for at year and maybe more; 2) there actually are such new developers working on 2.7 maintenance; and 3) there actually is a proposal to respond to. If new features were limited to backports of features in 3.x, especially in the library, then I *personally* could see something being released as 'python 2.8'.
I will be surprised it these preconditions come about. I suspect that most 2.7 users and most *nix distributions would be happy to have a stable increasingly de-bugged 2.7 be Python 2 for several years.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/barry%40python.org
On Fri, 29 Oct 2010 15:54:19 -0400 Barry Warsaw <barry@python.org> wrote:
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs.
Why would it only apply to 2.7? Regards Antoine.
It certainly doesn't have to. Sent from my digital lollipop. On Oct 29, 2010, at 4:06 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 29 Oct 2010 15:54:19 -0400 Barry Warsaw <barry@python.org> wrote:
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs.
Why would it only apply to 2.7?
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/barry%40python.org
2010/10/29 Barry Warsaw <barry@python.org>:
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs.
At the moment, I'm planning to do regular maintenance releases for 3.1 and 2.7 roughly every 6 months. -- Regards, Benjamin
On Oct 29, 2010, at 04:23 PM, Benjamin Peterson wrote:
At the moment, I'm planning to do regular maintenance releases for 3.1 and 2.7 roughly every 6 months.
Cool. The actual interval doesn't matter as much as the regularity. I say that speaking as a semi-former RM who sadly didn't adhere to much regularity. ;/ Cheers, -Barry
Am 29.10.2010 21:54, schrieb Barry Warsaw:
Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs.
Ah, timed releases :-) I know this is bike-shedding, but PY_MINOR_VERSION has never used two digits, so far. More seriously - I think that monthly releases would be a *dis-service* to users, and I base that on personal experience with both Bazaar, and TortoiseSVN. For less-than-daily users, the user experience will be that they should upgrade their installation *every* time they want to use it. People providing support will always ask "are you using the latest version", to which the answer will be "of course not, I am using an installation that is five weeks old". Regards, Martin
On 02:51 am, brett@python.org wrote:
2010/10/28 Kristj�n Valur J�nsson <kristjan@ccpgames.com>:
Hi all. This has been a lively discussion. My desire to keep 2.x alive in some sense is my own and I don't know if anyone shares it but as a member of this community I think I'm allowed to voice it. �So, just to clarify my particular position, let me explain where all this comes from. [snip]
And as everyone has said so far (and with which I agree), that's fine. As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty Python reference -- then that's fine. And as pointed out by folks, once Hg kicks in and we have user repos you can even host it on hg.python.org yourself to give it some semblance of authority if you want.
In case anyone was discouraged by the idea that a 2.x continuation would not be allowed to bear the name "Python" as Brett suggests here, I want to make a clarification. Brett is speaking for himself here (and he never claimed otherwise!). However, decisions about where to allow the use of the "Python" trademark are made by the Python Software Foundation. The PSF has not decided to reject any request by a 2.x continuation project to use the name "Python". Of course, this does not mean they would necessarily allow such a use. I just wanted to point out that they have not categorically rejected it, as one might be tempted to infer from Brett's message. Jean-Paul
On Fri, 29 Oct 2010 16:41:19 -0000 exarkun@twistedmatrix.com wrote:
Brett is speaking for himself here (and he never claimed otherwise!). However, decisions about where to allow the use of the "Python" trademark are made by the Python Software Foundation.
The point is not to allow the use of a trademark ("EVE-Python" is already an use of the trademark, as are "IronPython", "Cython", "VPython", etc.), it is to respect the original project and to keep things clear. Even if there were no trademark, I think it would be wrong for a separate project to adopt the same name without agreement from the original group of contributors. I have never seen a fork which didn't change the name of the project. Regards Antoine.
On Fri, 29 Oct 2010 10:10:31 +0800 Kristján Valur Jónsson <kristjan@ccpgames.com> wrote:
What finally drove me to write the original post, was that working with the new bytearray and memoryview object in 2.7 made me realize that they don't interoperate with other classes in a natural way and so nullify their advantages. My straightforward patches to 2.7 to remedy this situation (issues 10211 and 10212) were met with the usual "it's not a bugfix" reply.
For the record, and that's not because you are using it here as an argument, I misevaluated issue 10212. I thought you wanted to make cStringIO objects *provide* the buffer protocol. Actually, your patch simply makes it *accept* new buffer-compliant objects in places where it already accepts old buffer-compliant objects (such as the write() method). There is then much less contention against letting the patch in (provided it gets reviewed :-)). That doesn't change the rest of your argument, though; and I agree with other people's voiced opinions that what you are proposing ("usability improvements", etc.) is what we usually consider a new feature, in QA terms. Regards Antoine.
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Hello all. So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python?
The answer would seem to be “one doesn’t”. But must it be that way?
When python-dev chose to switch our own focus for new features to 3.x only, we were quite aware that a new group forming to continue with 2.8 was a definite possibility. If you do decide to go ahead with the idea, I have a few suggestions: 1. Since the distinguishing feature is that this branch is a 2.x version that will accept new features, in contrast to the python-dev maintained bugfix-only 2.7 maintenance branch, please call the branch something-or-other-2.8, rather than any form of 2.7. 2. Check with Benjamin how he plans to handle 2.7 maintenance releases. If he plans to release from SVN, use that as your upstream master. If 2.7.1 will instead be released from hg.python.org, wait until the switch happens then use the relevant hg branch as the upstream. 3. Choose your target audience early (if the target is only developers with existing 2.x installations that can build their own version of Python, then that simplifies release management significantly, since you don't need to build binaries any more). 4. Decide whether or not you need a buildbot farm (this relates to point 3: you may choose to limit your audience to people that are happy to run the test suite themselves on their own target platforms of interest). 5. Give some thought to how you will handle controversial design decisions (since you won't have the fallback of appealing to the BDFL, and feedback from python-dev is likely to be limited). 6. Asking for a python-org SIG mailing list may be a reasonable idea as well (e.g. py2x-sig) 7. As 3.x usage grows, such a group may have a vested interest in helping with 3to2 development as well as simplifying backporting of 3.x extension modules to 2.x. A 2.8 branch that sells itself as being suitable only for people willing to run their own builds and QA could definitely have a place in the world (CCP at least would obviously find it useful, but I wouldn't be surprised to find other companies that might consider adopting such a branch if the benefits of the new features over the official 2.7 releases were sufficiently compelling). I don't believe anyone here is implacably opposed to the idea of 2.8 development continuing - it's just that the "collective we" of python-dev isn't interested in making it happen, so a new crop of developers will need to step up if it is going to become more than a CCP-specific 2.x fork. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/2010 09:33 AM, Nick Coghlan wrote:
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Hello all. So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python?
The answer would seem to be “one doesn’t”. But must it be that way?
When python-dev chose to switch our own focus for new features to 3.x only, we were quite aware that a new group forming to continue with 2.8 was a definite possibility. If you do decide to go ahead with the idea, I have a few suggestions:
1. Since the distinguishing feature is that this branch is a 2.x version that will accept new features, in contrast to the python-dev maintained bugfix-only 2.7 maintenance branch, please call the branch something-or-other-2.8, rather than any form of 2.7. 2. Check with Benjamin how he plans to handle 2.7 maintenance releases. If he plans to release from SVN, use that as your upstream master. If 2.7.1 will instead be released from hg.python.org, wait until the switch happens then use the relevant hg branch as the upstream. 3. Choose your target audience early (if the target is only developers with existing 2.x installations that can build their own version of Python, then that simplifies release management significantly, since you don't need to build binaries any more). 4. Decide whether or not you need a buildbot farm (this relates to point 3: you may choose to limit your audience to people that are happy to run the test suite themselves on their own target platforms of interest). 5. Give some thought to how you will handle controversial design decisions (since you won't have the fallback of appealing to the BDFL, and feedback from python-dev is likely to be limited). 6. Asking for a python-org SIG mailing list may be a reasonable idea as well (e.g. py2x-sig) 7. As 3.x usage grows, such a group may have a vested interest in helping with 3to2 development as well as simplifying backporting of 3.x extension modules to 2.x.
A 2.8 branch that sells itself as being suitable only for people willing to run their own builds and QA could definitely have a place in the world (CCP at least would obviously find it useful, but I wouldn't be surprised to find other companies that might consider adopting such a branch if the benefits of the new features over the official 2.7 releases were sufficiently compelling).
I don't believe anyone here is implacably opposed to the idea of 2.8 development continuing - it's just that the "collective we" of python-dev isn't interested in making it happen, so a new crop of developers will need to step up if it is going to become more than a CCP-specific 2.x fork.
Thanks for the helpful guidance to such prospective volunteers! Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzJtxgACgkQ+gerLs4ltQ6OKgCcCH1Wt0Bg1COSqMdBm7whSL8H JOMAnRqA9jy8eazZnTMV+Q/gvKNX7zLb =yu2I -----END PGP SIGNATURE-----
Kristján Valur Jónsson <kristjan@ccpgames.com> wrote:
Let's move the current 'trunk' into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love.
Though I'm not personally convinced it's a good idea, I can see where some could find it useful.
Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole. Open-source it, if you will.
No real need to go that far, I think. The tests after all are part of the source tree, buildbots are still running them, etc. And if the buildbot master stops doing that, there are community buildbots for testing things like this. Release management is going to happen one way or another. Bill
Kristján Valur Jónsson <kristjan <at> ccpgames.com> writes:
Let’s move the current ‘trunk’ into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love.
Just curious - what specific new features or backwards-incompatible fixes do you need to add, i.e. things which cannot be catered for by release27-maint? Or is this just about the *principle* of having a 2.8? Regards, Vinay Sajip
Vinay Sajip <vinay_sajip <at> yahoo.co.uk> writes:
need to add, i.e. things which cannot be catered for by release27-maint? Or is this just about the *principle* of having a 2.8?
Never mind - I've just picked up the extra posts on this thread, which for some reason didn't show up in my reader before. Sorry for the noise.
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python?
The answer would seem to be “one doesn’t”. But must it be that way?
Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like. So it can be done, but the question is "Why?" -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like.
So it can be done, but the question is "Why?"
To keep the batteries included? James
2010/11/8 James Y Knight <foom@fuhm.net>:
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like.
So it can be done, but the question is "Why?"
To keep the batteries included?
But they'll only be included in > 2.7, which won't be used much, which defeats the purpose of including those batteries. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328
On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote:
2010/11/8 James Y Knight <foom@fuhm.net>:
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
So it can be done, but the question is "Why?"
To keep the batteries included?
But they'll only be included in > 2.7, which won't be used much, [...]
If there was going to be an official python.org sanctioned Python 2.8 release, I'm not at all sure that'd be the case. Since there isn't going to be one, then yes, that's probably true. James
James Y Knight writes:
On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote:
2010/11/8 James Y Knight <foom@fuhm.net>:
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
So it can be done, but the question is "Why?"
To keep the batteries included?
But they'll only be included in > 2.7, which won't be used much, [...]
If there was going to be an official python.org sanctioned Python 2.8 release, I'm not at all sure that'd be the case. Since there isn't going to be one, then yes, that's probably true.
Which pretty much demonstrates that the argument for a sanctioned 2.8 is weak, and ditto for adding features to 2.7. Python 2.7 is a great language; existing projects which need to go beyond that need to port to a different language. The OP is already doing that IIUC: Stackless is a pretty faithful implementation of Python (in several versions of the language, too!), but not quite 100%, right? OTOH, how many derivatives has C spawned? Or Pascal, FORTRAN, LISP? ML? And people continue to find that variety *constraining*, and invent new languages! python-dev's decision to offer that different language as Python 3, where *almost all* of your skills will upgrade transparently (even though unfortunately a lot of code won't, at least not today), is probably a great boon to developers *in* Python. Time will tell.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/08/2010 04:42 AM, Lennart Regebro wrote:
2010/10/28 Kristján Valur Jónsson <kristjan@ccpgames.com>:
Hello all.
So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does one make improvements to the distinguished, and still very much alive, 2.x series of Python?
The answer would seem to be “one doesn’t”. But must it be that way?
Except for making releases that start backporting Python 3 features and breaking backwards compatibility gradually (which may or may not be a good idea) I don't see the point. There isn't much to do when it comes to improving the language, and there is a moratorium anyway. Improvements in the standard library can be more easily done in external libraries anyway, and then you can release the improved libraries for everything from Python 2.4 and forwards if you like.
So it can be done, but the question is "Why?"
The OP has existing patches to contribute which the core python-dev team consider "not-a-bugfix", and hence not acceptable for the 2.7 branch. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzYIgUACgkQ+gerLs4ltQ4i1QCfVwDdlkd9tGj6ayKBq3xpiHAW fIYAoNwDx35RfC5VYEyVjhJBbCxrqfXk =bnTg -----END PGP SIGNATURE-----
participants (33)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Bill Janssen -
Brett Cannon -
Brian Curtin -
C. Titus Brown -
Casey Duncan -
Daniel Stutzbach -
David Malcolm -
Dirkjan Ochtman -
exarkun＠twistedmatrix.com -
Georg Brandl -
geremy condra -
Giampaolo Rodolà -
Glyph Lefkowitz -
Ian Bicking -
James Y Knight -
Kristján Valur Jónsson -
Lennart Regebro -
M.-A. Lemburg -
Neil Schemenauer -
Nick Coghlan -
R. David Murray -
Simon Cross -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy -
Toshio Kuratomi -
Tres Seaver -
Victor Stinner -
Vinay Sajip