Hello!
> This would affect code that expects annotations to always be strings, but such
> code would have to be poking directly at function objects (the
> __annotations__ attribute), instead of using the advertised ways of getting
> at annotations (like typing.get_type_hints()).
I would speculate that this is somewhat common to find. What I don't think is
common
enough to consider is code that directly relies on the annotations being
strings. The
majority of code will be trying to retrieve the actual underlying types.
The potential one script out there in the solarsystem that relies on this can
just wrap the
result in str(...) to ensure it's in-fact a string.
> Keeping the future import and stringified annotations around is certainly
> an option, but we’re worried about the cost of the implementation, the
> support cost, and the confusion for users (specifically, it is a future
> import that will never become the future). If we do keep them, how long
> would we keep them around? Should we warn about their use? If we warn about
> the future import, is the noise and confusion this generates going to be
> worth it? If we don't warn about them, how will we ever be able to turn
> them off?
I quite particularly like what Łukasz Langa brought up under the header "A
better possible future"
in their blog post here:
https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/
(which has been listed in another reply here).
I will quote part of the paragraph below (read 2021-10-22; last updated
2021-10-21):
> if the library author is fine with DeprecationWarnings, they could keep using
> `from __future__ import annotations` until Python 3.13 is released (October
> 2023). [...].
> So I would advise marking the old future-import as “pending deprecation”
> until 3.13
> and only fully deprecate it then for two releases, so it would
> be removed in Python 3.14 (𝛑) in October 2025 when Python 3.9 goes EOL.
This seems like the sense of direction in terms of a compromise that I would
like to see.
> One idea is to rely on linters and IDEs to provide this signal, possibly
> with a clear upgrade path for the code (e.g. a 2to3-like fixer for a
> specific deprecation).
> [...]
> This sounds like a reasonably user-friendly approach, but it would require
> buy-in from linter/IDE developers, or an officially supported “Python
> linter” project that we control.
I think this is a nice step in the right direction as you mention test
frameworks
have had this role so I don't see the issue in also extending this to static
analysis
tools (static type checkers, linters and IDEs). Couldn't the "Python linter"
simply
be the current behaviour when you opt-into it?
> Is it safe to assume very little code would be poking directly at
> __annotations__ attributes of function objects; effectively, to declare them
> implementation details and let them not be strings even in code that
> currently has the annotations future import?
I believe so, see my comments further up in this reply. It was never safe to
assume
that all annotations were strings (in my opinion on writing good code) and so
yes
I believe this would be a non-breaking change and could be considered an
implementation detail.
> Is the performance of PEP 649 and PEP 563 similar enough that we can
> outright discount it as a concern? Does anyone actually care about the
> overhead of type annotations anymore? Are there other options to alleviate
> this potential issue (like a process-wide switch to turn off annotations)?
In my opinion this shouldn't warrant any concern as these costs are only
on startup of Python. The difference is not enough for me to care at least.
> If we do not need to keep PEP 563 support, which would be a lot easier
> on code maintenance and our support matrix, do we need to warn about the
> semantics change? Can we silently accept (and ignore) the future import
> once PEP 649 is in effect?
In terms of semver I don't think this causes a breaking change that warrants
a major bump. That said this change should be made aware to the broader
Python community so that it reaches those who are affected by this change.
Have a good weekend
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/K77G435H7QQZ4YZOVXYBMWZLSQKGO3U3/
Code of Conduct: http://python.org/psf/codeofconduct/
