for __future__ import planning
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :) I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
Benjamin Peterson wrote:
I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.
Hey! That was my idea! I told you the very same idea on IRC a week ago. Shame on you! :) I'm +1 on the proposal. Let's focus on stability and performance for the next release. But before we start planning the next release we need to find a way to sync the development. Soon we have to apply fixes to up to four (again FOUR) branches: 2.6, 2.7, 3.0 and 3.1. We don't have to merge as many code as we did during the py3k phase. But it's still lots of work and we need all the (technical) help we can get. Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)
I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.
There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while. I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2". I would really like to see us adopt a distributed version control system. I want our maintenance branches to always be in a releasable state. I want to be confident enough about the tree to be able to cut a point release at any time. I want to release a new point release from the maint branches once a month. Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOajHXEjvBPtnXfVAQJ5qgP+I6k+kHMG2zPTvMIstM2wRmhtAPd7kKz9 S6bXllUBzpxQGMYfqR3Ze5/SVUMEV2HvINPDfg816sGOoxs0fMeori398rU97bkH tOFHOEi/KLKMdgGdjGWWnV+iPEGF6stPMX/6nGQDhM5NMzj81hBgF+7U+UNbS7iM dT2wk3vSZHQ= =q4kW -----END PGP SIGNATURE-----
On Fri, Oct 3, 2008 at 3:56 PM, Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)
I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.
There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.
I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
+1 from me. I think 2.7/3.1 should be used as a chance to get our testing framework straightened out and have those releases be extremely rock-solid (especially 2.7 as it might be the last in the 2.x series). Oh, and getting import rewritten in pure Python for 3.1 of course. =)
I would really like to see us adopt a distributed version control system.
Along the lines of making 2.7/3.1 very stable releases, I would love to use the time to clean up our workflow. To me that means cleaning up the workflow on the issue tracker and getting on to a DVCS to make it as easy as possible for people to contribute patches and for us to do reviews.
I want our maintenance branches to always be in a releasable state. I want to be confident enough about the tree to be able to cut a point release at any time. I want to release a new point release from the maint branches once a month.
Wow! I guess release.py is going to get really automated then. =) That or you are going to manage to con more of us to help out (and even cut the release ourselves).
Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations?
Beats me. Are that many projects crazy enough to have that many active branches? -Brett
Brett Cannon wrote:
Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations?
Beats me. Are that many projects crazy enough to have that many active branches?
Is it really that bad? Once 3.0 is released, it's not like we're going to be patching 2.6 and 3.0 all that much. All the "real development" (by which I mean most of the checkins) will be on 2.7 and 3.1. The biggest challenge I see is the buildbots. Eric.
Is it really that bad? Once 3.0 is released, it's not like we're going to be patching 2.6 and 3.0 all that much.
And unfortunately so. The 2.5 branch doesn't get the attention that it should, let alone the 2.4 branch. We will continue to "have" them (even if only for security patches). Regards, Martin
Brett Cannon
Beats me. Are that many projects crazy enough to have that many active branches?
Any project using branch-driven development has many active branches. Our specificity is that we must maintain in sync two branches (trunk, py3k) which have widely diverged from each other. Thus, merges are often non-trivial. Regards Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 3, 2008, at 7:34 PM, Brett Cannon wrote:
Wow! I guess release.py is going to get really automated then. =) That or you are going to manage to con more of us to help out (and even cut the release ourselves).
release.py is really coming along well. I'm planning to spend some time next time around on updating large parts of the web site automatically. Or maybe Benjamin will when he's RM :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOei8XEjvBPtnXfVAQLm+wQAgctR3FuylGaST4Y55JIpo8pPOZ8ouzXW L8wymNAz70neXMI2rVWk/qKyRovkwIgSe2GfKX14Vi85WGOw0MFvo2IkCx9VqUML GdpR2j0ixX512/bBknZ3+Jsz5yUrppXBqFOuMHdSkxg/3YZSWKYUjRAUVk/48ujL zbiVD+VJKUQ= =qjlH -----END PGP SIGNATURE-----
Barry Warsaw schrieb:
On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)
I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.
There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.
I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
Especially 3.1 should also be a release where we focus as much on the community as on the code. There are many people out there for whom Python 3, as an incompatible language, is not an easy step to make, especially those with huge 2.x codebases on their hands. They have two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them. We need to make 2to3 and related tools reliable and do more showcases of porting, like Martin did with Django, so that people have real-world examples at their disposal, by which they can estimate their own porting needs. (Waiting for the extended community to deliver such examples may be a mistake.) We also need to commit to help people with porting. I propose a new mailing list (e.g. python3-porting), parallel to python-list, specifically for people going that way. I think it will help to focus the community effort of getting Python 3 off the ground. Last not least, there should be a *central* location on python.org where specifically all resources on 2->3 transition are collected. Talks, documents, links, and some crucial information many people seem to miss, such as how long the 2.x series will at least be maintained. They depend on this. cheers, 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 Sat, Oct 04, 2008 at 09:45:27AM +0200, Georg Brandl wrote:
Barry Warsaw schrieb: two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them.
PyPI should also be enhanced to indicate which libraries are 3.x-compatible, to make it easier for 3.x users to find packages they can use. This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers... --amk
This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers...
Can you propose a spec? Regards, Martin
Martin v. Löwis
This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers...
Can you propose a spec?
Setuptools already has a syntax for declaring requirements. http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies
Antoine Pitrou wrote:
Martin v. Löwis
writes: This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers... Can you propose a spec?
Setuptools already has a syntax for declaring requirements. http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies
That is underspecified for the issue at hand: What *specifically* should PyPI look for to determine 3.0 support in a package, and how *specifically* should it display that? An alternative to specifying dependencies would be to specify a classifier, e.g. Programming Language :: Python :: 3 or Programming Langauge :: Python3 Then, no changes to PyPI are needed (except for adding the classifier to the database), and searching for Python-3-supporting packages could go through http://pypi.python.org/pypi?%3Aaction=browse Regards, Martin
On Sat, Oct 4, 2008 at 2:22 PM, "Martin v. Löwis"
Antoine Pitrou wrote:
Martin v. Löwis
writes: This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers... Can you propose a spec?
Setuptools already has a syntax for declaring requirements. http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies
That is underspecified for the issue at hand: What *specifically* should PyPI look for to determine 3.0 support in a package, and how *specifically* should it display that?
An alternative to specifying dependencies would be to specify a classifier, e.g.
Programming Language :: Python :: 3
or
Programming Langauge :: Python3
Then, no changes to PyPI are needed (except for adding the classifier to the database), and searching for Python-3-supporting packages could go through http://pypi.python.org/pypi?%3Aaction=browse
Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/) with a new metadata called 'Requires Python' Even if the problem is fixed in short term with a Trove classifier, the metadata of a package should provide this information imho.
From there PyPI should be able to provide the Python version directly.
For a full list of dependencies this is another tough problem due to the dynamic nature of the metadata: you have to run setup.py to get the list of dependencies because they are determined by code. This is by design, and plans for a refactoring are being discussed in distutils-SIG since a few days. In any case, extending metadata with supported Python version could be a first simple, useful step to do in distutils and PyPI today. So the Python version comes as the same level than the Platform or the License. Tarek
Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/) with a new metadata called 'Requires Python'
Even if the problem is fixed in short term with a Trove classifier,
Why would that be a short-term fix? It would work for the entire life time of Python 3, and can be easily extended for Python 4, so it sounds like a permanent solution to me. As a permanent solution, you need to keep the problem statement in mind, though: to allow people to determine whether a package works with Python 3.
the metadata of a package should provide this information imho.
Well, the classifiers *are* part of the metadata of the package. Regards, Martin
On Sun, Oct 5, 2008 at 6:59 AM, "Martin v. Löwis"
Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/) with a new metadata called 'Requires Python'
Even if the problem is fixed in short term with a Trove classifier,
Why would that be a short-term fix? It would work for the entire life time of Python 3, and can be easily extended for Python 4, so it sounds like a permanent solution to me.
As a permanent solution, you need to keep the problem statement in mind, though: to allow people to determine whether a package works with Python 3.
the metadata of a package should provide this information imho.
Well, the classifiers *are* part of the metadata of the package.
Yes and they are redundant to other metadata, like the licence for instance.. So maybe the problem is the other way: some specific metadata should be removed since they are expressed in the classifier medatata. (e.g. only in one place) There should be one-- and preferably only one --obvious way to do it. Regards Tarek
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/ ) with a new metadata called 'Requires Python'
Even if the problem is fixed in short term with a Trove classifier,
Why would that be a short-term fix? It would work for the entire life time of Python 3, and can be easily extended for Python 4, so it sounds like a permanent solution to me.
As a permanent solution, you need to keep the problem statement in mind, though: to allow people to determine whether a package works with Python 3.
The Setuptools dependencies fields are only for declaring library dependencies, not dependencies such as the Python interpreter. A problem with overloading the Categories field with Python version compatability information is that it makes for a poor user-interface. On the release page for a package, I'd rather see a Python Version field than having to look through a potentially large list of Categories. There is a "Py Version" field for file uploads (which I'd really like to tweak the UI to read "Python Version"), maybe if you could specify for uploads of the "source" type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules). Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run on Python 3 after running it through 2to3. The source code is different so that to me suggests different version numbers - but the API will be the same, so maybe the same version number should be used? That is should there be? foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz Or should it be something like? foobar-1.0.tar.gz # Python 2 foobar-1.1.tar.gz # Python 3 Well, writing out that last example looks wrong to me, since 1.0 -> 1.1 suggests bug fixes and API changes to the package. But someone could be thinking, "1.0 supports the Python 2 API and 1.1 supports the Python 3 language API". So at any rate it'd be good to make the way to handle this explicit in the (yet to be created) "2to3 central" documentation resource.
A problem with overloading the Categories field with Python version compatability information is that it makes for a poor user-interface. On the release page for a package, I'd rather see a Python Version field than having to look through a potentially large list of Categories.
That's an issue of how the page is rendered. Hence I asked for a full specification.
There is a "Py Version" field for file uploads (which I'd really like to tweak the UI to read "Python Version")
Feel free to submit a patch (or perhaps just a bug report).
maybe if you could specify for uploads of the "source" type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules).
I think that deviates from the subject, which is "3.1 focus", and AMK's request to let people find out whether a package runs on Python 3.
Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run on Python 3 after running it through 2to3. The source code is different so that to me suggests different version numbers - but the API will be the same, so maybe the same version number should be used? That is should there be?
It all depends on how you do the porting. If all it takes to run the program through 2to3 to make it port correctly, I recommend to use the build_py_2to3 build step of distutils in 3.0. Then the same source can be installed for 2.x and 3.x, with no modifications. Regards, Martin
Martin v. Löwis wrote:
A problem with overloading the Categories field with Python version compatability information is that it makes for a poor user-interface. On the release page for a package, I'd rather see a Python Version field than having to look through a potentially large list of Categories.
That's an issue of how the page is rendered. Hence I asked for a full specification.
There is a "Py Version" field for file uploads (which I'd really like to tweak the UI to read "Python Version")
Feel free to submit a patch (or perhaps just a bug report).
maybe if you could specify for uploads of the "source" type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules).
I think that deviates from the subject, which is "3.1 focus", and AMK's request to let people find out whether a package runs on Python 3.
Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run on Python 3 after running it through 2to3. The source code is different so that to me suggests different version numbers - but the API will be the same, so maybe the same version number should be used? That is should there be?
It all depends on how you do the porting. If all it takes to run the program through 2to3 to make it port correctly, I recommend to use the build_py_2to3 build step of distutils in 3.0. Then the same source can be installed for 2.x and 3.x, with no modifications.
Of course there is also the option of treating Python 3 as a different language, and having a Py3Pi website as well. This might not be as wasteful as it at first seems. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
[Steve Holden"]
Of course there is also the option of treating Python 3 as a different language, and having a Py3Pi website as well. This might not be as wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still work when run through 2-to-3 and then automatically porting updates to the Py3Pi website. Raymond
Of course there is also the option of treating Python 3 as a different language, and having a Py3Pi website as well. This might not be as wasteful as it at first seems.
Although it would be possible, I think it's not appropriate. It would be fairly easy to implement, though: just create pypi.python.org/python3 (say), along with /simple3 and /packages3. I find it inappropriate for two reasons: over time, Python 2 will disappear, and then we are left with the python3 URLs (similar how Microsoft now needs to put 64-bit binaries into the system32 folder). In addition, packages that do support both versions need to register twice, upload twice, etc. In any case, if that route is chosen, we have to adjust distutils before the 3.0 release is made. Regards, Martin
Martin v. Löwis
Although it would be possible, I think it's not appropriate.
I also think it's inappropriate. We want people to know about the existence of Python 3, and the best for that is to have Python 3-related information in the standard PyPI site where people look for Python 2.x packages. Regards Antoine.
2008/10/6 Antoine Pitrou
Martin v. Löwis
writes: Although it would be possible, I think it's not appropriate.
I also think it's inappropriate. We want people to know about the existence of Python 3, and the best for that is to have Python 3-related information in the standard PyPI site where people look for Python 2.x packages.
Agreed. Although there are significant differences to consider, I think the last thing we want to do is to encourage the impression that Python 3 is a different language from Python 2. Paul.
2008/10/5 Kevin Teague
on Python 3 after running it through 2to3. The source code is different so that to me suggests different version numbers - but the API will be the same, so maybe the same version number should be used? That is should there be?
foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz
More likely, in this way: foobar-1.0-py2.tar.gz foobar-1.0-py3.tar.gz
Or should it be something like?
foobar-1.0.tar.gz # Python 2 foobar-1.1.tar.gz # Python 3
The problem here is that I can foresee libs or apps that have a mixed path, starting to support Py 3 at some point, and deprecating the Py 2 support after a while: foobar-1.0.tar.gz # Py 2 foobar-1.1.tar.gz # Py 2 & 3 foobar-1.2.tar.gz # Py 2 & 3 foobar-1.3.tar.gz # Py 2 & 3 foobar-1.4.tar.gz # Py 2 & 3 foobar-1.5.tar.gz # Py 3 Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz
More likely, in this way:
foobar-1.0-py2.tar.gz foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename the files from how sdist names them. So it's more likely that they come up with things like foobar_py3-1.0.tar.gz and register a second project foobar_py3 in PyPI. Regards, Martin
2008/10/5 "Martin v. Löwis"
foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz
More likely, in this way:
foobar-1.0-py2.tar.gz foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename the files from how sdist names them. So it's more likely that they come up with things like
Sorry, I was not advising that structure, just mentioning that if you'll follow it, don't include the minor version, just the major one. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Sat, Oct 4, 2008 at 12:45 AM, Georg Brandl
Barry Warsaw schrieb:
On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)
I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.
There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.
I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
Especially 3.1 should also be a release where we focus as much on the community as on the code. There are many people out there for whom Python 3, as an incompatible language, is not an easy step to make, especially those with huge 2.x codebases on their hands. They have two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them.
We need to make 2to3 and related tools reliable and do more showcases of porting, like Martin did with Django, so that people have real-world examples at their disposal, by which they can estimate their own porting needs. (Waiting for the extended community to deliver such examples may be a mistake.)
We also need to commit to help people with porting. I propose a new mailing list (e.g. python3-porting), parallel to python-list, specifically for people going that way. I think it will help to focus the community effort of getting Python 3 off the ground.
This is a good idea; python-help for porting.
Last not least, there should be a *central* location on python.org where specifically all resources on 2->3 transition are collected. Talks, documents, links, and some crucial information many people seem to miss, such as how long the 2.x series will at least be maintained. They depend on this.
That seems reasonable if someone gets around to doing it. =) -Brett
Brett Cannon schrieb:
Last not least, there should be a *central* location on python.org where specifically all resources on 2->3 transition are collected. Talks, documents, links, and some crucial information many people seem to miss, such as how long the 2.x series will at least be maintained. They depend on this.
That seems reasonable if someone gets around to doing it. =)
Well, since for >95% of the (potential) Py3k users it is more important than e.g. the import rewrite in Python (no stab at you intended, Brett), it is something someone will have to get around to doing. I'm not excusing myself; in fact, I'd be happy to work on this, but overall the team "Python 3 advocacy and support" should consist of more than one person. 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.
Well, since for >95% of the (potential) Py3k users it is more important than e.g. the import rewrite in Python (no stab at you intended, Brett), it is something someone will have to get around to doing.
I'm not excusing myself; in fact, I'd be happy to work on this, but overall the team "Python 3 advocacy and support" should consist of more than one person.
I think this has time. I'm (now) confident that people will port to Python 3 sooner rather than later, just because it's there. In fact, we have to be careful not to talk too many people into porting, since there will be some glitches which need to be resolved, and may not get resolved before 3.2 or so. So people with a natural wariness are advised to trust this wariness, or else all their concerns become self-fulfilling prophecies. Regards, Martin
[replying to both Georg and Martin]
On Sat, Oct 4, 2008 at 12:17 PM, "Martin v. Löwis"
Well, since for >95% of the (potential) Py3k users it is more important than e.g. the import rewrite in Python (no stab at you intended, Brett), it is something someone will have to get around to doing.
Don't worry, I realize my import work is approaching vaporware status at this rate (still plugging away at it, though). But you are right: helping people port to 3 will be the most important thing we can help people with.
I'm not excusing myself; in fact, I'd be happy to work on this, but overall the team "Python 3 advocacy and support" should consist of more than one person.
I would definitely be willing to help. So the mailing list is a good idea. Perhaps it should just be python-porting so that it can also be used for people who have problems with minor releases? We could then have a /porting/ section to the site where we can actually document after each release how to port to the newest version. And as for 2 -> 3 stuff, should probably provide the expected steps to port, tips for pure Python code (and how to write 2.6/3.0 compatible code), extension modules, and make it clear what our overall plan is (e.g. 3.2 probably being the truly stable release semantically).
I think this has time. I'm (now) confident that people will port to Python 3 sooner rather than later, just because it's there. In fact, we have to be careful not to talk too many people into porting, since there will be some glitches which need to be resolved, and may not get resolved before 3.2 or so. So people with a natural wariness are advised to trust this wariness, or else all their concerns become self-fulfilling prophecies.
Yes, people should be warned that if they are not ready to make changes after each Python release that are probably more than they are used to between minor releases, they might to hold off for 3.1 or 3.2. But I don't want to be too discouraging as that might stifle any forward momentum we might have and potentially leave 3 flat before it even gets going. -Brett
2008/10/4 Brett Cannon
So the mailing list is a good idea. Perhaps it should just be python-porting so that it can also be used for people who have problems with minor releases?
+1. I'd try to help on that list, also. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Sat, Oct 4, 2008 at 00:56, Barry Warsaw
I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
I like that. Do we know what the next "hurdle" would be? The testing I have done seems to indicate that one major area is handling of binary file data that may or may not be binary. Is a real bytes type (and not just an alternate spelling for str) a possibility? It may be that this isn't a problem in practice, I don't know yet. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
participants (16)
-
"Martin v. Löwis"
-
A.M. Kuchling
-
Antoine Pitrou
-
Barry Warsaw
-
Benjamin Peterson
-
Brett Cannon
-
Christian Heimes
-
Eric Smith
-
Facundo Batista
-
Georg Brandl
-
Kevin Teague
-
Lennart Regebro
-
Paul Moore
-
Raymond Hettinger
-
Steve Holden
-
Tarek Ziadé