Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Raymond Hettinger
On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate something and add a DeprecationWarning; 2) forget about it after a while; 3) wait a few versions until

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Xavier Morel
On 2011-11-28, at 10:30 , Raymond Hettinger wrote: On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: How about we agree that actually removing things is usually bad for users. It will be best if the core devs had a strong aversion to removal. Instead, it is best to mark APIs as obsolete with a

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Nick Coghlan
On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel catch-...@masklinn.net wrote: Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Steven D'Aprano
Xavier Morel wrote: Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced by default). Both choices are harmful to

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread exarkun
On 12:14 pm, st...@pearwood.info wrote: Xavier Morel wrote: Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Xavier Morel
On 2011-11-28, at 13:06 , Nick Coghlan wrote: On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel catch-...@masklinn.net wrote: Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Petri Lehtinen
Raymond Hettinger wrote: How about we agree that actually removing things is usually bad for users. It will be best if the core devs had a strong aversion to removal. Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead. There is rarely a need to

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Barry Warsaw
On Nov 28, 2011, at 03:36 PM, Petri Lehtinen wrote: Raymond Hettinger wrote: That may serve a notion of tidyness or somesuch but in reality it is a PITA for users making it more difficult to upgrade python versions and making it more difficult to use published recipes. I'm strongly against

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Michael Foord
On 28/11/2011 13:36, Petri Lehtinen wrote: Raymond Hettinger wrote: How about we agree that actually removing things is usually bad for users. It will be best if the core devs had a strong aversion to removal. Instead, it is best to mark APIs as obsolete with a recommendation to use something

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Matt Joiner
On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano st...@pearwood.info wrote: Xavier Morel wrote: Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them

Re: [Python-Dev] PyPy 1.7 - widening the sweet spot

2011-11-28 Thread Brett Cannon
On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 25 Nov 2011 12:37:59 -0500 Brett Cannon br...@python.org wrote: On Thu, Nov 24, 2011 at 07:46, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Stephen J. Turnbull
Matt Joiner writes: This is a great argument. But people want to see new, bigger better things in the standard library, and the #1 reason cited against this is we already have too much. I think that's where the issue lies: Either lots of cool nice stuff is added and supported (we all want

[Python-Dev] New features

2011-11-28 Thread Antoine Pitrou
On Tue, 29 Nov 2011 00:19:50 +0900 Stephen J. Turnbull step...@xemacs.org wrote: Deprecated features are pretty much irrelevant to the height of the bar for new features. The problem is that there are a limited number of folks doing long term maintenance of the standard library, and an

[Python-Dev] New features

2011-11-28 Thread Stephen J. Turnbull
Antoine Pitrou writes: Actually, we don't often get patches for new features. Many new features are implemented by core developers themselves. Right. That's not inconsistent with what I wrote, as long as would-be feature submitters realize what the standards for an acceptable feature patch

Re: [Python-Dev] Deprecation policy

2011-11-28 Thread Antoine Pitrou
Hi, On Mon, 28 Nov 2011 01:30:53 -0800 Raymond Hettinger raymond.hettin...@gmail.com wrote: On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate

Re: [Python-Dev] Long term development external named branches and periodic merges from python

2011-11-28 Thread Jesus Cea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/11/11 06:06, Nick Coghlan wrote: So, in this context, if the tracker create patch diff from BASE, it is not safe to merge changes from mainline to the branch, because if so create patch would include code not related to my work. No,

Re: [Python-Dev] Long term development external named branches and periodic merges from python

2011-11-28 Thread Nick Coghlan
It's published as part of the tracker repo, although I'm not sure exactly where it lives. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Nov 29, 2011 6:50 AM, Jesus Cea j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/11/11 06:06, Nick