Should this be considered a bug in the Enum implementation?
>>> class Foo(enum.Enum):
... A = True
... B = 1
... C = 0
... D = False
...
>>> Foo.A
>>> Foo(True)
>>> Foo(1)
Seems to me like it should store and compare both type and value.
Paul
_
I've now experienced an issue I believe that PEP 533 was intended to
address:
When an asynchronous context manager is created within an asynchronous
generator, if the generator is not iterated fully, the context manager
will not exit until the event loop cancels the task by raising a
CancelledErro
My code pretty much does what you suggest at the end of your message:
On Mon, 2021-01-11 at 09:22 -0800, Larry Hastings wrote:
> Or code can just use inspect.get_type_hints(), which is tied to the
> Python version
> anyway and should always do the right thing.
So far, this has proven mostly[1] su
I'm very much in favour of the this concept. A few points come to mind
right away:
1. Backwards Compatibility
> PEP 563 changed the semantics of annotations. When its semantics are
> active, annotations must assume they will be evaluated inmodule-level
> scope. They may no longer refer directly
On Mon, 2021-01-11 at 13:16 -0800, Larry Hastings wrote:
>
> Thanks for your feedback! I'll reply piecemeal.
>
> On 1/11/21 12:32 PM, Paul Bryan wrote:
>
> > 1. Backwards Compatibility
> >
> >
> > > PEP 563 changed the semantics of annotations. When its semantics
> > > are active, annotations
Some more questions...
"Binding"," bound" and "unbound" code objects:
Is your use of "binding" terminology in the PEP identical to the
binding of a function to an object instance as a method during object
creation?
Function Annotations:
> When binding an unbound annotation code object, a function
On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote:
> On 1/11/21 5:02 PM, Paul Bryan wrote:
>
> >
> > Some more questions...
> >
> > "Binding"," bound" and "unbound" code objects:
> > Is your use of "binding" terminology in the PEP identical to the
> > binding of a function to an object in
Will do.
On Mon, 2021-01-11 at 20:55 -0800, Guido van Rossum wrote:
> On Mon, Jan 11, 2021 at 3:51 PM Larry Hastings
> wrote:
> > [...]
> > > This passage in PEP 563 appears not true in Python 3.9 with
> > > __future__ annotations, emphasis mine:
> > >
> > > > The get_type_hints() function autom
On Tue, 2021-01-12 at 09:54 -0800, Larry Hastings wrote:
> Note that this only works in the current version of the PEP /
> prototype, where annotations are strictly evaluated in module scope.
> If we start supporting closures, those need "cell" objects, which
> IIUC can't be marshalled.
Since the
On Tue, 2021-01-12 at 20:09 -0800, Guido van Rossum wrote:
> On Tue, Jan 12, 2021 at 8:00 PM Brett Cannon
> wrote:
> >
> > > * It turns a None annotation into type(None). Which means now
> > > you
> > > can't tell the difference between "None" and "type(None)".
> > >
> > Huh, I wasn't aware of
OK. Makes sense to think of __annotations__ as being the location of
the final, stable, "affixed" type hints.
I wonder if then the __co_annotations__ call and overwriting of
__annotations__ should be explicitly caused by a to get_type_hints
instead of (mysteriously) occurring on an attempt to geta
I knew I was missing something. Agree, annotations are not necessarily
type hints.
On Fri, 2021-01-15 at 10:56 -0800, Larry Hastings wrote:
>
> On 1/15/21 10:12 AM, Paul Bryan wrote:
>
> > I wonder if then the __co_annotations__ call and overwriting of
> > __annotations__ should be explicitly ca
Would annotations() just access the dunder, like other builtins (and
then result in the descriptor resolving __co_annotations__ as
proposed), or would calling it be required to actually resolve
__co_annotations__? I think it should probably be the former.
On Sat, 2021-01-16 at 12:29 +1300, Greg Ew
13 matches
Mail list logo
