[Python-ideas] PEP 550 v2

[Yury Selivanov]

On Fri, Aug 18, 2017 at 2:12 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Nathaniel Smith schrieb am 16.08.2017 um 09:18:
>> On Tue, Aug 15, 2017 at 4:55 PM, Yury Selivanov wrote:
>>> Here's the PEP 550 version 2.
>> Awesome!
>
> +1
>
>>> Backwards Compatibility
>>> =======================
>>>
>>> This proposal preserves 100% backwards compatibility.
>>
>> While this is mostly true in the strict sense, in practice this PEP is
>> useless if existing thread-local users like decimal and numpy can't
>> migrate to it without breaking backcompat. So maybe this section
>> should discuss that?
>>
>> (For example, one constraint on the design is that we can't provide
>> only a pure push/pop API, even though that's what would be most
>> convenient context managers like decimal.localcontext or
>> numpy.errstate, because we also need to provide some backcompat story
>> for legacy functions like decimal.setcontext and numpy.seterr.)
>
> I agree with Nathaniel that many projects that can benefit from this
> feature will need to keep supporting older Python versions as well. In the
> case of Cython, that's Py2.6+. We already have the problem that the
> asynchronous finalisation of async generators cannot be supported in older
> Python versions ("old" as in Py3.5 and before), so we end up with a
> language feature that people can use in Py2.6, but not completely/safely.
>
> I can't say yet how difficult it will be to integrate the new
> infrastructure that this PEP proposes into a backwards compatible code
> base, but if there's something we can think of now in order to help
> projects keep supporting older Python versions in the same code base, given
> the constraints of their existing APIs and semantics - that would be great.

I think it's Cython's quest to try to backport support of all new
Python 3.x language features to be 2.6-compatible, which sometimes can
be questionable.  You can add support of PEP 550 semantics to code
that was compiled with Cython, but pure Python code won't be able to
support it.  This, in my opinion, could cause more confusion than
benefit, so for Cython I think the solution is to do nothing in this
case.

We'll (maybe) backport some functionality to contextlib2. In my
opinion, any code that uses contextlib2 in Python should work exactly
the same when it's compiled with Cython.

Yury