Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Sat, Mar 19, 2011 at 03:42, Nick Coghlan ncogh...@gmail.com wrote: 5. The parallel evolution of the 2.x and 3.x line meant that the first version of 2.x with the relevant warning was released only ~7 months or so before the version of 3.2 where the API was removed An additional issue that makes it particularly problematic for me is that this is a part of moving a whole framework, the Zope Component Architecture And Friends (aka the Bicycle toolkit) that contains a lot of hard to port projects like zope.testing and zc.buildout. This means that it's so far take three years of porting (starting with efforts to port Setuptools in 2008) and isn't done yet. It's extremely frustrating that in the middle of this porting effort the target changes, so things I *thought* was done and ported, are now suddenly not done anymore. It becomes a sisyphean task to port to Python 3, and I don't fancy myself ending up in such a boring part of hell. :-) If I had instead ignored Python 3 completely until this year, then I this wouldn't have been a problem. As a result it feels like early porters like me just got our fingers whacked. But it all comes down to what Guido mentioned in his fie-side chat (at least how I understood him): The pace of change for Python needs to slow down a bit, at least until the migration to Python 3 both for Python implementations and general use has been completed. //Lennart ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Fri, Mar 18, 2011 at 00:23, Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. That would be creating an insane burden on library developers. Besides, I've so far not have things break between micro releases, it must be very unusual. That said, when running Python 2.7 with -3 in preparation for a port, you should of course use the latest version, that has the most warnings. //Lennart ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/03/11 01:01, Larry Hastings wrote: In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k(). This means it's been promoted to throwing DeprecationWarning! But that's also guarded with Py_Py3kWarningFlag so it's not active unless you ask for that too (as with -3 on the command-line, etc). I kind of remember doing this change myself. Since no 2.8 is planned, it seemed sensible to mark PyCObject as a py3k warning. PS: I am the maintainer of (externally developed lib) bsddb, but the 2.7.0 behaviour actually broke some other extensions out there (when used with warnings active). Details in the tracker, somewhere. I am offline now, can't use the browser. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYOiYplgi5GaxT1NAQLtRgQAjdB1yvFmqJLGqqzEaCK+ll5jx277b751 RGshITBFUkd+OLVErP9nEKUMsHvr/nl7BIjhZotKH31g6Hl0KiuGPHHkPNKYGs4y 5XsHaZ2a9/qkgt1wa12gLsHmxsrIICGKPzcPUQs6GVJGBuppGtDkc18iODOCd6eC kkDcc/sFHUI= =mXiX -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/18/2011 11:20 AM, Jesus Cea wrote: I kind of remember doing this change myself. Since no 2.8 is planned, it seemed sensible to mark PyCObject as a py3k warning. It's all fine by me, and yeah I think you did the change. I'm sure it wasn't me. PS: I am the maintainer of (externally developed lib) bsddb, but the 2.7.0 behaviour actually broke some other extensions out there (when used with warnings active). Details in the tracker, somewhere. I am offline now, can't use the browser. My point in bringing up bsddb was that it was the only remaining use of CObject that shipped with Python 2.7. Yes, certainly there were externally-maintained extensions that went to pieces when PyCObject_FromVoidPtr() started returning NULL. But internally, 2.7 switched entirely to capsules, except for bsddb. Cheers, /larry/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Fri, Mar 18, 2011 at 1:04 AM, Guido van Rossum gu...@python.org wrote: I don't want to be alarmist and I don't want to start another moratorium, but I do think that we need to be aware of people coming in sideways into Python 3 and missing the nice deprecations. So let's be conservative with deprecations in the Python 3 line for now. Adding new deprecations is probably OK, but we should definitely be very cautious about following through with *removal* of deprecated items. I was pondering the specific case of PyCapsule on the way home, and it actually took quite a series of events for it to blow up in Lennart's face the way it did at the sprints: 1. We really should have made a PEP about it at the time, but that didn't occur to anyone involved in the decision (I have vague recollections of contributing to those discussions, so I suspect a piece of the blame for that ends up in my own lap). 2. I believe PyCObject jumped directly from a PendingDeprecationWarning in 3.1 to removal in 3.2. That would have been less likely if we'd written a PEP to clearly spell out the deprecation timeline. 3. For whatever reason, nobody objected to the removal during post hoc python-checkins review. (While that manual filter catches a lot of mistakes, things can definitely slip through). 4. Anyone testing C extensions against the 3.2 alpha and beta releases must have either not used the PyCObject API in the first place, or else had already ported their code to use the PyCapsule API as necessary. 5. The parallel evolution of the 2.x and 3.x line meant that the first version of 2.x with the relevant warning was released only ~7 months or so before the version of 3.2 where the API was removed Backfilling with an after-the-fact PEP (as Larry now plans to do) will help make sure this particular change is less likely to come as a nasty surprise to anyone else, and will provide concrete porting advice for those that need to maintain compatibility with older Python versions that only offer the PyCObject API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 16:04, Guido van Rossum wrote: I don't want to be alarmist and I don't want to start another moratorium, but I do think that we need to be aware of people coming in sideways into Python 3 and missing the nice deprecations. So let's be conservative with deprecations in the Python 3 line for now. I can see the motivation for this. I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. In this way we can keep the improvements, while not leaving people just migrating from 2.7 behind. The problem will be to decide when to do the cleanup... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYJcQplgi5GaxT1NAQIeawQAgC3kpmS8RoYoeRn6BRFKTOSEKc6edafY NVKDZ+NAZzTeYqJcr0symc+9A+5J92fJQq2n6tz1/K2yAzS/m1dudAXK7YIb1Ldc EwX8JB2osvCgGM5PFefhGOLZ0VrrlWnHQTEviU5GilGNHzCcbEgNj/3BPnEyCNyv QPmlcyeN+eQ= =xidU -END PGP SIGNATURE- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/17/2011 03:08 PM, Jesus Cea wrote: I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. At some point, didn't we say PendingDeprecationWarning in version x, DeprecationWarning in x+1, and removal in x+2? That's what I've been doing, but it's not what PEP 5 says. Removing in x+2 would lengthen the timeframe, although I agree with Guido that we should be extra careful for the next several years because of people moving directory from 2.7 to (say) 3.5. Eric. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Mar 17, 2011, at 12:22 PM, Eric Smith wrote: On 03/17/2011 03:08 PM, Jesus Cea wrote: I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. At some point, didn't we say PendingDeprecationWarning in version x, DeprecationWarning in x+1, and removal in x+2? That's what I've been doing, but it's not what PEP 5 says. Removing in x+2 would lengthen the timeframe, although I agree with Guido that we should be extra careful for the next several years because of people moving directory from 2.7 to (say) 3.5. Agreeing with Guido is always a good move :-) In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases. That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x. Raymond ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Mar 17, 2011, at 4:07 PM, Raymond Hettinger wrote: Agreeing with Guido is always a good move :-) In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases. That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x. And of course, updating 2to3, if possible, would also be appreciated. James ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 3/17/2011 11:04 AM, Guido van Rossum wrote: I've thought some more about deprecations and subsequent deletions in Python 3 (but not read the whole thread -- sorry, I've gotten sick right after coming home from PyCon). I think that as long as a significant number of people are still using Python 2, it may be problematic if we start removing things (or making other backwards-incompatible changes) from later Python 3 versions that existed in early Python 3 versions, even if we've followed PEP 5 for the deprecation period. The problem is that --unrelated to this issue, and for legitimate reasons that we can anticipate-- people will likely ignore the entire Python 3 line until they're ready, which means that they may skip the early Python 3 versions once they port to Python 3. ... But if you have a big app finally ported to Python 2.7 (feeling ready Python 3) but are waiting for your last dependency to be ported to Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until you finally attempt to port to 3.4. And if something never got a deprecation warning in 2.7, and was deprecated in 3.2 (say) and removed in 3.4, you'd be in for a shock. Agreed. As Raymond said, such things *should* get a warning in the next release of 2.7, and there will be 'next' 2.7 releases for several years to received such updates. As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7. If 'py3k' warnings need to be specific, I presume that should be possible. People should retest their stuff with each micro (bugfix) release anyway. One counterpoint: everyone should ignore 3.0. And in my opinion, anyone who has ignored 3.1 can continue to ignore it. Which is to say, there is not so much 3.1 stuff frozen in place but what most everyone using 3.1 cannot upgrade to 3.2. So jumping from 2.7 to 3.2 should not be much harder than to 3.1. It might be a little harder to say this about 3.2 when 3.3 comes out. And this is not necessarily the kind of stuff that 2to3 does (since the feature existed in 3.0 and 3.1). In some cases 3to2 could even be wrong if we're not careful. This came up in a tracker issue and I meant to bring it up here before this. Since there is no single 'Python 3', 2to3 really needs to be 2to3.x. So I think the 2to3 that come with 3.x should be specific to 3.x. Or 2to3 should target the latest 3.x. For instance, 2to3 could make the unittest name substitutions now regardless of target version since the now preferred names were in 3.0 already. At the Python level, most of the recent deprecations have either been the delayed unittest cleanup or obscure library methods, many of which were undocumented and/or meant to be private. One exception is the change of .fromstring to .frombytes for a bytes method in one of the modules, a change that should have been in 3.0 but was overlooked. -- 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Thu, Mar 17, 2011 at 8:35 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. But IMHO, it would be that, or urging people to use 2to3 from a separate source. It does not make sense to keep 2to3 frozen while its target moves forward. Even if it is decided that things should not be removed, 2to3 should warn of new deprecations as Python moves into 3.3, 3.4, and beyond. js -- 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/jsbueno%40python.org.br ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/17/2011 07:23 PM, Terry Reedy wrote: As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7. In 2.7, the CObject constructor PyCObject_FromVoidPtr() threw a PendingDeprecationWarning exception. Like other warnings, these aren't active by default. This still caused two problems: * If you enabled warnings, PyCObject_FromVoidPtr() would return NULL. There is definitely code out there that assumes PyCObject_FromVoidPtr() always succeeds and doesn't bother checking the pointer it gets back. That's a bad assumption, the code is therefore buggy--but exposing these heretofore unnoticed bugs caused problems. * If you enabled warnings-as-errors, a PendingDeprecationWarning is therefore an error. In some environments there's a requirement that Python must build from scratch and pass its unit test suite without errors, with warnings-as-errors turned on. Python 2.7 shipped with one module still using PyCObject_FromVoidPtr(), bsddb, as it's externally maintained. (I wanted to change it to use PyCapsule for 2.7 but was told to leave it alone.) bsddb's test threw the warning, the warning was an error, now people had a problem. In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k(). This means it's been promoted to throwing DeprecationWarning! But that's also guarded with Py_Py3kWarningFlag so it's not active unless you ask for that too (as with -3 on the command-line, etc). /larry/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
Antoine Pitrou wrote: On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. Even bug fixes can have unintended consequences (in other words, new bugs). Or perhaps there is work-around code in place that now causes problems because there is nothing to work around. Even if neither of those two cases is true, why would you not want the warm, fuzzy feeling of contentment *knowing* that your code runs on the latest Python? ~Ethan~ ___ 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/archive%40mail-archive.com
