[python-committers] Re: PEP 563 and Python 3.10.

[Terry Reedy]

On 4/20/2021 2:57 PM, Thomas Wouters wrote:

We 
need to roll back the change that made stringified annotations the 
default, at least for 3.10. (Pablo is already working on this.)


I also agree and thank Pablo in advance.

.

  - PEP 563 provides no warning to users of the feature it’s disabling.


Removals or major changes to callables usually get deprecation warnings. 
 These are relatively easy to add by adding code to the object, to be 
triggered at runtime.  I believe something similar can be done with 
modules, triggered on import, but I have never been involved with such.


Warning about other behavior changes may be needed just as much, but are 
likely to be harder.  I think removing the ability to get object 
annotations is such a case.  It was and needed and likely will be for 
3.10, depending on what we decide for 3.11.  But the need for a warning 
would have been and likely will be dependent on the presence of a 
__future__ import.  So the compiler will have to be involved somehow.


The addition of with statements, for instance, was quite different and 
on balance did not need a deprecation statement.  The breaking behavior 
change was removing 'with' as a candidate for name binding.  Detecting 
such bindings would have been relatively expensive, while the 
consequence of being caught unaware was having to change a name later 
rather than sooner, but not losing the underlying code behavior.


The nearest parallel I can think of to this syntax-related type change 
is the switch for string exceptions to exception subclass exceptions.  I 
believe that at the end, raise 'somestring' got a deprecation notice. 
This difference is the the change was in the syntax input, where as the 
annotation change is in the somewhat hidden syntax output.


We need to continue discussing the issue and potential solutions, since 


this merely postpones the problem until 3.11. (For the record, 
postponing the change further is not off the table, either, for example 


if the final decision is to treat evaluated annotations as a deprecated 



feature, with warnings on use.)


Yes, discussion should continue now both while the issue is 'hot' and 
because adding an appropriate deprecation warning in 3.10.0 requires a 
decision before it becomes final.


For what it’s worth, the SC is also considering what we can do to reduce 
the odds of something like this happening again, but that’s a separate 
consideration, and a multi-faceted one at that.


Broadly speaking, statements are functions and their output, as well as 
input, should be subject to our normal deprecation and suggested 
replacement policy.


--
Terry Jan Reedy

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LRO2L7HI7S5U7G32RBZXDBOJVIHV7MP3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 563 and Python 3.10.

[Larry Hastings]

I commend the Steering Council for its wise decision.  I'm sure that 
once the Python community spends more time considering this issue, and 
innovating new solutions, we can come up with a path forward that'll be 
good news for everybody.


Best wishes,


//arry/

On 4/20/21 11:57 AM, Thomas Wouters wrote:


(Starting a new thread so as not to derail any of the ongoing 
discussions.)


Thanks, everyone, for your thoughts on Python 3.10 and the impact of 
PEP 563 (postponed evaluation of annotations) becoming the default. 
The Steering Council has considered the issue carefully, along with 
many of the proposed alternatives and solutions, and we’ve decided 
that at this point, we simply can’t risk the compatibility breakage of 
PEP 563. We need to roll back the change that made stringified 
annotations the default, at least for 3.10. (Pablo is already working 
on this.)


To be clear, we are not reverting PEP 563 itself. The future import 
will keep working like it did since Python 3.7. We’re delaying making 
PEP 563 string-based annotations the default until Python 3.11. This 
will give us time to find a solution that works for everyone (or to 
find a feasible upgrade path for users who currently rely on evaluated 
annotations). Some considerations that led us to this decision:


 - PEP 563’s default change is clearly too disruptive to downstream 
users and third-party libraries to happen right now. We can’t risk 
breaking even a small subset of the FastAPI/pydantic users, not to 
mention other uses of evaluated type annotations that we’re not aware 
of yet.
 - PEP 563 provides no warning to users of the feature it’s disabling. 
Without that, we can’t expect users to be aware of the upcoming 
breakage. The lack of a warning was by design, and made sense in a 
world where type annotations were only consumed by static type 
checkers --- but that’s not actually the situation we’re in.  There 
are clearly existing real-world, run-time uses of type annotations 
that would be adversely affected by this change.
 - Originally, PEP 563 was scheduled to take effect in Python 4, and 
this changed recently (after the discussion in the Language Summit of 
2020). It's possible that third-party libraries and users didn’t plan 
to react in the current time frame as they were not aware of this 
change in timing.
 - There isn’t enough time to properly discuss PEP 649 or any of the 
alternatives before the beta 1 deadline, and we really need to make 
sure we don’t compound errors here.  We need to look for a long term 
solution, which isn’t possible while still maintaining the release 
deadlines of Python 3.10.  That means we’re also deferring PEP 649 to 
Python 3.11.


In the Steering Council’s unanimous opinion, rolling back the default 
flip for stringified annotations in Python 3.10 is the least 
disruptive of all the options.


We need to continue discussing the issue and potential solutions, 
since this merely postpones the problem until 3.11. (For the record, 
postponing the change further is not off the table, either, for 
example if the final decision is to treat evaluated annotations as a 
deprecated feature, with warnings on use.)


For what it’s worth, the SC is also considering what we can do to 
reduce the odds of something like this happening again, but that’s a 
separate consideration, and a multi-faceted one at that.


For the Steering Council,
Thomas.
--
Thomas Wouters mailto:tho...@python.org>>

Hi! I'm an email virus! Think twice before sending your email to help 
me spread!


___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/



___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/UVEIVD5BBIQPBBOF6QYJ4CT6C4J5OYL3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 563 and Python 3.10.

[Guido van Rossum]

Thanks to the Steering Council! You have the wisdom of Solomon. Rolling
back the code that made PEP 563 the default behavior is the only sensible
solution for 3.10.

On Tue, Apr 20, 2021 at 11:58 AM Thomas Wouters  wrote:

>
> (Starting a new thread so as not to derail any of the ongoing discussions.)
>
> Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP
> 563 (postponed evaluation of annotations) becoming the default. The
> Steering Council has considered the issue carefully, along with many of the
> proposed alternatives and solutions, and we’ve decided that at this point,
> we simply can’t risk the compatibility breakage of PEP 563. We need to roll
> back the change that made stringified annotations the default, at least for
> 3.10. (Pablo is already working on this.)
>
> To be clear, we are not reverting PEP 563 itself. The future import will
> keep working like it did since Python 3.7. We’re delaying making PEP 563
> string-based annotations the default until Python 3.11. This will give us
> time to find a solution that works for everyone (or to find a feasible
> upgrade path for users who currently rely on evaluated annotations). Some
> considerations that led us to this decision:
>
>  - PEP 563’s default change is clearly too disruptive to downstream users
> and third-party libraries to happen right now. We can’t risk breaking even
> a small subset of the FastAPI/pydantic users, not to mention other uses of
> evaluated type annotations that we’re not aware of yet.
>  - PEP 563 provides no warning to users of the feature it’s disabling.
> Without that, we can’t expect users to be aware of the upcoming breakage.
> The lack of a warning was by design, and made sense in a world where type
> annotations were only consumed by static type checkers --- but that’s not
> actually the situation we’re in.  There are clearly existing real-world,
> run-time uses of type annotations that would be adversely affected by this
> change.
>  - Originally, PEP 563 was scheduled to take effect in Python 4, and this
> changed recently (after the discussion in the Language Summit of 2020).
> It's possible that third-party libraries and users didn’t plan to react in
> the current time frame as they were not aware of this change in timing.
>  - There isn’t enough time to properly discuss PEP 649 or any of the
> alternatives before the beta 1 deadline, and we really need to make sure we
> don’t compound errors here.  We need to look for a long term solution,
> which isn’t possible while still maintaining the release deadlines of
> Python 3.10.  That means we’re also deferring PEP 649 to Python 3.11.
>
> In the Steering Council’s unanimous opinion, rolling back the default flip
> for stringified annotations in Python 3.10 is the least disruptive of all
> the options.
>
> We need to continue discussing the issue and potential solutions, since
> this merely postpones the problem until 3.11. (For the record, postponing
> the change further is not off the table, either, for example if the final
> decision is to treat evaluated annotations as a deprecated feature, with
> warnings on use.)
>
> For what it’s worth, the SC is also considering what we can do to reduce
> the odds of something like this happening again, but that’s a separate
> consideration, and a multi-faceted one at that.
>
> For the Steering Council,
> Thomas.
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/4BFSYEKU3P7FNRKVDD7RZXTNEEA6PRXU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 563 and Python 3.10.

[Thomas Wouters]

(Starting a new thread so as not to derail any of the ongoing discussions.)

Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP
563 (postponed evaluation of annotations) becoming the default. The
Steering Council has considered the issue carefully, along with many of the
proposed alternatives and solutions, and we’ve decided that at this point,
we simply can’t risk the compatibility breakage of PEP 563. We need to roll
back the change that made stringified annotations the default, at least for
3.10. (Pablo is already working on this.)

To be clear, we are not reverting PEP 563 itself. The future import will
keep working like it did since Python 3.7. We’re delaying making PEP 563
string-based annotations the default until Python 3.11. This will give us
time to find a solution that works for everyone (or to find a feasible
upgrade path for users who currently rely on evaluated annotations). Some
considerations that led us to this decision:

 - PEP 563’s default change is clearly too disruptive to downstream users
and third-party libraries to happen right now. We can’t risk breaking even
a small subset of the FastAPI/pydantic users, not to mention other uses of
evaluated type annotations that we’re not aware of yet.
 - PEP 563 provides no warning to users of the feature it’s disabling.
Without that, we can’t expect users to be aware of the upcoming breakage.
The lack of a warning was by design, and made sense in a world where type
annotations were only consumed by static type checkers --- but that’s not
actually the situation we’re in.  There are clearly existing real-world,
run-time uses of type annotations that would be adversely affected by this
change.
 - Originally, PEP 563 was scheduled to take effect in Python 4, and this
changed recently (after the discussion in the Language Summit of 2020).
It's possible that third-party libraries and users didn’t plan to react in
the current time frame as they were not aware of this change in timing.
 - There isn’t enough time to properly discuss PEP 649 or any of the
alternatives before the beta 1 deadline, and we really need to make sure we
don’t compound errors here.  We need to look for a long term solution,
which isn’t possible while still maintaining the release deadlines of
Python 3.10.  That means we’re also deferring PEP 649 to Python 3.11.

In the Steering Council’s unanimous opinion, rolling back the default flip
for stringified annotations in Python 3.10 is the least disruptive of all
the options.

We need to continue discussing the issue and potential solutions, since
this merely postpones the problem until 3.11. (For the record, postponing
the change further is not off the table, either, for example if the final
decision is to treat evaluated annotations as a deprecated feature, with
warnings on use.)

For what it’s worth, the SC is also considering what we can do to reduce
the odds of something like this happening again, but that’s a separate
consideration, and a multi-faceted one at that.

For the Steering Council,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/