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
12 matches
Mail list logo
