[Python-ideas] PEP 550 v2

[Nick Coghlan]

On 18 August 2017 at 16:12, 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:
>>> 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.

One aspect of this that we're considering is to put the Python level
API in contextlib rather than in sys.

That has the pragmatic benefit that contextlib2 then becomes the
natural home for an API backport, and we should be able to get the
full *explicit* API working on older versions (even if it means
introducing an optional C extension module as a dependency to get that
part of the API working fully).

To backport the isolation of generators, we'd likely be able to
provide a decorator that explicitly isolated generators, but it
wouldn't be feasible to backport implicit isolation. The same would go
for the various other proposals for implicit isolation - when running
on older versions, the general principle would be "if you (or a
library/framework you're using) didn't explicitly isolate the
execution context, assume it's not isolated".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia