Re: [Python-Dev] public visibility of python-dev decisions before it's too late
Lennart Regebro, 16.03.2011 00:04: On Tue, Mar 15, 2011 at 18:56, Nick Coghlan wrote: why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Apparently not, as the code already ran under Python 3.1. Personally, I would expect that breaking backwards compatibility in Python 3.2 affects a lot less people than a similar change in the 2.x line because many projects still haven't ported their code to Python 3.x. I can assure you that it's quite easy to support both PyCObject and PyCapsule at the same time, thus supporting a wide range of Python 2.x and 3.x releases. NumPy does it, Cython does it, other projects probably do it by now, too. So this is actually less of a problem than you are trying to make it appear. Stefan ___ 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] public visibility of python-dev decisions before it's too late
Eric Smith, 16.03.2011 04:12: On 3/15/2011 10:58 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. I think it's valid that we should consider the affect of libraries that are trying to support 2.x and 3.y (for some values of x and y) at the same time. I don't really see any for this specific change, though. It's not an issue of supporting both 2.x and 3.x, it's an issue of supporting 3.2 and earlier CPython versions, and it's not even hard to do that. Basically, you can copyadapt code from a project that already supports it and be done. CPython has broken backwards compatibility in certain areas more than once. It even broke basically all existing C code in 2.5 with the introduction of Py_ssize_t (well, technically, it didn't break it on 32bit platforms, but it introduced a pretty heavy push for people to walk through their code and manually adapt it anyways). Other breakages had a much smaller impact than that. If the amount of affected code is smaller, it's unfortunate to be amongst those who are hit by such a change, but if there's a reason to go that route, well, then there's a reason. I still consider this is mostly a communication issue. If this change had been properly written up, preferably in a PEP, including the reasoning for it to get done, I think this whole discussion would not have been necessary. Stefan ___ 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] public visibility of python-dev decisions before it's too late
On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnel stefan...@behnel.de wrote: I still consider this is mostly a communication issue. If this change had been properly written up, preferably in a PEP, including the reasoning for it to get done, I think this whole discussion would not have been necessary. Yes, I think we need to keep topic of wider interest in mind when deciding whether or not to write up a PEP, even if the change isn't particularly controversial amongst the core developers. We made a similar mistake with the zipfile and directory execution changes. 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] public visibility of python-dev decisions before it's too late
On 15 Mar, 2011, at 19:31, Greg Ewing wrote: Martin v. Löwis wrote: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. I still think this is going to result in rude shocks to people switching from 2 to 3 and jumping several releases into the 3.x line. You need to update the source of extensions anyway when switching from 2.x to 3.x, this additional change is a minor one. Ronald ___ 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] public visibility of python-dev decisions before it's too late
Am 16.03.11 08:06, schrieb Nick Coghlan: On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnelstefan...@behnel.de wrote: I still consider this is mostly a communication issue. If this change had been properly written up, preferably in a PEP, including the reasoning for it to get done, I think this whole discussion would not have been necessary. Yes, I think we need to keep topic of wider interest in mind when deciding whether or not to write up a PEP, even if the change isn't particularly controversial amongst the core developers. We made a similar mistake with the zipfile and directory execution changes. PEP 5 actually requires that backwards-incompatible changes must be defined in a PEP. This wasn't done in this case; I agree it should have. I guess it's not too late to write this PEP, even though that's after the fact. Regards, Martin ___ 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] public visibility of python-dev decisions before it's too late
On Wed, Mar 16, 2011 at 9:11 AM, Martin v. Löwis mar...@v.loewis.de wrote: Am 16.03.11 08:06, schrieb Nick Coghlan: On Wed, Mar 16, 2011 at 3:20 AM, Stefan Behnelstefan...@behnel.de wrote: I still consider this is mostly a communication issue. If this change had been properly written up, preferably in a PEP, including the reasoning for it to get done, I think this whole discussion would not have been necessary. Yes, I think we need to keep topic of wider interest in mind when deciding whether or not to write up a PEP, even if the change isn't particularly controversial amongst the core developers. We made a similar mistake with the zipfile and directory execution changes. PEP 5 actually requires that backwards-incompatible changes must be defined in a PEP. This wasn't done in this case; I agree it should have. I guess it's not too late to write this PEP, even though that's after the fact. The rationale and initial implementation of the new API are here: http://bugs.python.org/issue5630 Interestingly, there is no definite time frame on the deprecation warnings in that discussion. It was just the standard deprecation in X.Y means removal in X.Y+1 that lead to 3.2 no longer providing the PyCObject API. An after the fact PEP would probably be valuable, as it could document the rationale for the removal, as well as pointing to resources to help folks in Lennart's situation that need to support both PyCObject-only and PyCapsule-only versions of Python from the same C code base. Perhaps Larry would be willing to write it up if we asked? 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] public visibility of python-dev decisions before it's too late
On 16 Mar, 2011, at 9:56, Nick Coghlan wrote: Interestingly, there is no definite time frame on the deprecation warnings in that discussion. It was just the standard deprecation in X.Y means removal in X.Y+1 that lead to 3.2 no longer providing the PyCObject API. Speaking of deprecation warnings: GCC has an __attribute__ option to mark C functions as deprecated. Is that something we should use for C API's that are deprecated? As an example: int old_code (void) __attribute__((__deprecated__)); Will warn when the function is called: t.c:12: warning: ‘old_code’ is deprecated (declared at t.c:6) This would obviously have to be wrapped in a macro that expands to nothing on compilers other than GCC. Ronald ___ 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] public visibility of python-dev decisions before it's too late
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/11 22:16, Georg Brandl wrote: But in any case, by popular demand fix is now removed, and only close and its variants actually closes the issue -- since there is not much chance that you can write close #12345 without actually meaning to close the issue :) Sorry to bother you. What would be the exact wording?. What variants means?. Yesterday I committed a changeset with a commit message of Close issue #8600: test_gdb failures because innocuous warnings, and it didn't automatically close the issue :). Sorry for being so picky ;-). - -- 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/ iQCVAwUBTYDMNZlgi5GaxT1NAQL3bAP/aey6/n0Hx59PsOW0t6v0+eOBcWGZ4r6R 20pvuYa2GJ4GUd6rTcOmIXBdwyfLe9K2r+2hYkSbn4Xg2RrAltXnPEhFuSOKRYfD /v5S4YuwGa3QL7uiKe5qUn7u91KJzLb3vlAqq0TCzJxwLvZq5YeTB1iSXOZ3NoM8 xx/+mHpcUHI= =eDnU -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] public visibility of python-dev decisions before it's too late
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/03/11 16:01, Lennart Regebro wrote: Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. That is a deprecation period of seven and a half months. I strongly opposed CObject deprecation in 2.7, as you can see in http://bugs.python.org/issue9675 and mailing list archives. In (external module) pybsddb http://www.jcea.es/programacion/pybsddb.htm I support Python 2.3, 2.4, 2.5, 2.6, 2.7, 3.1, 3.2 and 3.x. Having to deal with CObject/Capsule was an undesired pain, but the actual support has been painless. What problems are you finding trying to support both CObject and Capsule?. - -- 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/ iQCVAwUBTYDNvplgi5GaxT1NAQIZ+gP8Dtv1EBIUTYYujlY/QcjmmyY+rdXwgZq6 tSJnHsonvaBkG34yY+YM/jw54wA0GFRApvHNtXo6r1AS0Gwei6+Ypb5iGGxdsWmB SdaZhhcEfmaP1u+5Jaq9P3Nco9LfhgxC3ahT/M8uYsGzpC6U4zgh3yjIY08Y1MAp h5cRmF2L6CI= =8MSH -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] public visibility of python-dev decisions before it's too late
2011/3/16 Jesus Cea j...@jcea.es: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/11 22:16, Georg Brandl wrote: But in any case, by popular demand fix is now removed, and only close and its variants actually closes the issue -- since there is not much chance that you can write close #12345 without actually meaning to close the issue :) Sorry to bother you. What would be the exact wording?. What variants means?. Matching this re. :) (?:\b(?Pverbclose[sd]?|closing|)\s+)? -- Regards, Benjamin ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 03/09/2011 01:15 AM, Stefan Behnel wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, I was a bit surprised by it too, and I wrote the Capsule object. (Well, hacked up CObject to give it a new API.) PyCObject_AsVoidPtr emitted a PendingDeprecationWarning in 3.1. I was surprised when it was removed completely in trunk shortly after the release of 3.1. I thought it was supposed to get promoted to DeprecationWarning in 3.2 and then removed in 3.3. But I'm not totally familiar with the policy subtleties of CPython, and the CObject API had enough flaws that I was happy to see it gone, so I kept a still tongue. On 03/14/2011 06:30 PM, Lennart Regebro wrote: But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. Sorry I didn't see your email until just now; I've been tuning out python-dev for a while. Nick Coghlan brought this matter to my attention just this morning. The PyCapsule API is very much like the CObject API. In fact, in Python 3.1 CObject was actually implemented on top of PyCapsule. It should be very easy to support both APIs. Are you still at PyCon? I'm in the core / hg room, and I'd be happy to help you get this code working for both 2.6 and 3.2. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** The one-year deprecation period seems to be in keeping with PEP 5, which states There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. I'm not a release manager for Python but I suspect this is unlikely. Nick has convinced me that I should create the world's first temporal inversion PEP, discussing the justification for adding the Capsule API and (eventually) removing the CObject API. I expect the PEP to discuss coping strategies on how to simultaneously support 2.6 and 3.2. I'm enjoying PyCon too much to write the PEP this week, but I expect I can have a draft up next week. Personally I'm hoping the PEP will be rejected ;) /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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 22:50, Guido van Rossum wrote: I propose we try to find an embedded blogger who participates in python-dev but is focused on making regular blog posts about the interesting tidbits. There's no requirement to be complete (which I think always weighed the python-dev-summaries task down). Ditto for python-ideas -- it would be nice if it was the same person but doesn't have to be. This might be an opportunity for increasing diversity. +1. I would love to see this. Too bad I don't have the time myself to keep up with python-dev python-ideas... Forwarding the request to python-es mailing list. Crossing fingers. - -- 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/ iQCVAwUBTYDSJZlgi5GaxT1NAQIEvwP+MWHZbY+xMhl27K7hC2fPH7QJsz55H0Xb 7FIWSApqdJXL5Uzu+VbGN4IKK7GBCGHXS8t/vTOXcePeqZRnTGIgxVth8NnxcK3M O9+VJIyGaqMghb0BEgSaaryfiZNfbI0mKwAouzgzQsvP2uyX/kzCHQCnxdDsNTWo mxLbKVicaRw= =aA2c -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] public visibility of python-dev decisions before it's too late
I strongly opposed CObject deprecation in 2.7, as you can see in http://bugs.python.org/issue9675 and mailing list archives. Interestingly enough, Lennart would have preferred a longer deprecation period, not a shorter one. So he would have been even more upset had the deprecation not be done in 2.7. Regards, Martin ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 16, 2011, at 11:07 AM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/11 22:50, Guido van Rossum wrote: I propose we try to find an embedded blogger who participates in python-dev but is focused on making regular blog posts about the interesting tidbits. There's no requirement to be complete (which I think always weighed the python-dev-summaries task down). Ditto for python-ideas -- it would be nice if it was the same person but doesn't have to be. This might be an opportunity for increasing diversity. +1. I would love to see this. Too bad I don't have the time myself to keep up with python-dev python-ideas... Forwarding the request to python-es mailing list. Crossing fingers. Jesus, if anyone expresses interest in helping out please have them contact me directly, off list. Thanks, Doug ___ 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] public visibility of python-dev decisions before it's too late
Larry Hastings wrote: The PyCapsule API is very much like the CObject API. In fact, in Python 3.1 CObject was actually implemented on top of PyCapsule. It should be very easy to support both APIs. Perhaps the code for the 3.1 implementation could be pulled out and made available to people in a form that's easy to include in their projects? -- Greg ___ 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] public visibility of python-dev decisions before it's too late
In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Python 2.6's API wasn't removed in 2.7. It remains available. If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. This change conforms to PEP 5: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. If you think a year is too little, you should lobby for a PEP 5 change. Regards, Martin ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 09:20, Martin v. Löwis mar...@v.loewis.de wrote: In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. That is a deprecation period of seven and a half months. If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. And 3.1 to 3.2? There is no major version break there. For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Yes, but we are now in a period of parallell support for Python 2 and Python 3. So it doesn't work like that. We need to support both Python 2 and Python 3 at the same time. Therefore, the deprecation period was seven and a half month, because it was impossible to support the new API before, and impossible to support the new API after, if you need to support both Python 2 and Python 3. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. This change conforms to PEP 5: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. It is too short, and so is 19 months, but this change does *not* conform. //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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mon, Mar 14, 2011 at 19:22, Reid Kleckner reid.kleck...@gmail.com wrote: I don't know how your code works, but handling either type from C seems very straightforward to me. You can simply use #ifdef Py_COBJECT_H to see if the cobject.h header was pulled into Python.h. Similarly for Py_CAPSULE_H. All you lose is that if you do get a PyCObject, there is no way of knowing if the void pointer is of the right type. Good to know. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** Surely, you must be joking. No. //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] public visibility of python-dev decisions before it's too late
Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. No, it didn't. It first appeared in 3.1. That is a deprecation period of seven and a half months. Not true. It's a deprecation period of 19 months and two releases (3.1 and 2.7). If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. And 3.1 to 3.2? There is no major version break there. Right. So for things to be removed there, they have to be deprecated first (and that's what happened). For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Yes, but we are now in a period of parallell support for Python 2 and Python 3. So it doesn't work like that. We need to support both Python 2 and Python 3 at the same time. Therefore, the deprecation period was seven and a half month, because it was impossible to support the new API before, and impossible to support the new API after, if you need to support both Python 2 and Python 3. If you actually had been supporting 2.x and 3.x in parallel for the last two years, you would have had a deprecation period of 19 months and two releases. It's only if you are now migrating from 2 to 3 that you notice the breakage for the first time. Regards, Martin ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/14/11 5:30 PM, Lennart Regebro wrote: Many projects, not only the Zope Toolkit needs to support a lot of versions. The Zope component architecture currently supports 2.4, 2.5 and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can be dropped, but it definitely will be *years* until we can drop support for 2.6. But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. For what it's worth, numpy simultaneously supports Python 2.5-2.7 and 3.1-3.2. It uses PyCObject or PyCapsule APIs as appropriate. We do this from the same codebase. We had to add another layer of indirection, but nothing too bad. You can steal our code here: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_3kcompat.h#L299 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 12:02, Martin v. Löwis mar...@v.loewis.de wrote: If you actually had been supporting 2.x and 3.x in parallel for the last two years, you would have had a deprecation period of 19 months and two releases. It's only if you are now migrating from 2 to 3 that you notice the breakage for the first time. The code in question was ported to Python 3 last year, before both 2.7 and 3.2. I noticed the API change now because it's gone from 3.2. That's how most API changes gets noticed: Things stop working. And that's OK. Deprecation periods are there to help you support multiple versions at the same time. Deprecation notices are helpful, of course, but in this case it doesn't help. Even if I had noticed the deprecation warning in 3.1, I wouldn't have been able to do anything about that, because 2.7 had then not been released, and the new API isn't supported in 2.6. I therefore could not have moved to the new API *because* I support both Python 2.x and 3.x I could have (and still can) support it by using compatibility macros or #ifdefs, sure. But you can do that without a deprecation period. So: without compatibility preprocessing I can no longer support 2.6. 2.7 came out seven and a half months before 3.2. Hence the deprecation period was in practice seven and a half months. Admittedly, in C with the preprocessing it's less of an issue, but the C-extensions is rapidly reaching a position where there seems to be as much compatibility macros as there is C code... :-) How long is this going to continue. What API's are going to be needlessly removed in Python 3.3? Could we please cool down with the backwards incompatibility? //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] public visibility of python-dev decisions before it's too late
I noticed the API change now because it's gone from 3.2. That's how most API changes gets noticed: Things stop working. And that's OK. Deprecation periods are there to help you support multiple versions at the same time. That may be the source of misunderstanding. In my understanding, that's *not* what deprecation periods are there. Instead, they are there to give people time to adjust to the changes before their code will break for good. So during the deprecation period, they should start using the new way of doing things, so that the code is ready when the old way goes away. Deprecation notices are helpful, of course, but in this case it doesn't help. Even if I had noticed the deprecation warning in 3.1, I wouldn't have been able to do anything about that Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). Then, the could would not have been broken in 3.2. I could have (and still can) support it by using compatibility macros or #ifdefs, sure. But you can do that without a deprecation period. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. Could we please cool down with the backwards incompatibility? That's another motivation for deprecation. It gives people a chance to intervene and ask for an extension of the deprecation period, so that they have more time to adjust. Regards, Martin ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote: Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). No I'm not. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. Up until 3.2 that statement was not actually true. Python 2.x was very backwards compatible. The next time somebody tells me that Python isn't stable and breaks backwards compatibility all the time, and says that's why you should use Java, what can I now say? OK, it's just the C-API, but that excuse isn't going to fly... //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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote: Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). No I'm not. The numpy folks have shown it is quite possible to support 3.2 without sacrificing compatibility with earlier versions. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. Up until 3.2 that statement was not actually true. Python 2.x was very backwards compatible. The next time somebody tells me that Python isn't stable and breaks backwards compatibility all the time, and says that's why you should use Java, what can I now say? OK, it's just the C-API, but that excuse isn't going to fly... But given that this situation was unique to the parallel development of 2.x and 3.x, and PEP 5 was applied correctly within each of the parallel lines of development, why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan ncogh...@gmail.com wrote: why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Apparently not, as the code already ran under Python 3.1. //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] public visibility of python-dev decisions before it's too late
On Tue, 15 Mar 2011 18:46:37 -0400 Lennart Regebro rege...@gmail.com wrote: Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. We? You must understand that compatibility rules are quite a burden when it comes to evolving Python's APIs. Making these rules even stricter would probably reduce motivation to contribute to Python for at least some developers (be they core developers or not). Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. This sounds like FUD. Again, such companies can just rely on a commercial vendor to provide support. 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] public visibility of python-dev decisions before it's too late
Martin v. Löwis wrote: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. I still think this is going to result in rude shocks to people switching from 2 to 3 and jumping several releases into the 3.x line. -- Greg ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote: Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. OK, fine. I'm stopping my efforts of porting the ZTK to Python 3 unless somebody pays me then, if that is the attitude from the core developers on this issue. Why should there be third-party libraries available for Python 3.2!? No need, if you want them you can find commercial support, apparently. //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] public visibility of python-dev decisions before it's too late
On Tue, 15 Mar 2011 21:16:58 -0400 Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote: Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. OK, fine. I'm stopping my efforts of porting the ZTK to Python 3 unless somebody pays me then, if that is the attitude from the core developers on this issue. I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. //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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 10:14:12PM -0400, Lennart Regebro wrote: Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It is still. The majority of the responses were informative on backwards compatibility and release process. And suggestive of how things changed from between 2.7, 3.1 and 3.2. And there is a unique problem here that 3.1 was released before 2.7. And things which break backwards compatibility is discussed before any changes are made. So, your comment on python 'always breaking the compatibility' was not correct and perhaps that invoked a strong reaction. -- Senthil ___ 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. This is unfortunate (and the PyCon sprints aren't even over!). I think Lennart's complaint has *some* validity. I think PEP 5 did not anticipate two overlapping lines of development, and in retrospect it was unwise to kill the offending API in 3.2 (even if it is *possible* to deal with it, it's cumbersome). But I do not think that there is a way to undo the damage that was done; putting the missing API back in 3.2.1 will cause other problems (because it would break compatibility between 3.2 and 3.2.1). So Lennart will have to put up with the pragmatics of supporting 2.7 and 3.2 (and others as he desires). But we should learn from the experience and be more cautious with 3.3. Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. -- --Guido van Rossum (python.org/~guido) ___ 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] public visibility of python-dev decisions before it's too late
On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. It seems a bit odd for you to be so surprised about this, considering Python3 is a *huge* compatibility break that broke basically every single thing ever written in Python. And I'm not sure why you're making such a big deal about this one corner of incompatibility -- PyCObject vs. PyCapsule seems like such a trivial and easy to work around issue compared to the massive pain-in-the-ass porting job for all the incompatibilities on the Python-language side of the fence. 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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum gu...@python.org wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. //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] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:58, Lennart Regebro rege...@gmail.com wrote: That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) I meant removed. ___ 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] public visibility of python-dev decisions before it's too late
On 3/15/2011 10:58 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 22:42, Guido van Rossumgu...@python.org wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. I think it's valid that we should consider the affect of libraries that are trying to support 2.x and 3.y (for some values of x and y) at the same time. Speaking for myself, I'll admit I hadn't thought of this during any discussions of changing APIs. We'll only have to consider this for at most 2 more 3.x releases, if we believe the 5 year timeframe (since 3.0) for most projects to migrate. But I agree that there's not much we can do in the capsule case. The ship has sailed on that one. 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. And so was I. I discovered it today. And personally, I don't mind being surprised. And I'm sorry I didn't have time to try out the zope.* packages that support Python 3 on 3.2, but then again the difference was supposed to be between 2.x and 3.x. I didn't expect 3.2 to suddenly be backwards incompatible. Of the eight packages that currently support 3.1 (in trunk), two packages do not compile, and one gets massive test failures (which may only be test failures, and not actual failures). That is *not* good. Perhaps there is a easy way to map the API's with #defines, but if this is the case, why was the change done in the first place? But the problem here is not the surprise. If I had known about this beforehand, that would only have helped, if I could have convinced others that the API shouldn't have been removed! The problem is the deprecation period! Many projects, not only the Zope Toolkit needs to support a lot of versions. The Zope component architecture currently supports 2.4, 2.5 and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can be dropped, but it definitely will be *years* until we can drop support for 2.6. But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. It can possibly be removed in 3.3, but better would be 3.4. It must be possible to support 3-4 releases of Python with the current release speed. We need to support python versions that are five years old or so. In fact the deprecation period should probably be somewhat similar to the security fix period. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mon, Mar 14, 2011 at 6:30 PM, Lennart Regebro rege...@gmail.com wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. And so was I. I discovered it today. And personally, I don't mind being surprised. And I'm sorry I didn't have time to try out the zope.* packages that support Python 3 on 3.2, but then again the difference was supposed to be between 2.x and 3.x. I didn't expect 3.2 to suddenly be backwards incompatible. Of the eight packages that currently support 3.1 (in trunk), two packages do not compile, and one gets massive test failures (which may only be test failures, and not actual failures). That is *not* good. Perhaps there is a easy way to map the API's with #defines, but if this is the case, why was the change done in the first place? I don't know how your code works, but handling either type from C seems very straightforward to me. You can simply use #ifdef Py_COBJECT_H to see if the cobject.h header was pulled into Python.h. Similarly for Py_CAPSULE_H. All you lose is that if you do get a PyCObject, there is no way of knowing if the void pointer is of the right type. Many projects, not only the Zope Toolkit needs to support a lot of versions. The Zope component architecture currently supports 2.4, 2.5 and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can be dropped, but it definitely will be *years* until we can drop support for 2.6. But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** Surely, you must be joking. Python already has a long release cycle. I'm not familiar with this feature, but suppose it is decided that there is sufficient cause to remove a feature. First, we have to wait until the next release to deprecate it. Then we have to wait yet one more release to remove it. With an 18-month release cycle, that's 27 months on average. To me, that is a very long time to wait. In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? PyCObject was deprecated in 3.1, as well as 2.7. http://docs.python.org/release/3.1.3/c-api/cobject.html#PyCObject Reid ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 11, 2011, at 7:12 PM, Paul Moore wrote: On 11 March 2011 23:24, Guido van Rossum gu...@python.org wrote: I'm interested in the task and I guess I'll follow-up with Doug Hellman. I don't follow -ideas close enough to summarize it, but I'd contribute to a -dev blog. Awesome! (And we don't need to stop at one blogger. Many hands make light work.) I'm interested but probably haven't got time to take something like this on properly. Helping out occasionally would probably be something I could do, though. (Was that tentative enough? :-)) I'm on -ideas, too, so I could do something there as well. Thanks Brian and Paul! I have sent you both invitations to join the communications team mailing list so we can work out the details. Doug ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, 09 Mar 2011 07:15:07 +0100 Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A better alternative IMHO would be to revive the community buildbots (pybots.org), under the same form or another. 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2011 03:24 PM, Antoine Pitrou wrote: On Wed, 09 Mar 2011 07:15:07 +0100 Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A better alternative IMHO would be to revive the community buildbots (pybots.org), under the same form or another. How would more buildbots help the visibility of changes being landed to the language or standard library? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk16i68ACgkQ+gerLs4ltQ6RaACeMOXvAqUYByjx5lFUjMcVH0Z9 ZtIAn0MtoBD3LWc6GZsUCrQmL3DJqHVC =rZ+o -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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann doug.hellm...@gmail.com wrote: On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. I propose we try to find an embedded blogger who participates in python-dev but is focused on making regular blog posts about the interesting tidbits. There's no requirement to be complete (which I think always weighed the python-dev-summaries task down). Ditto for python-ideas -- it would be nice if it was the same person but doesn't have to be. This might be an opportunity for increasing diversity. -- --Guido van Rossum (python.org/~guido) ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Fri, 11 Mar 2011 15:53:03 -0500 Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2011 03:24 PM, Antoine Pitrou wrote: On Wed, 09 Mar 2011 07:15:07 +0100 Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A better alternative IMHO would be to revive the community buildbots (pybots.org), under the same form or another. How would more buildbots help the visibility of changes being landed to the language or standard library? They would help check that changes don't cause regressions in major third-party packages such as CPython. 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, 9 Mar 2011 15:40:56 -0500 Doug Hellmann doug.hellm...@gmail.com wrote: The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. [...] I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. If you find someone who likes to do it then it's fine. Otherwise, I'm not sure it's a good use of our (the developers') time. We already explain changes in the documentation, in Misc/NEWS and in the what's new documents... 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 11, 2011 4:52 PM, Guido van Rossum gu...@python.org wrote: On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann doug.hellm...@gmail.com wrote: On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. I propose we try to find an embedded blogger who participates in python-dev but is focused on making regular blog posts about the interesting tidbits. There's no requirement to be complete (which I think always weighed the python-dev-summaries task down). Ditto for python-ideas -- it would be nice if it was the same person but doesn't have to be. This might be an opportunity for increasing diversity. -- --Guido van Rossum (python.org/~guido) I'm interested in the task and I guess I'll follow-up with Doug Hellman. I don't follow -ideas close enough to summarize it, but I'd contribute to a -dev blog. ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Fri, 11 Mar 2011 22:56:49 +0100 Antoine Pitrou solip...@pitrou.net wrote: On Fri, 11 Mar 2011 15:53:03 -0500 Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2011 03:24 PM, Antoine Pitrou wrote: On Wed, 09 Mar 2011 07:15:07 +0100 Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A better alternative IMHO would be to revive the community buildbots (pybots.org), under the same form or another. How would more buildbots help the visibility of changes being landed to the language or standard library? They would help check that changes don't cause regressions in major third-party packages such as CPython. Sorry, I meant Cython, not CPython... 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Fri, Mar 11, 2011 at 5:05 PM, Brian Curtin brian.cur...@gmail.com wrote: On Mar 11, 2011 4:52 PM, Guido van Rossum gu...@python.org wrote: On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann doug.hellm...@gmail.com wrote: On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. I propose we try to find an embedded blogger who participates in python-dev but is focused on making regular blog posts about the interesting tidbits. There's no requirement to be complete (which I think always weighed the python-dev-summaries task down). Ditto for python-ideas -- it would be nice if it was the same person but doesn't have to be. This might be an opportunity for increasing diversity. -- --Guido van Rossum (python.org/~guido) I'm interested in the task and I guess I'll follow-up with Doug Hellman. I don't follow -ideas close enough to summarize it, but I'd contribute to a -dev blog. Awesome! (And we don't need to stop at one blogger. Many hands make light work.) -- --Guido van Rossum (python.org/~guido) ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 11 March 2011 23:24, Guido van Rossum gu...@python.org wrote: I'm interested in the task and I guess I'll follow-up with Doug Hellman. I don't follow -ideas close enough to summarize it, but I'd contribute to a -dev blog. Awesome! (And we don't need to stop at one blogger. Many hands make light work.) I'm interested but probably haven't got time to take something like this on properly. Helping out occasionally would probably be something I could do, though. (Was that tentative enough? :-)) I'm on -ideas, too, so I could do something there as well. Paul. ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel stefan...@behnel.de wrote: A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents I've wondered myself if we should simply be more inclined to create PEPs for changes with a wide impact, even if they're technically a CPython-specific implementation decision (cf. zipfile/directory execution, migration from PyCObject to PyCapsule API). Both of those were backed by extensive tracker and mailing list discussions, but there's no easy reference point for anyone coming across them later. 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. -- Tim Lesher tles...@gmail.com ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel stefan...@behnel.de wrote: Martin v. Löwis, 08.03.2011 23:47: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. Maybe the what's new document could at least include a link to the relevant python-dev discussion/decision, so that fewer people have to ask back? Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents Stefan A python dev blog/news site is on the list of topics for the language summit tomorrow at PyCon. Doug hellmann is going to be managing that discussion - but there is a general agreement we have to spread word outside of core and into the general world a little bit more - and this also applies to other python VMs as well. jesse ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? I think what's new serves this purpose properly. Usually, every time I commit a new feature, I update the what's new file as well. In fact we already have a partial roadmap for Python 3.3: http://docs.python.org/dev/whatsnew/3.3.html I'm not sure who else is doing the same though. If we agree that every time a new feature is added we also update the what's new file we can have such a roadmap with relatively no effort. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/3/9 Stefan Behnel stefan...@behnel.de: Martin v. Löwis, 08.03.2011 23:47: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. Maybe the what's new document could at least include a link to the relevant python-dev discussion/decision, so that fewer people have to ask back? Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents Stefan ___ 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/g.rodola%40gmail.com ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. Doug ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, 9 Mar 2011 19:42:36 +0100 Giampaolo Rodolà g.rod...@gmail.com wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? I think what's new serves this purpose properly. Usually, every time I commit a new feature, I update the what's new file as well. In fact we already have a partial roadmap for Python 3.3: http://docs.python.org/dev/whatsnew/3.3.html Perhaps the part of the what's new document which deals with porting issues and compatibility breakage would need more highlighting? 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/9/2011 4:14 PM, Antoine Pitrou wrote: On Wed, 9 Mar 2011 19:42:36 +0100 Perhaps the part of the what's new document which deals with porting issues and compatibility breakage would need more highlighting? That could go at the tops. Deletions in 3.3 ... Planned deletions in future versions ... Porting issues ... then the usual ... -- 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/9/2011 9:50 AM, Tim Lesher wrote: We used to do biweekly-ish Python-Dev summaries for this reason. They were, is a sense, too detailed, complete, and voluminous. In whatever format, terser announcement of just things others really need to know - like decisions that affect them, would probably be more useful. There is also python-announce, but I do not follow it. -- 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
[Python-Dev] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
Martin v. Löwis, 08.03.2011 23:47: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. Maybe the what's new document could at least include a link to the relevant python-dev discussion/decision, so that fewer people have to ask back? Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents Stefan ___ 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
