On Sat, 25 Jan 2014 18:30:24 -0800
Raymond Hettinger wrote:
>
> On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
>
> > Nick also suggested to document
> > our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> > http://www.python.org/dev/peps/pep-0005/ ).
>
> Here's a few though
On 26 January 2014 12:30, Raymond Hettinger wrote:
>
> On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
>
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
>
>
> Here's a few thoughts on deprecatio
On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
Here's a few thoughts on deprecations:
* If we care at all about people moving to Python 3, the
On Sat, Jan 25, 2014 at 8:29 AM, Ezio Melotti wrote:
> Hi,
> a couple of years ago I suggested to define and document our
> deprecation policy in this thread:
> https://mail.python.org/pipermail/python-dev/2011-October/114199.html
> I didn't receive many replies and eventually nothing was done.
>
On 01/25/2014 05:29 AM, Ezio Melotti wrote:
a couple of years ago I suggested to define and document our
deprecation policy
+1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Hi,
a couple of years ago I suggested to define and document our
deprecation policy in this thread:
https://mail.python.org/pipermail/python-dev/2011-October/114199.html
I didn't receive many replies and eventually nothing was done.
Lately the same issue came up on #python-dev and Larry and Nick
su
I like this article on it:
http://semver.org/
The following snippets being relevant here:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated
2011/11/29 Nick Coghlan :
> On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw wrote:
>> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>>
>>>Well, that's why I think the version number components are not
>>>correctly named. I don't think any of the 2.x or 3.x releases can be
>>>called "minor" by
On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw wrote:
> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>
>>Well, that's why I think the version number components are not
>>correctly named. I don't think any of the 2.x or 3.x releases can be
>>called "minor" by any stretch of the word. A quick
Am 29.11.2011 13:46, schrieb Petri Lehtinen:
> Michael Foord wrote:
>> We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
>> just Python's terminology.
>
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, releaselevel and ser
On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>Well, that's why I think the version number components are not
>correctly named. I don't think any of the 2.x or 3.x releases can be
>called "minor" by any stretch of the word. A quick glance at
>http://docs.python.org/dev/whatsnew/index.html sh
On Tue, Nov 29, 2011 at 02:46:06PM +0200, Petri Lehtinen wrote:
> Michael Foord wrote:
> > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> > just Python's terminology.
>
> Even though (in the documentation) Python's version number components
> are called major, minor, micro,
On Tue, 29 Nov 2011 14:46:06 +0200
Petri Lehtinen wrote:
> Michael Foord wrote:
> > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> > just Python's terminology.
>
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, relea
Michael Foord wrote:
> We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> just Python's terminology.
Even though (in the documentation) Python's version number components
are called major, minor, micro, releaselevel and serial, in this
order? So when the minor version component
Hi,
On Mon, 28 Nov 2011 01:30:53 -0800
Raymond Hettinger 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 something and add a Depre
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
On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano 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 Depreca
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 el
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 ag
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
On 2011-11-28, at 13:06 , Nick Coghlan wrote:
> On Mon, Nov 28, 2011 at 7:53 PM, 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 m
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 b
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 us
On Mon, Nov 28, 2011 at 7:53 PM, 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 b
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
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 unt
Hi,
+1 to all Ezio said. One specific remark:
PendingDeprecationWarning could just become an alias of
DeprecationWarning, but maybe there is code out there that relies on the
distinction, and there is no real value in making it an alias (there is
value in removing it altogether, but we can’t do
On Mon, Oct 24, 2011 at 06:17, Antoine Pitrou wrote:
> On Mon, 24 Oct 2011 15:58:11 +0300
> Ezio Melotti wrote:
>>
>> I suggest to follow the following process:
>> 1) deprecate something and add a DeprecationWarning;
>> 2) decide how long the deprecation should last;
>> 3) use the deprec
On Mon, 24 Oct 2011 15:58:11 +0300
Ezio Melotti wrote:
>
> I suggest to follow the following process:
>1) deprecate something and add a DeprecationWarning;
>2) decide how long the deprecation should last;
>3) use the deprecated-remove[1] directive to document it;
>4) add a test th
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 someone notices it;
4) actually remove it;
I suggest
30 matches
Mail list logo
