On Mon, 7 Dec 2020 11:29:55 -0800
Brett Cannon wrote:
> After much deliberation, the 2020 SC will be making a recommendation to the
> 2021 SC to accept PEP 634 (although this was not a unanimous decision).
> This is in no way a binding recommendation to the 2021 SC (even if a
> majority of current
As a candidate for the new SC, if elected I would certainly find it more
useful to have more specific thoughts from the outgoing SC than simply "we
recommend." How divided was the vote? Who took the sides? What were the
major points of disagreement? That sort of thing.
On Tue, Dec 8, 2020 at 9:39
On Tue, 8 Dec 2020 at 15:19, David Mertz wrote:
>
> As a candidate for the new SC, if elected I would certainly find it more
> useful to have more specific thoughts from the outgoing SC than simply "we
> recommend." How divided was the vote? Who took the sides? What were the major
> points of d
On Tue, Dec 8, 2020 at 7:32 AM Paul Moore wrote:
> On Tue, 8 Dec 2020 at 15:19, David Mertz wrote:
> >
> > As a candidate for the new SC, if elected I would certainly find it more
> useful to have more specific thoughts from the outgoing SC than simply "we
> recommend." How divided was the vote?
Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
macOS.
Without the changes from https://github.com/python/cpython/pull/22855
backported, attempting to build a portable binary on macOS 11 (e.g. by
setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
'XXX
It appears that when from future import __annotations__, a type hint
annotation derived from a closure loses scope.
Simplistic example:
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def make_a_class(
Yeah, static type checkers won't like it regardless.
On Tue, Dec 8, 2020 at 6:39 PM Paul Bryan wrote:
> It appears that when from future import __annotations__, a type hint
> annotation derived from a closure loses scope.
>
> Simplistic example:
>
> Python 3.9.0 (default, Oct 7 2020, 23:09:01)
Let's try an example that static type checkers should have no problem
with:
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>>
>>> def make_a_class():
... class
What is the utility of a type annotation when the thing it refers to cannot
exist?
Deferred annotation lookups are intended to be something that analysis time
can make sense of but can always have no useful meaning at runtime.
No nesting required:
```
from __future__ import annotations
Class X:
Yep, your example, *boom*.
My use case is to for type annotations to resolve type encoders,
decoders and validators at runtime.
Without __future__, type annotations specified in closure scope are
correctly attached to class variables, function parameters and return
types. Because they're in scope
On Tue, Dec 8, 2020 at 8:58 PM Paul Bryan wrote:
> My use case is to for type annotations to resolve type encoders, decoders
> and validators at runtime.
>
What is the reason you can't insist that the annotations be globals or at
least accessible from there (e.g. class attributes)? If the reason
Rereading PEP 563, I'm clearly railing against it. I believe I can work
with __annotations__ as you suggest assuming the contract going forward
is for get_type_hints to return annotations verbatim if they're not
strings or ForwardRefs (the current implementation).
Thank you and Gregory for your ti
Great. If you’d like to add something to the docs for get_type_hints()
about this behavior please submit a PR — I don’t see a reason this would
suddenly change but it’s better to make sure.
On Tue, Dec 8, 2020 at 22:29 Paul Bryan wrote:
> Rereading PEP 563, I'm clearly railing against it. I beli
13 matches
Mail list logo
