Re: [Python-Dev] for __future__ import planning
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python-checkins seems broken
> I know there's a transition to new IP addresses going on for the > python.org machines, but Thomas or Sean probably needs to do something > with the DNS for this. IIUC, it would be sufficient if these addresses get recognized as local. Meanwhile, I have disabled the new interfaces. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Doc nits question
Terry Reedy schrieb: > Georg Brandl wrote: >> Fred Drake schrieb: >>> On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote: I intend to set things up so that the docs at docs.python.org are continually rebuilt, just like the /dev docs were until now. > > Will you do the same for the 3.0 version? > http://docs.python.org/dev/3.0/ Yes. Nothing has changed there. > The following page has no reference to the 3.0 version > http://www.python.org/doc/versions/ > The 'unreleased' link at the top goes to a link that only referenced the > SVN version and not the built version above. Adding a link to the build > version would have made it easier to find ;-). http://www.python.org/dev/doc/, where the link leads to, references both trunk and 3.0 here. 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Steven D'Aprano wrote: On Sat, 4 Oct 2008 12:26:30 pm Nick Coghlan wrote: (Tangent: the above two try/except examples are perfectly legal Py3k code. Do we really need the "pass" statement anymore?) I can't imagine why you would think we don't need the pass statement. I often use it: * For subclassing exceptions: class MyTypeError(TypeError): pass * As a placeholder for code I haven't written yet. * As a no-op used in, e.g. the timeit module. And probably a few other places as well. Nick is literally (pardon the pun) saying that '...' could take the place of 'pass' in 3.0. His original examples are valid syntax, as written with the ellipses. For example: $ ./python Python 3.0rc1+ (py3k:66789, Oct 4 2008, 05:26:45) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... ... ... except: ... ... ... else: ... ... ... finally: ... ... ... Ellipsis Ellipsis Ellipsis >>> I think it's a little too cute, and 'pass' is preferable. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future __ import planning)
Martin v. Löwis v.loewis.de> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pickle, 3.0, and recursion
Hi, I posted a bug ticket on bugs.python.org, specifically #3119. Link: http://bugs.python.org/issue3119 The original issue is that the default Pickler can exceed the maximum recursion depth for structures that are fairly nested. There's a patch attached to the ticket that fixes this behavior by using a generator- based callstack. Unfortunately, this completely changes the API of Pickler. As far as I know, such major API changes would not be accepted in to 3.0 at this point. I tried to come up with an alternate version of the patch that just added a subclass, but I haven't been able to think of a way to do that that doesn't involve a lot of code duplication. It's easy to just copy-paste most of Pickler and give it a new name and change the API, but that's hardly an optimal solution. Does anybody else have any thoughts about how this could be better implemented? I think this is a decent implementation, but at this point, it's too severe of a change. Maybe somebody else has a better idea of how this could fit cleanly into the existing Pickler API or write a subclass without a lot of messy duplication. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
Antoine Pitrou wrote: > Martin v. Löwis v.loewis.de> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] for __future__ import planning
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
On Sat, Oct 4, 2008 at 12:45 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
[replying to both Georg and Martin] On Sat, Oct 4, 2008 at 12:17 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
2008/10/4 Brett Cannon <[EMAIL PROTECTED]>: > 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
On Sat, Oct 4, 2008 at 2:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Antoine Pitrou wrote: >> Martin v. Löwis v.loewis.de> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
