4 ms·

> I know people don't like the specific decisions python has made recently (me too!), but the process for deprecation and implementation once those decisions ar

> I know people don't like the specific decisions python has made recently (me too!), but the process for deprecation and implementation once those decisions are made is at least clear and unambiguous, thanks to backwards compatibility policy adopted in PEP 387, i.e. way back in 2009. > "Wait for the warning to appear in at least two major Python versions. It's fine to wait more than two releases." > PEP 563, the one that apparently breaks pydantic, was accepted during Python 3.7. [..] It was eligible for full implementation in 3.9 according to the backward compatibility policy Can you point me to the warning that was raised in Python 3.7, 3.8, and 3.9? I don't find it on a quick look.

williamsmj 6y ago
If you're looking for runtime warnings, me neither. I think the definition of "appear in" is vague. My understanding (not a python core dev, or even someone who follows PEPs closely) is that a PEP has a corresponding python version, but it does not necessarily result in changes to cpython (or other implementations) that issue runtime warnings.
- jhayward 6y ago
  Ah, we disagree on that reading of PEP 387 then. I read it to say the API or behavior being altered must have a deprecation warning for two major releases.
  - williamsmj 6y ago
    No. I agree with your reading, but the reality is that the PSF doesn't appear to interpret it that way and it's sufficiently vague to allow them to get away with that :( I can't remember the last time (if ever) I saw a runtime deprecation warning from cpython itself (I see plenty from libraries). I don't understand PEP 563 (or the python type system and ecosystem of tooling) well enough to know whether it would even be possible for cpython itself to issue a deprecation warning in this case. In any case, it's clear that the pydantic and fastapi authors were aware of this issue.
    - williamsmj 6y ago
      Like I say, it's clear the pydantic and fastapi authors were aware of this issue, but for what it's worth I confirmed that no runtime warnings were issued for PEP 563. The behavior has been available via `from __future__ import annotations` since Python 3.7. It was the very first change mentioned in the 3.7 release notes (alongside an explicit statement that it would become default four years later in 3.10): https://github.com/python/cpython/blob/a41782cc84bcd813209a03e6e11c60e77dbc7718/Doc/whatsnew/3.7.rst#pep-563-postponed-evaluation-of-annotations https://github.com/python/cpython/blob/a41782cc84bcd813209a0...
dragonwriter 6y ago
> Can you point me to the warning that was raised in Python 3.7, 3.8, and 3.9? AIUI, No warning was raised because the PEP 484 functionality that was changed was at the time identified as provisional, and not subject to the deprecation policy, which excludes provisional features. The lack of warning, but not rationale, is explicitly noted in PEP 563.

williamsmj 6y ago

If you're looking for runtime warnings, me neither. I think the definition of "appear in" is vague. My understanding (not a python core dev, or even someone who follows PEPs closely) is that a PEP has a corresponding python version, but it does not necessarily result in changes to cpython (or other implementations) that issue runtime warnings.

jhayward 6y ago
Ah, we disagree on that reading of PEP 387 then. I read it to say the API or behavior being altered must have a deprecation warning for two major releases.
- williamsmj 6y ago
  No. I agree with your reading, but the reality is that the PSF doesn't appear to interpret it that way and it's sufficiently vague to allow them to get away with that :( I can't remember the last time (if ever) I saw a runtime deprecation warning from cpython itself (I see plenty from libraries). I don't understand PEP 563 (or the python type system and ecosystem of tooling) well enough to know whether it would even be possible for cpython itself to issue a deprecation warning in this case. In any case, it's clear that the pydantic and fastapi authors were aware of this issue.
  - williamsmj 6y ago
    Like I say, it's clear the pydantic and fastapi authors were aware of this issue, but for what it's worth I confirmed that no runtime warnings were issued for PEP 563. The behavior has been available via `from __future__ import annotations` since Python 3.7. It was the very first change mentioned in the 3.7 release notes (alongside an explicit statement that it would become default four years later in 3.10): https://github.com/python/cpython/blob/a41782cc84bcd813209a03e6e11c60e77dbc7718/Doc/whatsnew/3.7.rst#pep-563-postponed-evaluation-of-annotations https://github.com/python/cpython/blob/a41782cc84bcd813209a0...

dragonwriter 6y ago

> Can you point me to the warning that was raised in Python 3.7, 3.8, and 3.9? AIUI, No warning was raised because the PEP 484 functionality that was changed was at the time identified as provisional, and not subject to the deprecation policy, which excludes provisional features. The lack of warning, but not rationale, is explicitly noted in PEP 563.