On Wed, May 9, 2018 at 2:53 AM, Serhiy Storchaka wrote:
> 08.05.18 19:10, Ethan Furman пише:
>>>
>>> X.Y+1: added a deprecation warning. Many users need to support only two
>>> recent versions and can move to using the
>>> replacement now.
>>
>>
>> I'm curious how you arrived at this conclusion?
08.05.18 19:10, Ethan Furman пише:
X.Y+1: added a deprecation warning. Many users need to support only
two recent versions and can move to using the
replacement now.
I'm curious how you arrived at this conclusion? I know I've only worked
at two different Python-using companies, but neither a
04.05.18 22:08, Matthias Bussonnier пише:
Maybe to push people forward, but from experience it is hard to predict
future, so saying when
it _will_ be remove is hard.
Right. But the data of removing is usually specified when the code for
removing already is written, or even merged in the next
On Tue, May 08, 2018 at 03:20:50PM +0200, Stéphane Blondon wrote:
> I wonder if it would be interesting to have a package available by
> pypi.org which would provide the removed features.
[...]
> Cons:
> - it pushes the question to how many times the previous behavior should
> be maintained from
08.05.18 18:51, Joni Orponen пише:
If one can import from the future can one can also import from the past?
One can move removed feature to a third-party module and import them
from it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail
On 05/04/2018 11:48 AM, Serhiy Storchaka wrote:
04.05.18 20:57, Matthias Bussonnier пише:
But when I hit a DeprecationWarning message there is one crucial piece of
information missing most of the time: Since which version number it's deprecated
(and sometime since when the replacement is avail
On Tue, May 8, 2018 at 3:20 PM, Stéphane Blondon wrote:
> Le 02/05/2018 à 11:11, Victor Stinner a écrit :
> > * Communicate on python-dev, Twitter, Python Insider blog, etc.
> > * Collaborate with major Python projects to help them to migrate the
> alternative
>
> I wonder if it would be interest
Le 02/05/2018 à 11:11, Victor Stinner a écrit :
> * Communicate on python-dev, Twitter, Python Insider blog, etc.
> * Collaborate with major Python projects to help them to migrate the
> alternative
I wonder if it would be interesting to have a package available by
pypi.org which would provide th
On 5 May 2018 at 07:59, Terry Reedy wrote:
> On 5/2/2018 5:11 AM, Victor Stinner wrote:
>
> As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
>> the Move to Python 3" thread, I will like to clarify how a feature
>> should be removed from Python.
>>
>
> Would it be possible (and
Sent: Friday, May 4, 2018 15:24
To: Serhiy Storchaka
Cc: python-dev
Subject: Re: [Python-Dev] Process to remove a Python feature
2018-05-04 20:48 GMT+02:00 Serhiy Storchaka :
> I think the information about since which version number it will be removed
> is more useful.
About deprecation,
On 5/4/2018 6:18 PM, Victor Stinner wrote:
2018-05-04 23:59 GMT+02:00 Terry Reedy :
Would it be possible (and sensible) to use the 2to3 machinery to produce
36to37.py, etc., to do mechanical replacements when possible and flag other
things when necessary?
I suggest you to watch Daniele Esposti
2018-05-04 20:48 GMT+02:00 Serhiy Storchaka :
> I think the information about since which version number it will be removed
> is more useful.
About deprecation, there is the funny story of bytes filenames on
Windows. I deprecated this feature in Windows 3.3 since it was broken.
I really wanted har
2018-05-04 23:59 GMT+02:00 Terry Reedy :
> Would it be possible (and sensible) to use the 2to3 machinery to produce
> 36to37.py, etc., to do mechanical replacements when possible and flag other
> things when necessary?
I suggest you to watch Daniele Esposti's talk "Evolution or stagnation
programm
On 5/2/2018 5:11 AM, Victor Stinner wrote:
As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
the Move to Python 3" thread, I will like to clarify how a feature
should be removed from Python.
Would it be possible (and sensible) to use the 2to3 machinery to produce
36to37.py,
On Fri, 4 May 2018 at 12:09 Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:
> On Fri, 4 May 2018 at 11:49, Serhiy Storchaka wrote:
>
>> 04.05.18 20:57, Matthias Bussonnier пише:
>> > But when I hit a DeprecationWarning message there is one crucial piece
>> of
>> > information missing m
On Fri, 4 May 2018 at 11:49, Serhiy Storchaka wrote:
> 04.05.18 20:57, Matthias Bussonnier пише:
> > But when I hit a DeprecationWarning message there is one crucial piece of
> > information missing most of the time: Since which version number it's
> > deprecated
> > (and sometime since when the
No, the reason they're hidden by default is that for most users they're not
actionable most of the time.
On Fri, May 4, 2018 at 11:55 AM, Nathaniel Smith wrote:
> On Fri, May 4, 2018, 11:50 Serhiy Storchaka wrote:
>
>>
>> Ideally any deprecated feature should have a replacement, and this
>> rep
On Fri, May 4, 2018, 11:50 Serhiy Storchaka wrote:
>
> Ideally any deprecated feature should have a replacement, and this
> replacement should be available in at least one version before adding
> the deprecation warning.
>
> X.Y: added a replacement
>
> X.Y+1: added a deprecation warning. Many us
04.05.18 20:57, Matthias Bussonnier пише:
But when I hit a DeprecationWarning message there is one crucial piece of
information missing most of the time: Since which version number it's
deprecated
(and sometime since when the replacement is available could be good if
overlap
between functional
I would like to take a step back,
I think that for removal of feature you need to make sure that the "old
way" is
not common enough. I think that in many context, users of Python see
DeprecationWarnings as a stick. A deprecation warning means you'll have to
do
some work. A pep or a document that l
04.05.18 16:14, Steven D'Aprano пише:
Have there been many features removed since 3.1? I know there were some
features removed in 3.0, like callable(), which were later put back in,
but I can't think of anythin removed since then. If there were, the pace
of it is pretty slow.
Read "What's New"
On Fri, May 04, 2018 at 12:56:57PM +0200, Victor Stinner wrote:
> Sorry, when I wrote "Python 4" I mean "the new Python release which
> introduces a lot of backward incompatible changes and will annoy
> everyone". It can be Python 3.9 or 3.10, or whatever version
> (including 4.3 if you want) :-)
2018-05-02 19:24 GMT+02:00 Brett Cannon :
> On Wed, 2 May 2018 at 02:12 Victor Stinner wrote:
>> Does it mean that the Python 3 release following Python 2 end-of-life
>> (2020) will be our next feared "Python 4"? Are we going to remove all
>> deprecated features at once, to maximize incompatibilit
On Thu, 3 May 2018 at 12:01 Facundo Batista
wrote:
> 2018-05-02 14:24 GMT-03:00 Brett Cannon :
>
> >> Maybe we should create a tool to list features scheduled for removal,
> >> and open a discussion to check each removal?
> >
> > I don't know if a tool is necessary. We could have a meta issue or
2018-05-02 14:24 GMT-03:00 Brett Cannon :
>> Maybe we should create a tool to list features scheduled for removal,
>> and open a discussion to check each removal?
>
> I don't know if a tool is necessary. We could have a meta issue or text file
> somewhere to track what's to be removed in a certain
On Wed, 2 May 2018 at 02:12 Victor Stinner wrote:
> Hi,
>
> As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
> the Move to Python 3" thread, I will like to clarify how a feature
> should be removed from Python.
>
> We have multiple tools:
>
> * Emit a PendingDeprecationWarning
2018-05-02 11:17 GMT+02:00 Antoine Pitrou :
> It's at least possible with gcc, clang and MSVC:
> https://stackoverflow.com/questions/295120/c-mark-as-deprecated/295229#295229
>
> You can even add a deprecation message.
Aha, I opened an issue: https://bugs.python.org/issue33407 "Implement
Py_DEPREC
On Wed, 2 May 2018 11:11:16 +0200
Victor Stinner wrote:
>
> Removing a feature from the C API is more complex, since there is no
> portable way to emit a deprecation warning at compilation. There is
> Py_DEPRECATED() which seems to only be available on GCC (3.1 and
> newer).
It's at least possib
Hi,
As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
the Move to Python 3" thread, I will like to clarify how a feature
should be removed from Python.
We have multiple tools:
* Emit a PendingDeprecationWarning warning at runtime for *slow*
deprecation (remove a feature in at
29 matches
Mail list logo
