> My assumption is, there is still in active interest in documenting our
> deprecation policy, and it might be a good idea to move forward with a
> pep PR?
+1
> I suspect that there is something in the devguide also
I searched the devguide about deprecation policy, and it didn't turn up
anything.
On 4/9/2017 3:09 PM, Senthil Kumaran wrote:
I was looking for our Deprecation Policy and stumbled on this thread
from January 2016.
-
PEP: XXX
Title: Deprecation Policy
Version: $Revision$
Last-Modified: $Date$
Author: Ezio Melotti
Status: Draft
Type: Process
Content-Type: text/x-rst
C
I was looking for our Deprecation Policy and stumbled on this thread
from January 2016.
-
PEP: XXX
Title: Deprecation Policy
Version: $Revision$
Last-Modified: $Date$
Author: Ezio Melotti
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 29-Jan-2016
Post-History:
https://mai
On Feb 06, 2016, at 04:54 PM, Nick Coghlan wrote:
>Although if anyone has both the C/POSIX skills and the necessary
>roundtuits to help move Geoffrey Thomas's "pythonmux" [1] idea
>forward, we may be able to settle the preferred behaviour of the
>"/usr/bin/python" path once and for all.
+1 (but t
On 3 February 2016 at 11:00, Barry Warsaw wrote:
> On Feb 03, 2016, at 11:03 AM, Steven D'Aprano wrote:
>
>>The point being, I'm not entirely sure I agree that a major version bump
>>would *necessarily* be considered a big deal, let alone a barrier to
>>adoption.
>
> The problem isn't so much the
On Feb 03, 2016, at 11:03 AM, Steven D'Aprano wrote:
>The point being, I'm not entirely sure I agree that a major version bump
>would *necessarily* be considered a big deal, let alone a barrier to
>adoption.
The problem isn't so much the major version bump, but what to do about the
command name o
On Tue, Feb 02, 2016 at 09:40:52AM -0500, Barry Warsaw wrote:
> On Feb 02, 2016, at 03:33 PM, Ezio Melotti wrote:
>
> >Changing the major version should be done for incompatible changes, and just
> >doing it after 3.9 will probably just create confusion for both users that
> >will wonder if it's i
On 2/2/2016 9:54 AM, R. David Murray wrote:
On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti wrote:
On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum wrote:
Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.
I think we should continue with 3.10, 3.11, etc.
Chan
On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti wrote:
> On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum wrote:
> > Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11,
> > etc.
> >
>
> I think we should continue with 3.10, 3.11, etc.
> Changing the major version should
On Feb 02, 2016, at 03:33 PM, Ezio Melotti wrote:
>Changing the major version should be done for incompatible changes, and just
>doing it after 3.9 will probably just create confusion for both users that
>will wonder if it's incompatible with Python 3 and for things like the
>executable name. Hop
On Tue, Feb 2, 2016 at 4:54 PM, R. David Murray wrote:
> On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti
> wrote:
>> On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum wrote:
>> > Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11,
>> > etc.
>> >
>>
>> I think we should
On Sat, Jan 30, 2016 at 4:08 AM, Martin Panter wrote:
>> What and when to deprecate
>> ==
>>
>> * The number of releases before an API is removed is decided
>> on a case-by-case basis depending on widely used the API is
>
> depending on [how] widely used
>
>> * In general
On Fri, Jan 29, 2016 at 11:59 PM, Serhiy Storchaka wrote:
> On 29.01.16 21:56, Ezio Melotti wrote:
>>
>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka
>> wrote:
>>>
>>> What about adding deprecations in bugfix releases? If current behavior is
>>> obviously incorrect and should be fixed in dev
On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum wrote:
> Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11,
> etc.
>
I think we should continue with 3.10, 3.11, etc.
Changing the major version should be done for incompatible changes,
and just doing it after 3.9 will pro
On Sat, Jan 30, 2016 at 1:39 AM, Barry Warsaw wrote:
> On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:
>
>>+1 from me as well, especially once Serhiy's comments are addressed.
>
> Me too, but only if you add a PendingDeprecationWarning to
> PendingDeprecationWarning .
>
The original plan actual
On 1/30/2016 3:39 AM, Nick Coghlan wrote:
Me too, but only if you add a PendingDeprecationWarning to
PendingDeprecationWarning .
There were some discussions a while back of restoring a distinction
between the two by having code executed directly at the REPL (whether
at the command line or in I
On 30 January 2016 at 13:28, Martin Panter wrote:
> On 29 January 2016 at 21:59, Serhiy Storchaka wrote:
>> On 29.01.16 21:56, Ezio Melotti wrote:
>>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka
>>> wrote:
Some deprecation can be documentation-only.
>>>
>>> Do you have examples where
On 30 January 2016 at 09:39, Barry Warsaw wrote:
> On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:
>
>>+1 from me as well, especially once Serhiy's comments are addressed.
Likewise - an additional proofreading pass would be useful, but the
overall content looks fine to me.
> Me too, but only i
On Fri, Jan 29, 2016 at 7:28 PM, Martin Panter wrote:
> I thought Python 4 was mainly a myth or fantasy at this stage?
We are already in Python 3.6. If we go with a release every 1.5 years,
then Python 4 is probably 6 years away.
___
python-committer
On 29 January 2016 at 21:59, Serhiy Storchaka wrote:
> On 29.01.16 21:56, Ezio Melotti wrote:
>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka
>> wrote:
>>> Some deprecation can be documentation-only.
>>
>> Do you have examples where this has been done?
>
> An attribute of a module. [. . .]
>
> What and when to deprecate
> ==
>
> * The number of releases before an API is removed is decided
> on a case-by-case basis depending on widely used the API is
depending on [how] widely used
> * In general it's better to be conservative, and if the API is
> deprecated
Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.
I also want the 3->4 transition to feel like a non-event for most
users. How we'll do that I don't know yet, but I want it to be a lot
smoother than 2->3.
--
--Guido van Rossum (python.org/~guido)
___
On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:
>+1 from me as well, especially once Serhiy's comments are addressed.
Me too, but only if you add a PendingDeprecationWarning to
PendingDeprecationWarning .
depreception-ly y'rs,
-Barry
___
python-commi
On Fri, 29 Jan 2016 at 11:57 Ezio Melotti wrote:
> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka
> wrote:
> > On 29.01.16 19:11, Ezio Melotti wrote:
> [SNIP]
> >> Deprecation Process
> >> ===
> >>
> >> These are the steps required to deprecate and remove an API:
> >>
> >> 1.
On 29.01.16 21:56, Ezio Melotti wrote:
On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka wrote:
What about adding deprecations in bugfix releases? If current behavior is
obviously incorrect and should be fixed in development branch, but this can
break existing code that implicitly depends on cu
On Fri, 29 Jan 2016 at 09:33 Senthil Kumaran wrote:
> +1 to this proposal. I reviewed the contents and I feel it is
> comprehensive.
>
+1 from me as well, especially once Serhiy's comments are addressed.
-Brett
___
python-committers mailing list
pytho
On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka wrote:
> On 29.01.16 19:11, Ezio Melotti wrote:
>>
>> Deprecation Warnings
>>
>>
>> Python offers two kinds of deprecation warnings:
>>
>> * ``PendingDeprecationWarning``
>> * ``DeprecationWarning``
>>
>> Initially, only ``Pend
Hi,
in the past I suggested to document our deprecation policy on a PEP.
Since the issue came up again on a few issues on the tracker and on
#python-dev, I adapted the content of my previous email and wrote a
PEP.
Attached you can find the full text, including references to the
previous discussion
On 29.01.16 19:11, Ezio Melotti wrote:
Deprecation Warnings
Python offers two kinds of deprecation warnings:
* ``PendingDeprecationWarning``
* ``DeprecationWarning``
Initially, only ``PendingDeprecationWarning``\ s were silenced by
default. Starting from Python 2.7, ``Dep
+1 to this proposal. I reviewed the contents and I feel it is comprehensive.
It should be easy to follow for any deprecations. Also, we should give some
examples of how
the deprecated-removed directive will be used.
Since our policy itself is very subjective (for good reasons), I propose
that we
30 matches
Mail list logo
