[Python-Dev] TypedDict behavior

[Paul Bryan]

Is this the expected behavior?

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.
>>> import typing
>>> TD = typing.TypedDict("TD", {"a": str}, total=False)
>>> TD.__total__
False
>>> TD.__required_keys__
frozenset({'a'})
>>> TD.__optional_keys__
frozenset()
>>> 

It seems to me "a" should not be a required key, but in fact an
optional key.

___
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/6NEXFZIEFGKACLP6BUTJVWJ4ARXUHMKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] __future__ annotations loses closure scope

[Paul Bryan]

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(data_type):
... class Foo:
... def put_data(self, data: data_type):
... self.data = data
... return Foo
... 
>>> import typing
>>> foo = make_a_class(str)()
>>> typing.get_type_hints(foo.put_data)
{'data': }
>>> 

If I add a single import to the top, it breaks:

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  # added this line
>>> def make_a_class(data_type):
... class Foo:
... def put_data(self, data: data_type):
... self.data = data
... return Foo
... 
>>> import typing
>>> foo = make_a_class(str)()
>>> typing.get_type_hints(foo.put_data)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/typing.py", line 1386, in get_type_hints
value = _eval_type(value, globalns, localns)
  File "/usr/lib/python3.9/typing.py", line 254, in _eval_type
return t._evaluate(globalns, localns, recursive_guard)
  File "/usr/lib/python3.9/typing.py", line 493, in _evaluate
eval(self.__forward_code__, globalns, localns),
  File "", line 1, in 
NameError: name 'data_type' is not defined
>>> 

I don't see how I can supply the closure scope as localns to
get_type_hints. Any suggestions? Is constructing a (dynamically-type-
annotated) class in a function like this an anti-pattern?

___
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/5RK6VXF263F5I4CU7FUMOGOYN2UQG73Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: __future__ annotations loses closure scope

[Paul Bryan]

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 A:
... def get_b(self) -> B:
... return B()
... class B:
... def get_a(self) -> A:
... return A()
... return A
... 
>>> A = make_a_class()
>>> a = A()
>>> 
>>> import typing
>>> typing.get_type_hints(a.get_b)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/typing.py", line 1386, in get_type_hints
value = _eval_type(value, globalns, localns)
  File "/usr/lib/python3.9/typing.py", line 254, in _eval_type
return t._evaluate(globalns, localns, recursive_guard)
  File "/usr/lib/python3.9/typing.py", line 493, in _evaluate
eval(self.__forward_code__, globalns, localns),
  File "", line 1, in 
NameError: name 'B' is not defined
>>> 



On Tue, 2020-12-08 at 18:48 -0800, Guido van Rossum wrote:
> 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) 
> > [GCC 10.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more
> > information.
> > >>> def make_a_class(data_type):
> > ... class Foo:
> > ... def put_data(self, data: data_type):
> > ... self.data = data
> > ... return Foo
> > ... 
> > >>> import typing
> > >>> foo = make_a_class(str)()
> > >>> typing.get_type_hints(foo.put_data)
> > {'data': }
> > >>> 
> > 
> > 
> > If I add a single import to the top, it breaks:
> > 
> > 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 # added this line
> > >>> def make_a_class(data_type):
> > ... class Foo:
> > ... def put_data(self, data: data_type):
> > ... self.data = data
> > ... return Foo
> > ... 
> > >>> import typing
> > >>> foo = make_a_class(str)()
> > >>> typing.get_type_hints(foo.put_data)
> > Traceback (most recent call last):
> > File "", line 1, in 
> > File "/usr/lib/python3.9/typing.py", line 1386, in get_type_hints
> > value = _eval_type(value, globalns, localns)
> > File "/usr/lib/python3.9/typing.py", line 254, in _eval_type
> > return t._evaluate(globalns, localns, recursive_guard)
> > File "/usr/lib/python3.9/typing.py", line 493, in _evaluate
> > eval(self.__forward_code__, globalns, localns),
> > File "", line 1, in 
> > NameError: name 'data_type' is not defined
> > >>> 
> > 
> > 
> > I don't see how I can supply the closure scope as localns to
> > get_type_hints. Any suggestions? Is constructing a (dynamically-
> > type-annotated) class in a function like this an anti-pattern?
> > 
> > ___
> > 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/5RK6VXF263F5I4CU7FUMOGOYN2UQG73Q/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> ___
> 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/NRH4HBD36WDIP4WR2L4TLTOYMQL2NUFV/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/6P5GFROAVAYXU3DTELZRHHRCDRYUEWCG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: __future__ annotations loses closure scope

[Paul Bryan]

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 at the time they're evaluated.

__future__ annotations breaks because the hint is not evaluated until
get_type_hints is called, which is too late; the scope is lost.

Instead of just storing an annotation as a string, how about storing an
object containing the string, plus the local scope? Then get_type_hint
could be made to successfully resolve it.


On Tue, 2020-12-08 at 20:44 -0800, Gregory P. Smith wrote:
> 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:
>   ...
> 
> def foo(hi: X):
>   ...
> 
> del X
> ```
> 
> Now try analyzing foo at runtime...  I assume "Boom" with that
> NameError again?  (On a phone, can't try it now)
> 
> I believe this isn't a problem get_type_hints() can ever solve.
> 
> Code that does this isn't what I'd call "reasonably" structured for
> use with type hints. 
> 
> If anything, type checkers should try to warn about it?
> 
> -gps
> 
> On Tue, Dec 8, 2020, 7:03 PM Paul Bryan  wrote:
> > 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 A:
> > ... def get_b(self) -> B:
> > ... return B()
> > ... class B:
> > ... def get_a(self) -> A:
> > ... return A()
> > ... return A
> > ... 
> > >>> A = make_a_class()
> > >>> a = A()
> > >>> 
> > >>> import typing
> > >>> typing.get_type_hints(a.get_b)
> > Traceback (most recent call last):
> > File "", line 1, in 
> > File "/usr/lib/python3.9/typing.py", line 1386, in get_type_hints
> > value = _eval_type(value, globalns, localns)
> > File "/usr/lib/python3.9/typing.py", line 254, in _eval_type
> > return t._evaluate(globalns, localns, recursive_guard)
> > File "/usr/lib/python3.9/typing.py", line 493, in _evaluate
> > eval(self.__forward_code__, globalns, localns),
> > File "", line 1, in 
> > NameError: name 'B' is not defined
> > >>> 
> > 
> > 
> > 
> > 
> > On Tue, 2020-12-08 at 18:48 -0800, Guido van Rossum wrote:
> > > 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) 
> > > > [GCC 10.2.0] on linux
> > > > Type "help", "copyright", "credits" or "license" for more
> > > > information.
> > > > >>> def make_a_class(data_type):
> > > > ... class Foo:
> > > > ... def put_data(self, data: data_type):
> > > > ... self.data = data
> > > > ... return Foo
> > > > ... 
> > > > >>> import typing
> > > > >>> foo = make_a_class(str)()
> > > > >>> typing.get_type_hints(foo.put_data)
> > > > {'data': }
> > > > >>> 
> > > > 
> > > > 
> > > > If I add a single import to the top, it breaks:
> > > > 
> > > > 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 # added this line
> > > > >>> def make_a_class(data_type):
> > > > ... class Foo:

[Python-Dev] Re: __future__ annotations loses closure scope

[Paul Bryan]

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 time.


On Tue, 2020-12-08 at 21:49 -0800, Guido van Rossum wrote:
> 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 is that they're dynamically computed, maybe you can
> dynamically compute the annotation (effectively overruling the
> "future" semantics)? `__annotations__` is a mutable attribute so
> there's nothing to stop you from writing e.g.
> 
> def make_foo(symbol):
>     def foo(arg: symbol): ...
>     foo.__annotations__['arg'] = symbol  # Or you could do e.g. this
> in a decorator
>     return foo
>  
> > Without __future__, type annotations specified in closure scope are
> > correctly attached to class variables, function parameters and
> > return types. Because they're in scope at the time they're
> > evaluated.
> > 
> > __future__ annotations breaks because the hint is not evaluated
> > until get_type_hints is called, which is too late; the scope is
> > lost.
> > 
> > Instead of just storing an annotation as a string, how about
> > storing an object containing the string, plus the local scope? Then
> > get_type_hint could be made to successfully resolve it.
> > 
> 
> 
> That would be a problem because it would keep everything in the local
> scope alive forever (since perhaps the annotation is never used).
> 
> There may be a reason why my suggestion won't work either. If that's
> so, please show a realistic example that captures the essence of your
> problem, so we won't keep going back and forth attacking each other's
> toy examples.
> 
> Also please understand that this behavior is prescribed by an
> accepted PEP and has been around since 3.7, so the bar to change this
> is very high. (It's not the default behavior until 3.10 though, so
> theoretically there might be a little bit more wiggle room for that.
> So far you haven't shown sufficient evidence to consider that
> though.)
> 
> ___
> 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/DMHM5BTBITZK26NJ2SZOOCYYK7AFWXFC/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/KXMVS4EE4JHW6GPMECNN3Q4ZKJJCNQEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Runtime vs. Static Typing

[Paul Bryan]

Per PEP 563:

> Most importantly, Guido van Rossum explicitly stated interest in
> gradually restricting the use of annotations to static typing (with
> an optional runtime component).

As I'm working on runtime type encoding and validation using type
annotations, this passage raises a bit of a concern, as I don't know
what is meant by optional runtime component.

Looking for any discussion on this. I checked:

https://bugs.python.org/issue38605
https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed

Can't find any references to runtime. Can someone point me to (or
briefly explain) the thinking on this?

Thanks,

Paul

___
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/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Runtime vs. Static Typing

[Paul Bryan]

Thanks. Concern allayed. 🙂

On Thu, 2020-12-10 at 21:55 -0800, Guido van Rossum wrote:
> Hi Paul,
> 
> The runtime component is the API provided by the `typing` module such
> as `get_type_hints()`, plus the `__annotations__` attribute on
> various objects (classes and functions, mostly).
> 
> I am not aware of any plans or proposals to remove `__annotations__`
> or `typing.get_type_hints()`, and obviously use cases like yours
> abound.
> 
> That said, the needs of static checking (e.g. mypy) and runtime
> checking (e.g. JSON schema checkers) sometimes diverge, and in those
> cases I tend to favor the needs of static checkers.
> 
> PEP 563 is an example: we found that developers were having a hard
> time with the original requirement that all annotations are evaluated
> as expressions at the time the function definition is executed, since
> it makes forward references difficult (requiring the hack of
> enclosing the annotation in string quotes).
> 
> At the same time we found that static type checks are much more used
> than runtime type checks -- presumably for performance reasons. So
> PEP 563 was born -- annotations containing forward references no
> longer need to be quoted, making the use of static checkers simpler,
> while still catering to the needs of runtime checkers via
> typing.get_type_hints(). (Note that the latter was already needed to
> deal with explicitly quoted forward references pre-PEP-563.)
> 
> It is not inconceivable that eventually type system features will be
> introduced that are hard to check at runtime, and in such cases we
> will not let that stop us from defining the new type system feature.
> (I already doubt that there are runtime checkers that check the
> consistent use of type variables at runtime.)
> 
> That said, I don't see a reason to start deprecating the runtime
> introspection features of the existing annotation syntax, and if you
> look at PEP 585 (`list[int]` etc.) or PEP 604 (`int | str` union
> notation) you'll see that they are completely runtime introspectable.
> (Believe me, it would have been much simpler to erase type parameters
> completely at runtime, but I personally wrote most of the
> implementation to make them available via attributes on the
> `types.GenericAlias` type.)
> 
> Hope this helps,
> 
> --Guido
> 
> On Thu, Dec 10, 2020 at 7:17 PM Paul Bryan  wrote:
> > Per PEP 563:
> > 
> > > Most importantly, Guido van Rossum explicitly stated interest in
> > > gradually restricting the use of annotations to static typing
> > > (with an optional runtime component).
> > 
> > 
> > As I'm working on runtime type encoding and validation using type
> > annotations, this passage raises a bit of a concern, as I don't
> > know what is meant by optional runtime component.
> > 
> > Looking for any discussion on this. I checked:
> > 
> > https://bugs.python.org/issue38605
> >
> https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed
> > 
> > Can't find any references to runtime. Can someone point me to (or
> > briefly explain) the thinking on this?
> > 
> > Thanks,
> > 
> > Paul
> > 
> > ___
> > 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/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 

___
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/NJUTIIV4XHGOJCMKDWW4NGDHKVZ7DQGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Paul Bryan]

I like.

On Wed, 2021-02-03 at 15:48 -0800, Guido van Rossum wrote:
> Anyone? I'm +1 on this PEP as it is, and I imagine a few other core
> devs are too (Brandt, Steven). If nobody responds before the end of
> the week I think we can say that there was no disagreement and
> Stefano can submit PEP 637 to the SC.
> 
> On Tue, Feb 2, 2021 at 3:43 AM Stefano Borini
>  wrote:
> > Hi all,
> > 
> > I would like to request feedback by python-dev on the current
> > implementation of PEP 637 - Support for indexing with keyword
> > arguments.
> > 
> > https://www.python.org/dev/peps/pep-0637/
> > 
> > The PEP is ready for SC submission and it has a prototype
> > implementation ready, available here (note, not reviewed, but
> > apparently fully functional)
> > 
> >
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
> > 
> > (note: not sure if there's a preference for the link to be to the
> > diff
> > or to the branch, let me know if you prefer I change the PEP link)
> > 
> > Thank you for your help.
> > 
> > 
> > -- 
> > Kind regards,
> > 
> > Stefano Borini
> > ___
> > 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/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> ___
> 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/67ZLIDZPKQA2BVDNSRUQUUTPO7ZB4OIE/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/SZX43KQOKBQFVKPGRZ6ZGB26ZD4BF5B5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Bryan]

On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:

> A __future__ import would make clear to all that the feature is
> experimental, and maybe there could be __future__ imports for
> different parts of the proposal.

That's not my understanding. My understanding is __future__ is meant
for  features that potentially break existing code, and allows code to
opt-in in a release earlier than when it will behave that way by
default. From what I can tell with this PEP, existing code can continue
working the way it always has.

Paul

___
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/XYES63LQIVXZAX53B6MWT6UCIPLS2JGY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Bryan]

On Sat, 2021-02-06 at 22:05 -0300, Luciano Ramalho wrote:

> The initial pattern matching syntax and semantics with its many
> corner
> cases may be incompatible with a future way of doing pattern matching
> that is better.

Then that future incompatible way should be marked with __future__, not
this PEP implementation.

Paul

___
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/DNDPEXQXLHGXX4ZCUIZIDHEKCWIFY6LY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dusting off PEP 533?

[Paul Bryan]

For what it's worth, I've increasingly considered creating a context in
a generator (sync or async) to be an antipattern. To this end, in my
case, I moved creation of the context outside of the generator. This
resulted in a more explicit contract, which actually simplified
reasoning about its behavior. 

On Sun, 2021-02-07 at 16:18 -0800, Richard Levasseur wrote:
> I, too, think I ran into basically the same situation as Paul: An
> outer async generator calls an inner async generator. The outer
> doesn't fully consume the inner. The inner uses an async context
> manager. The inner CM isn't exited when expected and resources aren't
> released when required/expected.
> 
> FWIW, the analysis of PEP 533 seems spot on -- for synchronous code,
> while still possible, it's harder to trigger thanks to the GC tricks.
> For asynchronous code, it easily (and subtly) results in resources
> not being released when expected. Or perhaps never at all? IIUC, a
> long-lived server might just accumulate unfinished async generators
> indefinitely, or at least until some OS resource was exhausted.
> 
> In my particular case, I have thousands of network requests to make,
> each of which is potentially large and/or slow to complete in its
> entirety, so I'm taking extra care to break early to minimize
> resource usage to both client and servers. I spent about an entire
> day trying to figure why the synchronous version of my code Just
> Worked, while the asynchronous version simply refused to close things
> when I was done with them. It was only after I started looking at
> third party libraries and stumbled upon a reference to PEP 533 and a
> detailed blog post from 5 years ago that I had a clue what was going
> on. My point being, the feature PEP 533 describes would have made
> things Just Work in line with my expectations.
> 
> 
> On Tue, Jan 5, 2021 at 8:35 AM Stestagg  wrote:
> > For what it's worth, this recent issue:
> > https://bugs.python.org/issue42762  is somewhat related to the non-
> > async aspect of 533. (generator func getting closed during __del__
> > and causing odd side-effects at seemingly random points in the
> > execution flow)
> > 
> > The example code provided in that issue is contrived, and involves
> > catching unconditional exceptions and recursing, but following the
> > code flow in that situation feels unreasonably hard, and deciding
> > if it's a python bug or not is even harder.
> > 
> > I'm not sure how easy an implementation of 533 would be that
> > doesn't break a lot of existing code, but if one could be made, it
> > might help make generator lifecycles more predictable.
> > 
> > 
> > 
> > 
> > On Tue, Jan 5, 2021 at 1:08 PM Senthil Kumaran
> >  wrote:
> > > Hi Paul,
> > > 
> > > > Per PEP 525, I can call aclose coroutine method to cleanup the
> > > generator, but
> > > > it requires the code iterating to be aware that that closing
> > > the generator is
> > > > necessary.
> > > 
> > > How about treating this as a bug for the specific use case that
> > > you mentioned,
> > > rather than a complete addition of " PEP 533 -- Deterministic
> > > cleanup for
> > > iterators". I am not certain why PEP 533 was deffered.
> > > 
> > > I'd also suggest a documentation update if the details of aclose
> > > requirement is
> > > mentioned only in a PEP and not in the documentation.
> > > 
> > > Thank you,
> > > Senthil
> > > ___
> > > 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/EPKMYH7DH5G6YR3AQHZTQKHBQF46YXLC/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > ___
> > 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/VB64QJAYU2CCLOHRCBUIQOHMS2DIQQCC/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/D7CO5ZMIPT3R4YO3OCWGAYG5PFC5S53I/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/4FCYB63LCWI5D7AGRRDHEEXE5IIB2SAZ/

[Python-Dev] Re: Python standardization

[Paul Bryan]

>From my point of view, the process of standardizing through a formal
standards body is a tedious, verbose, laborious, bureaucratic and
often contentious process.

I'd really like to know quantitatively what the benefits would be of
running that gauntlet, as I'm not sure they would outweigh the costs.

On Fri, 2021-02-12 at 10:33 -0800, Dan Stromberg wrote:
> 
> What would it take to create an ANSI, ECMA and/or ISO standard for
> Python?
> 
> It seems to have really helped C.
> 
> It looks like Java isn't standardized, and it's done OK, though
> perhaps it was healthier in the past - before Oracle decided API's
> were ownable.
> 
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
> 
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/7PM4C6EW633HF4URYN4JTKS7KTAJEPME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Paul Bryan]

What if PSF were to undertake codifying a language specification?

On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
> 
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev
>  wrote:
> > How a standard by ANSI, ECMA and/or ISO is any better than a
> > standard by the PSF?
> > 
> 
> I don't think what the PSF is producing is truly a standard.
> > Is PSF bad at "controlling its growth and avoiding featuritis" in
> > your opinion or smth?
> > 
> 
> It's not the PSF I have an issue with. It's having a reference
> implementation.
> 
> I think the PSF has done a pretty good job of keeping in mind what
> other Python implementations can realistically do also - but doing so
> is an uphill battle.
> 
> I believe Python needs to become more independent of CPython, for
> Python's long term health.
> 
> Think of C.  Where would it be if it had K&R C as a reference
> implementation, long term?  There are dozens, maybe hundreds of
> mostly-compatible implementations of C.  I think this should be
> Python's goal.
> 
> Look where not having a standard got Perl.  It is so defined by a
> single implementation that the language is collapsing under its own
> weight.  Perl 6 is so not-perl that it was renamed.  Python is much
> less guilty of exuberant design, that's part of what I like about
> Python, but like I said, having a reference implementation instead of
> a standard makes that more difficult.
> > On 12.02.2021 21:33, Dan Stromberg wrote:
> > 
> > > 
> > > What would it take to create an ANSI, ECMA and/or ISO standard
> > > for Python?
> > > 
> > > It seems to have really helped C.
> > > 
> > > It looks like Java isn't standardized, and it's done OK, though
> > > perhaps it was healthier in the past - before Oracle decided
> > > API's were ownable.
> > > 
> > > I think standardizing Python might be really good for controlling
> > > its growth and avoiding featuritis.
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > ___
> > 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-d
> > e...@python.org/message/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> > Code of Conduct: http://python.org/psf/codeofconduct/

___
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/64TBHFOMEK7ECWSTHA6PMF7RGUH7S6TQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Paul Bryan]

I definitely think they could. As a developer using Python, they're
fully sufficient for my purposes.

I honestly don't know enough about non-CPython implementations and
their challenges to know what gaps (if any) would need to be filled to
fully implement a compatible version.


On Sat, 2021-02-13 at 10:58 +1300, Greg Ewing wrote:
> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
> 
> We have the Language Reference and Library Reference. Do they
> not count as specifications?
> 

___
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/KG3AN42M3GEJQ3O4SXSK3AZQ3BPNI42L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Paul Bryan]

I'm a +1 on using Annotated in this manner. Guido mentioned that it was
intended for only third-parties though. I'd like to know more about why
this isn't a good pattern for use by Python libraries. 

On Sun, 2021-02-14 at 16:29 +0100, Adrian Freund wrote:
> Here's another suggestion:
> 
> PEP 593 introduced the `Annotated` type annotation. This could be
> used to annotate a TypeGuard like this:
> 
> `def is_str_list(val: List[object]) -> Annotated[bool,
> TypeGuard(List[str])]`
> 
> Note that I used ( ) instead of [ ] for the TypeGuard, as it is no
> longer a type.
> 
> This should fulfill all four requirements, but is a lot more verbose
> and therefore also longer.
> It would also be extensible for other annotations.
> 
> For the most extensible approach both `-> TypeGuard(...)` and `->
> Annotated[bool, TypeGuard(...)]` could be allowed, which would open
> the path for future non-type-annotations, which could be used
> regardless of whether the code is type-annotated.
> 
> 
> --
> Adrian
> 
> On February 14, 2021 2:20:14 PM GMT+01:00, Steven D'Aprano
>  wrote:
> > On Sat, Feb 13, 2021 at 07:48:10PM -, Eric Traut wrote:
> > 
> > > I think it's a reasonable criticism that it's not obvious that a 
> > > function annotated with a return type of `TypeGuard[x]` should
> return 
> > > a bool.
> > > 
> > [...]
> > > As Guido said, it's something that a developer can easily 
> > > look up if they are confused about what it means.
> > > 
> > 
> > Yes, developers can use Bing and Google :-)
> > 
> > But it's not the fact that people have to look it up. It's the fact
> that 
> > they need to know that this return annotation is not what it seems,
> but 
> > a special magic value that needs to be looked up.
> > 
> > That's my objection: we're overloading the return annotation to be 
> > something other than the return annotation, but only for this one 
> > special value. (So far.) If you don't already know that it is
> special, 
> > you won't know that you need to look it up to learn that its
> special.
> > 
> > 
> > > I'm open to alternative formulations that meet the following
> requirements:
> > > 
> > > 1. It must be possible to express the type guard within the
> function 
> > > signature. In other words, the implementation should not need to
> be 
> > > present. This is important for compatibility with type stubs and
> to 
> > > guarantee consistent behaviors between type checkers.
> > > 
> > 
> > When you say "implementation", do you mean the body of the
> function?
> > 
> > Why is this a hard requirement? Stub files can contain function 
> > bodies, usually `...` by convention, but alternatives are often
> useful, 
> > such as docstrings, `raise NotImplementedError()` etc.
> > 
> > https://mypy.readthedocs.io/en/stable/stubs.html
> > 
> > I don't think that the need to support stub files implies that the
> type 
> > guard must be in the function signature. Have I missed something?
> > 
> > 
> > > 2. It must be possible to annotate the input parameter types
> _and_ the 
> > > resulting (narrowed) type. It's not sufficient to annotate just
> one or 
> > > the other.
> > > 
> > 
> > Naturally :-)
> > 
> > That's the whole point of a type guard, I agree that this is a
> truly 
> > hard requirement.
> > 
> > 
> > > 3. It must be possible for a type checker to determine when
> narrowing 
> > > can be applied and when it cannot. This implies the need for a
> bool 
> > > response.
> > > 
> > 
> > Do you mean a bool return type? Sorry Eric, sometimes the
> terminology 
> > you use is not familiar to me and I have to guess what you mean.
> > 
> > 
> > > 4. It should not require changes to the grammar because that
> would 
> > > prevent this from being adopted in most code bases for many
> years.
> > > 
> > 
> > Fair enough.
> > 
> > 
> > > Mark, none of your suggestions meet these requirements.
> > > 
> > 
> > Mark's suggestion to use a variable annotation in the body meets 
> > requirements 2, 3, and 4. As I state above, I don't think that 
> > requirement 1 needs to be a genuinely hard requirement: stub files
> can 
> > include function bodies.
> > 
> > To be technically precise, stub functions **must** include function
> > bodies. It's just that by convention we use typically use `...` as
> the 
> > body.
> > 
> > 
> > > Gregory, one of your suggestions meets these requirements:
> > > 
> > > ```python
> > > def is_str_list(val: Constrains[List[object]:List[str]) -> bool:
> > > ...
> > > ```
> > > 
> > 
> > That still misleadingly tells the reader (or naive code analysis 
> > software) that parameter val is of type
> > 
> > Contrains[List[object]:List[str]]
> > 
> > whatever that object is, rather than what it *actually* is, namely 
> > `List[object]`. I dislike code that misleads the reader.
> > 
> > 
> > > As for choosing the name of the annotation
> > > 
> > [...]
> > > `TypeGuard` is the term that is used in other languages to
> describe 
> > > this notion, so it seems reasonable to me to adopt this term
> > 

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

[Paul Bryan]

Let the bikeshedding begin. How about with the underscores in place?
More readable to my eyes.

On Mon, 2021-02-15 at 14:28 +0900, Inada Naoki wrote:
> I am updating PEP 597 to include discussions in the thread.
> Before finishing the PEP, I need to decide the option name.
> 
> I used PYTHONWARNDEFAULTENCODING (envvar name) /
> warn_default_encoding (-X option and sys.flags name) before, but it
> seems too long and hard to type, easy to misspell.
> 
> Currently, I use PYTHONWARNENCODING / warn_encoding, but it is not so
> explicit.
> 
> Which name is the best balance between explicitness and readability?
> 
> * PYTHONWARNENCODING / warn_ecoding
> * PYTHONWARNOMITENCODING / warn_omit_encoding
> * PYTHONWARNDEFAULTENCODING / warn_default_encoding
> * Anything else
> 
> Regards,

___
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/G6JFTBOKIP23GTCNZBGX42N7RQASRO63/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

[Paul Bryan]

As long as we don't encounter sys.flags.pen_is_mightier type of cases,
I guess it'll be OK. :-)

On Fri, 2021-02-19 at 12:08 +0100, Victor Stinner wrote:
> Environment variable names with underscore would be more readable,
> but
> IMO consistency with all existing names matters more:
> https://docs.python.org/dev/using/cmdline.html#environment-variables
> 
> So I prefer PYTHONWARNDEFAULTENCODING env var and
> sys.flags.warn_default_encoding attribute names.
> 
> Victor
> 
> On Fri, Feb 19, 2021 at 9:48 AM Inada Naoki 
> wrote:
> > 
> > On Mon, Feb 15, 2021 at 3:00 PM Paul Bryan  wrote:
> > > 
> > > Let the bikeshedding begin. How about with the underscores in
> > > place? More readable to my eyes.
> > > 
> > 
> > I agree with you. Although it is not consistent with existing many
> > option names, it is much more readable.
> > 
> > Ivan, Victor, what do you think? about
> > PYTHON_WARN_DEFAULT_ENCODING?
> > 
> > ---
> > Inada Naoki  
> 
> 
> 

___
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/6NJ3E2PNF3QZBYH57UOTCHQL4IWGTLNP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Have virtual environments led to neglect of the actual environment?

[Paul Bryan]

I think it's a classic case of dependency hell.

OS packagers are rebundling Python packages as OS packages and
expressing their own OS-package dependency graphs. Then, you sudo pip
install something that has a conflicting dependency, it bypasses OS
packaging, and *boom*.

I find tools like pipx go a long way to solve this, as they install a
Python package and all of its dependencies in its own venv. This is
great for Python apps, and (kinda) treats them like apps on platforms
like Android, where all app dependencies are bundled and isolated from
others.

I think it would great if OS vendors did something similar to pipx for
Python-based apps: bundle the app and all of its dependencies into its
own venv.

 
On Tue, 2021-02-23 at 19:45 -0500, Random832 wrote:
> I was reading a discussion thread
> 
> about various issues with the Debian packaged version of Python, and
> the following statement stood out for me as shocking:
> 
> Christian Heimes wrote:
> > Core dev and PyPA has spent a lot of effort in promoting venv
> > because we don't want users to break their operating system with
> > sudo pip install.
> 
> I don't think sudo pip install should break the operating system. And
> I think if it does, that problem should be solved rather than merely
> advising users against using it. And why is it, anyway, that
> distributions whose package managers can't coexist with pip-installed
> packages don't ever seem to get the same amount of flak for "damaging
> python's brand" as Debian is getting from some of the people in the
> discussion thread? Why is it that this community is resigned to
> recommending a workaround when distributions decide the site-packages
> directory belongs to their package manager rather than pip, instead
> of bringing the same amount of fiery condemnation of that practice as
> we apparently have for *checks notes* splitting parts of the stdlib
> into optional packages? Why demand that pip be present if we're not
> going to demand that it works properly?
> 
> I think that installing packages into the actual python installation,
> both via distribution packaging tools and pip [and using both
> simultaneously - the Debian model of separated dist-packages and
> site-packages folders seems like a reasonable solution to this
> problem] can and should be a supported paradigm, and that virtual
> environments [or more extreme measures such as shipping an entire
> python installation as part of an application's deployment] should
> ideally be reserved for the rare corner cases where that doesn't work
> for some reason.
> 
> How is it that virtual environments have become so indispensable,
> that no-one considers installing libraries centrally to be a viable
> model anymore? Are library maintainers making breaking changes too
> frequently, reasoning that if someone needs the old version they can
> just venv it? Is there some other cause?
> ___
> Python-ideas mailing list -- python-id...@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-id...@python.org/message/KMRNKSVEPHAXA7BHFT4PWX4EKWYUF4G7/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/2VYJAJHHGOOPFQA6U7ATBKREMAC66CXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Which thing is "Development Mode"

[Paul Bryan]

Perhaps refine the packaging nomenclature to be "local development
mode"?

On Fri, 2021-02-26 at 18:34 +, Coyot Linden wrote:
> As of 3.7, there is now a python feature called Development Mode:
> 
> https://docs.python.org/3/library/devmode.html#devmode
> 
> Which has a confusingly similar and nearly identical name to a
> setuptools feature:
> 
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode
> 
> It seems like a bit of bikeshedding could create a name for one of
> them that disambiguates them.
> 
> Best,
> 
> coyot
> ___
> 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/42NQQHQEQ4FTRP5CKI5XSKD3GA6L5IIT/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/43SQIBITRKH7Q5RQEV6EGA4JDV7XQKLP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Paul Bryan]

While, I agree "master" is not and should not be considered a
derogatory term—it has demonstrable valid usage—unfortunately the broad
usage of "master/slave" terminology in technology muddies the waters. 

If it's not changed, the debate about the continuing to use the term
will likely be ongoing. So, despite there being no technical merit to
the change, my vote would be +1 to change to main, simply to avoid
distraction from inevitable ongoing pushes to change it. 


On Wed, 2021-03-10 at 08:11 -0800, Carol Willing wrote:
> I echo Barry's earlier response.
> 
> To directly address individuals who object to renaming the branch: I
> respect your opinion. As I weigh the benefits of keeping the status
> quo with the benefits of changing, I see the change as a temporary
> inconvenience to update the branch once in order to open the door to
> the benefits of conforming to the new industry norm and the
> simplification that brings to tooling configuration and
> user/contributor documentation.
> 
> Thanks.
> 
> On Wed, Mar 10, 2021 at 7:49 AM MRAB 
> wrote:
> > On 2021-03-10 15:17, Antoine Pitrou wrote:
> > > On Wed, 10 Mar 2021 14:23:33 +
> > > David Mertz  wrote:
> > >> 
> > >> Renaming main branches as 'main' is currently predominant
> > practice on
> > >> GitHub (and more broadly in Free Software communities).  Python
> > doesn't
> > >> need to cling to an old name based on a tired argument that
> > political
> > >> sensitivity is a creeping plot to destroy old "fun" prejudices
> > and
> > >> injustices.
> > > 
> > > Uh... Since you're putting "fun" in quotes, I assume this is
> > quoting
> > > someone else? (who?)
> > > 
> > It's not a quote, it's Irony punctuation (in this case, used to
> > indicate 
> > sarcasm):
> > 
> > https://en.wikipedia.org/wiki/Irony_punctuation
> > ___
> > 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/RJUCHSTSFC6IJPILRPYFQYY437NEOQ4G/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/BZQPFFBS6LVJQB23AYRBCUUTMNZG2HGF/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/ZQLSTBDLA3DPISPOAGLGEZYIY42JPFCQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Paul Bryan]

On Thu, 2021-03-11 at 02:20 +1100, Chris Angelico wrote:

> It is NOT a general convention. It is a push by Microsoft (owners of
> GitHub). Outside of GitHub, the git command still uses "master" as
> the
> default name.

I agree, not yet. But I think the writing is on the wall that this will
be the new convention.

> This is a *political* move made for *political* reasons, and has
> consequences downstream. Why is it so important to cause actual real
> problems for no reason other than to feel good about one
> insignificant
> piece of language - and, as Steve pointed out, not even the most
> significant one?

I don't see this so much as "feel good" as much as "fit in". I do not
appreciate the cost of fitting-in though in this case.

To elaborate, there are words we would clearly not use when naming
branches, modules, classes, etc. I don't think this list is fixed; I
think it changes with the times, and if we value our community, then
our community's (changing) standards should figure into our choices.

Paul

___
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/LYMQXOKK6Y4KOBQPO6QUR5SIQY53CGUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Paul Bryan]

I don't think it's particularly constructive, even as a strawman, to
imagine every conceivable way some word could be interpreted as
offensive. I submit that if the community consensus is that "chain"
becomes a derogatory term, then we should agree to change it too.

On Thu, 2021-03-11 at 08:23 +1100, Steven D'Aprano wrote:
> On Wed, Mar 10, 2021 at 02:23:33PM +, David Mertz wrote:
> > > > It even has a symbol for chains, which is associated even more 
> > > > closely with slavery than "master".
> > > > 
> > > 
> > All the other examples are also forced and contrived.  This is
> > perhaps
> > worst.  I own several chains for purposes having nothing to do with
> > bondage
> > or oppression.
> 
> Chains are an almost universal symbol of bondage and slavery: "Man is
> born free but everywhere he is in chains", according to Rosseau
> (please 
> forgive the sexism, his sense was mankind as a whole regardless of
> sex 
> or gender). How is this contrived? Not just contrived, but the
> "worst" 
> example of it.
> 
> If "master" is hurtful and harmful because of its connotations,
> "chains" 
> is even more so. There are "harmless" (supposedly) meanings for
> "master" 
> too, and "master branch" is one, but we decided to remove that. And
> yet 
> you are resistant to changing the others. Why?
> 
> 

___
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/M7JUZA4WD4FTDWT5YUKKGDKK3JRVMN2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Paul Bryan]

Google tells me...

From https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask
:
> We are then going to modify the file on both the master and slave
> repository and then merge the work.

This particular passage was also cited in GNOME developer discussions
regarding the usage of the term:
https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
 


On Wed, 2021-03-10 at 15:38 -0800, Mike Miller wrote:
> 
> On 2021-03-10 13:45, David Mertz wrote:
> > In contrast, the "master" used in version control directly borrows
> > from 
> > so-called "master/slave network architecture."
> 
> 
> It was shown upthread that this isn't the case.  Do you have more
> accurate 
> documentation to refute the claim?
> 
> - https://twitter.com/xpasky/status/1272280760280637441
> - https://en.wikipedia.org/wiki/Mastering_(audio)
> 
> -Mike
> ___
> 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/SU747SQXQ2VPTY44XPKWFIOG5K7UDDB2/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/A7IDLURAOSZNIYZEKMHFWMXG4D5TVAAA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

Sample size of 1: I have code calling __aiter__ and __anext__. It would
be nice to have representative functions—in some module—for the 3.10
release.

I would think the bar for inclusion in builtins should be quite high.
Looking at what's in the operator module, it does seem like a more
appropriate location than builtins; if setitem doesn't warrant
inclusion in builtins, hard to justify aiter and anext.

Paul

On Fri, 2021-03-19 at 13:55 -0300, Luciano Ramalho wrote:
> OK, but it seems clear to me that if there are any lingering doubts
> it would be better to add the functions to a module than to the
> built-ins, and later promote them to built-ins if people actually
> find them widely useful.
> 
> On the other hand, adding something to built-ins that turns out to be
> rarely useful adds unnecessary noise and is much harder to fix later
> without causing further problems.
> 
> Best,
> 
> Luciano
> 
> 
> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
> wrote:
> > Thanks for taking a look at this, Luciano.
> > 
> > Yury immediately replied to the comment from Jelle that you quoted
> > with the following:
> > 
> > > > Do these really need to be builtins?
> > > 
> > > We're only beginning to see async iterators being used in the
> > > wild, so we can't have a definitive answer at this point.
> > > 
> > > > They seem too specialized to be widely useful; I've personally
> > > never needed them in any async code I've written. It would make
> > > more sense to me to put them in a module like operators.
> > > 
> > > I think putting them to the operators module makes sense, at
> > > least for 3.8.  Do you want to work on a pull request?
> > > 
> > 
> > 
> > 
> > That was on 2018-06-14. On 2018-08-24, I
> > submitted https://github.com/python/cpython/pull/8895, "Add
> > operator.aiter and operator.anext". On 2018-09-07, Yury left the
> > following comment on that PR:
> > 
> > > Please don't merge this yet. I'm not convinced that aiter and
> > > anext shouldn't be builtins.
> > > 
> > 
> > 
> > 
> > So there has been some back-and-forth on this, and some more years
> > have passed, but all the latest signals we've gotten up to now have
> > indicated a preference for adding these to builtins.
> > 
> > In any case, as of my latest PR, the Python core developers now
> > have both options to choose from.
> > 
> > As community contributors, is there anything further we can do to
> > help drive timely resolution on this one way or another?
> > 
> > Thanks,
> > Josh
> > 
> > 
> > On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho
> >  wrote:
> > > Thanks for working on this, Joshua. I agree 100% with Jelle
> > > Zijlstra in the issue tracker:
> > > 
> > > Do these really need to be builtins?
> > > 
> > > They seem too specialized to be widely useful; I've personally
> > > never needed them in any async code I've written. It would make
> > > more sense to me to put them in a module like operators.
> > > 
> > > (sorry for the weird formatting, posting from an iPad)
> > > 
> > > On Wed, Mar 17, 2021 at 21:01 Joshua Bronson
> > >  wrote:
> > > > Dear python-dev,
> > > > 
> > > > New here (but not to Python). 👋 Brett Cannon recommended I
> > > > start a thread here (thanks, Brett!).
> > > > 
> > > > In December, two colleagues and I submitted
> > > > https://github.com/python/cpython/pull/23847, "Add aiter and
> > > > anext to builtins", which would fix
> > > > https://bugs.python.org/issue31861.
> > > > 
> > > > Would any core developers who may be reading this be willing
> > > > and able to provide a code review?
> > > > 
> > > > We would love to try to address any review feedback before
> > > > having to fix (another round of) merge conflicts. (And ideally
> > > > maybe even get this landed in time for the 3.10 feature freeze
> > > > in early May?)
> > > > 
> > > > Thanks and hope this finds you well.
> > > > ___
> > > > 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/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
> > > > Code of Conduct: http://python.org/psf/codeofconduct/
> > > -- 
> > > Luciano Ramalho
> > > |  Author of Fluent Python (O'Reilly, 2015)
> > > |     http://shop.oreilly.com/product/0636920032519.do
> > > |  Technical Principal at ThoughtWorks
> > > |  Twitter: @ramalhoorg
> 
> 
> ___
> 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/R3I7WIXNZNVA534XFABDQJRHHKRB6X2S/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Pyt

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:

> I’m not convinced that we need aiter(x, sentinel) at all — for iter()
> it’s mostly a legacy compatibility API.

I'm feel like I'm going to learn something today. To date, the pattern
I've used for getting the first item from an iterable:

next(iter(i))

What's the recommended alternative?

Paul

___
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/2XNN6NYR6WXKVQN5UDCPVMY7KRDKF3BG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

I did learn something today! 🙂

On Fri, 2021-03-19 at 10:37 -0700, Guido van Rossum wrote:
> I was only talking about the two-argument version, iter(x, sentinel).
> Betcha you didn’t even know that existed. :-)
> 
> On Fri, Mar 19, 2021 at 10:34 Paul Bryan  wrote:
> > On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
> > 
> > > I’m not convinced that we need aiter(x, sentinel) at all — for
> > > iter() it’s mostly a legacy compatibility API.
> > 
> > 
> > I'm feel like I'm going to learn something today. To date, the
> > pattern I've used for getting the first item from an iterable:
> > 
> > next(iter(i))
> > 
> > 
> > What's the recommended alternative?
> > 
> > Paul
> > 

___
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/4DTORCDVGMSPZ3TXEMZ3EYAVJ3GLJEUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[Paul Bryan]

I suggest that SHA224 does not qualify as "SHA256 or better".
Truncating any hash should not be considered equivalent or better.
Reductio ad absurdum: truncate to 128 bits, 16 bits, 8 bits, or 1 bit.

On Mon, 2021-03-29 at 08:15 +, Theallredman via Python-Dev wrote:
> No need to be condescending.  Trust me when I say I know the bit
> length relates to the collision resistance.  Also trust me when I say
> there are other dimensions upon which to consider one hash algo over
> another other then just collision resistance such as, power
> consumption, execution time, whether or not the algorithm suffers
> from length extension attacks.
> 
> I'm assuming the reason MD5 and SHA1 were both disallowed were
> because they have been proven to have a collision resistance less
> then 1/2 their bit length.  But this is not the case for SHA224.  It
> is just a truncated version of SHA256 and thus the underlying
> algorithm is just as strong as SHA256 except that you can expect to
> find a collision in about 16 bits of work less.
> 
> So going back to my actual question SHA224 is disallowed in record
> files because it's bit length is less then 256?
> ___
> 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/NKMWTOLR5GVSKGYWPBHB7FGMD33IYCNK/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/2RGX3KHUWHTL55RJ252RSY67HXCNWOLY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

I like! I really appreciate the work you've put into this to get it
this far.

Questions and comments:


> PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()``
> to examine annotations. Code updated to work with PEP 563 that calls
> ``eval()`` directly would have to be updated simply to remove the
> ``eval()`` call. Code using ``typing.get_type_hints()`` would
> continue to work unchanged, though future use of that function
> would become optional in most cases.

I think it is worth noting somewhere that string annotations are still
valid, and should still be evaluated if so.


> Because this PEP makes semantic changes to how annotations are
> evaluated, this PEP will be initially gated with a per-module
> ``from __future__ import co_annotations`` before it eventually
> becomes the default behavior.

Is it safe to assume that a module that does not import co_annotations,
but imports a module that does, will exhibit PEP 649 behavior when the
former accesses an annotation defined in the latter?


> * *Code that sets annotations on module or class attributes
> from inside any kind of flow control statement.* It's
> currently possible to set module and class attributes with
> annotations inside an ``if`` or ``try`` statement, and it works
> as one would expect. It's untenable to support this behavior
> when this PEP is active.

Is the following an example of the above?

@dataclass
class Foo:
 if some_condition:
 x: int
 else:
 x: float

If so, would the following still be valid?

if some_condition:
 type_ = int
else:
 type_ = float

@dataclass
class Foo:
 x: type_


> * *Code in module or class scope that references or modifies the
> local* ``__annotations__`` *dict directly.* Currently, when
> setting annotations on module or class attributes, the generated
> code simply creates a local ``__annotations__`` dict, then sets
> mappings in it as needed. It's also possible for user code
> to directly modify this dict, though this doesn't seem like it's
> an intentional feature. Although it would be possible to support
> this after a fashion when this PEP was active, the semantics
> would likely be surprising and wouldn't make anyone happy.

I recognize the point you make later about its impact on static type
checkers. Setting that aside, I'm wondering about caes where
annotations can be dynamically generated, such as
dataclasses.make_dataclass(...). And, I could see reasons for
overwriting values in __annotations__, especially in the case where it
may be stored as a string and one wants to later affix its evaluated
value. These are considerations specific to runtime (dynamic) type
checking. 

I wonder if it would make sense for each item in __annotations__ to be
evaluated separately on first access of each key, rather than all
__annotations__ on first access to the dict. Basically the dict would
act as a LazyDict. It could also provide the benefit of lessening the
expense of evaluating complex but otherwise unused annotations.


Paul


On Sun, 2021-04-11 at 18:55 -0700, Larry Hastings wrote:
> 
> Attached is my second draft of PEP 649.  The PEP and the prototype
> have both seen a marked improvement since round 1 in January; PEP 649
> now allows annotations to refer to any variable they could see under
> stock semantics:
>  * Local variables in the current function scope or in enclosing
>function scopes become closures and use LOAD_DEFER.
>  * Class variables in the current class scope are made available using
>a new mechanism, in which the class dict is attached to the bound
>annotation function, then loaded into f_locals when the annotation
>function is run.  Thus permitting LOAD_NAME opcodes to function
>normally.
> 
> I look forward to your comments,
> 
> /arry
> ___
> 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/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/SUSRZHLME3QQ4THICJVMQKRH4RVRY6XL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Relaxing the annotation syntax

[Paul Bryan]

I'm in favour of the approach proposed in PEP 649.

Movie trailer: "In a world where annotations are arbitrary non-Python
syntax..."

It seems to me we could always have annotations evaluate to Python
expressions *and* support any arbitrary syntax (e.g. through
Annotated[...] or similar mechanism). What would a relaxed inline
syntax provide that a well-placed Annotated[type,
ArbitraryNonPythonSyntax("...")] annotation wouldn't? . 

Paul


On Sun, 2021-04-11 at 20:43 -0700, Guido van Rossum wrote:
> On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw 
> wrote:
> [snip]
> > This is something the SC has been musing about, but as it’s not a
> > fully formed idea, I’m a little hesitant to bring it up.  That
> > said, it’s somewhat relevant: We wonder if it may be time to in a
> > sense separate the typing syntax from Python’s regular syntax. 
> > TypeGuards are a case where if typing had more flexibility to adopt
> > syntax that wasn’t strictly legal “normal” Python, maybe something
> > more intuitive could have been proposed.  I wonder if the typing-
> > sig has discussed this possibility (in the future, of course)?
> > 
> 
> 
> We haven't discussed this in typing-sig, but it so happens that a
> similar idea for JavaScript was mentioned to me recently, and at the
> time I spent about 5 seconds thinking about how this could be useful
> for Python, too.
> 
> Basically, where the original PEP 3107 proposed annotations to have
> the syntax of expressions and evaluate them as such, now that we've
> got PEP 563 which makes annotations available as strings and no
> longer attempts to evaluate them, we could relax this further and do
> something like just skipping tokens until a suitable delimiter is
> found (',' or ')' inside the parameter list, ':' for the return
> type). Of course, matching parentheses, brackets and braces should
> always be paired and the target delimiter should not terminate the
> scan inside such matched pairs.
> 
> It occurs to me that right now is actually very good time to think
> about this a little more, because we're at a crossroads, of sorts: we
> could adopt Larry Hastings' PEP 649, which reverses PEP 563 and makes
> annotations available at runtime as objects (e.g., `def f(x: int)`
> would have the `int` type object in the annotation instead of the
> string `"int"`). Or we could reject PEP 649, which leaves the door
> open for a more relaxed annotation syntax in the future (earliest in
> 3.11).
> 
> At the very least I recommend that the SC take this into account when
> they consider PEP 649. Accepting it has some nice benefits when it
> comes to the scoping rules for annotations -- but it would forever
> close the door for the "relaxed annotation syntax" idea you brought
> up. (Isn't it fun to be on the SC. :-)
> 
> [snip]
> > Agreed.  It’s interesting that PEP 593 proposes a different
> > approach to enriching the typing system.  Typing itself is becoming
> > a little ecosystem of its own, and given that many Python users are
> > still not fully embracing typing, maybe continuing to tie the
> > typing syntax to Python syntax is starting to strain.
> 
> It definitely is. Type checkers are still young compared to Python
> itself, and their development speed is much faster than that of
> Python. So whenever new syntax is required the strain becomes
> obvious. Thanks for making that observation!
> 
> ___
> 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/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/PUO7U3ZUIJ24W32GM7PYT34RJ5MGWZOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Sun, 2021-04-11 at 23:34 -0700, Larry Hastings wrote:

> Your example was valid, and I think your workaround should be fine. 
> Do you have a use case for this, or is this question motivated purely
> by curiosity?

It took a few readings for me to understand the limitations in the PEP.
My example and workaround were mostly for me to confirm I had read it
correctly. 

> It's fine to modify the __annotations__ dict after the creation of
> the class or module.  It's code that modifies "__annotations__" from
> within the class or module that is disallowed here.  Similarly for
> dataclasses; once it creates a class object, it can explicitly set
> and / or modify the annotations dict on that class.

Thanks. I think this clarification should be added to the PEP.

Paul

___
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/6OTLAO3XOO2DVAGJOL4Q4LKPLCMLI3FZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:

> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings 
> wrote:

> > This is really the heart of the debate over PEP 649 vs PEP 563.  If
> > you examine an annotation, and it references an undefined symbol,
> > should that throw an error?  There is definitely a contingent of
> > people who say "no, that's inconvenient for us".  I think it should
> > raise an error.  Again from the Zen: "Special cases aren't special
> > enough to break the rules."  Annotations are expressions, and if
> > evaluating an expression fails because of an undefined name, it
> > should raise a NameError.

> I agree that this is the heart of the debate. I think "annotations
> are
> for type hitns". They are for:
> 
> * Static type checkers
> * document.

+ dynamic type validation, encoding and decoding (Pydantic, FastAPI,
Fondat, et al.)

Paul

___
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/57GR7AN7L647CGMMHDWTK3PVL27HFKEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Tue, 2021-04-13 at 11:33 +0900, Inada Naoki wrote:
> On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan  wrote:
> > 
> > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
> > 
> > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings 
> > wrote:
> > 
> > 
> > This is really the heart of the debate over PEP 649 vs PEP 563.  If
> > you examine an annotation, and it references an undefined symbol,
> > should that throw an error?  There is definitely a contingent of
> > people who say "no, that's inconvenient for us".  I think it should
> > raise an error.  Again from the Zen: "Special cases aren't special
> > enough to break the rules."  Annotations are expressions, and if
> > evaluating an expression fails because of an undefined name, it
> > should raise a NameError.
> > 
> > 
> > I agree that this is the heart of the debate. I think "annotations
> > are
> > for type hitns". They are for:
> > 
> > * Static type checkers
> > * document.
> > 
> > 
> > + dynamic type validation, encoding and decoding (Pydantic,
> > FastAPI, Fondat, et al.)
> > 
> > Paul
> > 
> 
> OK. It is important use case too.
> 
> Such use cases doesn't justify raising NameError instead of getting
> stringified type hints for documents for document use cases.
> 
> On the other hand, if "dynamic type" is used heavily, eval()
> performance can be a problem.


In 3.9 this cost is paid once when a type is defined. However, in 3.10,
it gets expensive, because when the string is evaluated by
get_type_hints, its result is not stored/cached anywhere (repeated
calls to get_type_hints results in repeated evaluation). As a
workaround, I have code to "affix" the evaluated expression in
__annotations__ value. PEP 649 would resolve this and eliminate the
need for such a hack.

Paul

___
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/HJNS3JHQNZ3WFG44PXTNLFLJTQRYJWCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Mon, 2021-04-12 at 19:52 -0700, Guido van Rossum wrote:

> Why not submit a PR that adds caching to get_type_hints(), rather
> than promote a paradigm shift? 

A couple of reasons:

1. In reviewing the code, I didn't find an obvious way to store cached
values. Anything but a non-trivial change would suggest the need for a
PEP of its own to document new behavior.

2. I've been hoping that PEP 649 would be adopted, making such a hack
or any plan to cache type hints moot.

Paul

___
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/WP4OWWONK7Q72MRGTDGDJNTRYMCHQKZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

I favour annotations for type hints; the writing's been on the wall for
some time. I think the necessary escape hatch for those using it for
other purposes should be Annotated[Any, ...] (or a similar, nicer
alternative).

Guido, one of the difficulties I'm having is understanding the
direction you're going with "relaxed syntax". PEP 649 is concrete; it's
hard to weigh its merits against the usability—even feasibility—of
incorporating an as yet undefined relaxed syntax.

At the end of the day, such syntax is going to have to be represented
in some structure. If one were to accept that annotations are for type
hints only, is the debate then the difference between a Python type
(which PEP 649 would yield) and some other as yet undefined structure?
 

Paul


On Wed, 2021-04-14 at 10:24 -0700, Guido van Rossum wrote:
> On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings 
> wrote:
> > 
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> > 
> > > On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings
> > >  wrote:
> > > 
> > > > 
> > > > On 4/12/21 7:24 PM, Guido van Rossum wrote:
> > > > 
> > > > > I've been thinking about this a bit, and I think that the way
> > > > > forward is for Python to ignore the text of annotations
> > > > > ("relaxed annotation syntax"), not to try and make it
> > > > > available as an expression.
> > > > > 
> > > > > To be honest, the most pressing issue with annotations is the
> > > > > clumsy way that type variables have to be introduced. The
> > > > > current convention, `T = TypeVar('T')`, is both verbose (why
> > > > > do I have to repeat the name?) and widely misunderstood (many
> > > > > help request for mypy and pyright follow from users making a
> > > > > mistaken association between two type variables that are
> > > > > unrelated but share the same TypeVar definition). And relaxed
> > > > > annotation syntax alone doesn't solve this.
> > > > > 
> > > > > Nevertheless I think that it's time to accept that
> > > > > annotations are for types -- the intention of PEP 3107 was to
> > > > > experiment with different syntax and semantics for types, and
> > > > > that experiment has resulted in the successful adoption of a
> > > > > specific syntax for types that is wildly successful.
> > > > 
> > > > I don't follow your reasoning.  I'm glad that type hints have
> > > > found success, but I don't see why that implies "and therefore
> > > > we should restrict the use of annotations solely for type
> > > > hints".  Annotations are a useful, general-purpose feature of
> > > > Python, with legitimate uses besides type hints.  Why would it
> > > > make Python better to restrict their use now?
> > > > 
> > > 
> > > Because typing is, to many folks, a Really Important Concept, and
> > > it's confusing to use the same syntax ("x: blah blah") for
> > > different purposes, in a way that makes it hard to tell whether a
> > > particular "blah blah" is meant as a type or as something else --
> > > because you have to know what's introspecting the annotations
> > > before you can tell. And that introspection could be signalled by
> > > a magical decorator, but it could also be implicit: maybe you
> > > have a driver that calls a function based on a CLI entry point
> > > name, and introspects that function even if it's not decorated.
> > 
> > I'm not sure I understand your point.  Are you saying that we need
> > to take away the general-purpose functionality of annotations,
> > that's been in the language since 3.0, and restrict annotations to
> > just type hints... because otherwise an annotation might not be
> > used for a type hint, and then the programmer would have to figure
> > out what it means?  We need to take away the functionality from all
> > other use cases in order to lend clarity to one use case?
> > 
> 
> 
> Yes, that's how I see it.
> 
> And before you get too dramatic about it, the stringification of
> annotations has been in the making a long time, with the community's
> and the SC's support. You came up with a last-minute attempt to
> change it, using the PEP process to propose to *revert* the decision
> already codified in PEP 563 and implemented in the master branch. But
> you've waited until the last minute (feature freeze is in three
> weeks) and IMO you're making things awkward for the SC (who can and
> will speak for themselves).
>  
> > Also, if you're stating that programmers get confused reading
> > source code because annotations get used for different things at
> > different places--surely that confirms that annotations are useful
> > for more than just type hints, in real-world code, today.
> > 
> 
> No, it doesn't, it's just a hypothetical that they *would* be
> confused if there *were* other uses. Personally I haven't used any
> libraries that use non-type-hint annotations, but I've been told they
> exist.
> 
> > I genuinely have no sense of how important static type analysis is
> > in Python--personally I have no need for it--but I find it hard to
> > believe that type hints a

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

What would you expect get_type_hints(...) to return with relaxed
syntax? Today, for type hint annotations, it returns a type, which I'd
argue is an important feature to preserve (in it or some successor).

On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote:
> On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan  wrote:
> > I favour annotations for type hints; the writing's been on the wall
> > for some time. I think the necessary escape hatch for those using
> > it for other purposes should be Annotated[Any, ...] (or a similar,
> > nicer alternative).
> > 
> > Guido, one of the difficulties I'm having is understanding the
> > direction you're going with "relaxed syntax". PEP 649 is concrete;
> > it's hard to weigh its merits against the usability—even
> > feasibility—of incorporating an as yet undefined relaxed syntax.
> > 
> > At the end of the day, such syntax is going to have to be
> > represented in some structure. If one were to accept that
> > annotations are for type hints only, is the debate then the
> > difference between a Python type (which PEP 649 would yield) and
> > some other as yet undefined structure?  
> > 
> 
> 
> In `__annotations__` it would be a string, as currently implemented
> in the 3.10 alpha code. The string just might not be parsable as an
> expression.
> 
> In the AST, it will have to be a new node that just collects tokens
> and bracketed things; that could be an array of low-level tokens.
> 

___
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/AP6TJNGH5SKFX3H5EL2QWACYG3F7WQF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote:

> That's assuming the syntax in the annotations doesn't diverge too
> much
> from the Python syntax as far as brackets etc are concerned. I must
> say
> I'm not too worried about typing. But the hypothetic "def foo(prec:
> --precision int):" is already less readable. Will finding the closing
> comma or colon always be obvious to the human reader?

To push the limit, let's add some default value:

def foo(prec: --precision int = 123):
    ...

vs.

def foo(prec: "--precision int" = 123):
    ...

And if a "type parameter" becomes numeric. For example:

def foo(prec: --max bar 3000 = 123):
    ...

vs.

def foo(prec: "--max bar 3000" = 123):
    ...

Now, the quotes seem even more readable as a delimiter.

Paul

___
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/UITB2A657TAINAGWGRD6GCKWFC5PEBIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Bryan]

Seems like this is something that should make its way into stdlib?

On Thu, 2021-04-15 at 00:15 +0200, Antoine Pitrou wrote:
> On Wed, 14 Apr 2021 22:23:44 +0100
> Paul Moore  wrote:
> > On Wed, 14 Apr 2021 at 21:59, David Mertz  wrote:
> > > 
> > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore 
> > > wrote:  
> > > > 
> > > > If it's not basically equivalent to packaging.version.Version
> > > > (and
> > > > based on PEP 440) then we'll be creating a nightmare of
> > > > confusion,
> > > > because PEP 440 versions are fundamental to packaging.  
> > > 
> > > Are you suggesting that users should have to install an external
> > > module to tell what version of packages they are using?!  
> > 
> > No. To tell what version of a package they are using, a string is
> > sufficient.
> > 
> > They only need a version object if they want to do additional
> > processing (like comparing versions, or checking whether a version
> > meets a constraint).
> > 
> > Given that the packaging ecosystem already has a canonical version
> > object (provided by the packaging library), which has been used and
> > tested extensively in many environments, inventing a different API
> > seems at best ill-advised. Whether the stdlib needs a version
> > object.
> > rather than leaving that functionality to a 3rd party library, is
> > the
> > same question that comes up for *any* functionality that's proposed
> > for the stdlib, and I have no particular opinion in this case.
> 
> Tangentially, until now projects could use distutils's LooseVersion
> if
> they wanted to compare version numbers reliably.  With distutils
> being
> deprecated, they'll have to either depending on packaging (which is a
> large dependency just for comparison version numbers) or vendor
> packaging's Version class (which is doable but still some bothersome
> additional work).
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> 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/T4J2JD454XP3ZGULM777H5EG5Z3WVNMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/M6WEZ5YR66LQRFYITSD6Y5L457V3NZOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Bryan]

https://docs.python.org/3/reference/datamodel.html

On Wed, 2021-04-14 at 22:56 +, Jim J. Jewett wrote:
> Paul Moore wrote:
> > What's wrong with Version(module.__version__)? And if the
> > __version__
> > attribute isn't a valid version, raise an exception?
> 
> I don't have a deep answer, but I do think __version__ should be
> specified (or at least mentioned) at
> https://docs.python.org/3/reference/datamodel.html
> 
> At the moment, I can't even find a listing of possible __dunder__
> attributes, though I'm almost sure I've seen one in the past.
> 
> -jJ
> ___
> 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/AG344CLSKM7BDOYP3CWGXGBNFSPWVQU4/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/PZQD4HJZS34VKS6KT5QC5J6LOKEEHKEX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In support of PEP 649

[Paul Bryan]

I've been working on a similar framework, Fondat [1], that shares
similar objectives as Pydantic and FastAPI, albeit implementing in a
different manner. 

I believe other frameworks will have to "run a gauntlet" (as I already
have)  to deal with the affects of PEP 563. If anyone on these teams
are interested in how I've dealt with such issues, please feel free to
contact me directly.

I also recommend members of these teams monitor and/or participate in
the typing-sig (and maybe the python-dev) mailing list, as discussions
in these lists are likely to affect their work in the future.

Paul 

[1] https://github.com/fondat/fondat-core


On Thu, 2021-04-15 at 17:49 -0400, Paul Ganssle wrote:
> I should point out that "accept PEP 649" and "break pydantic" are not
> the only options here. The thing that will break pydantic is the end
> of PEP 563's deprecation period, not a failure to implement PEP 649.
> Other viable options include:
> - Leave PEP 563 opt-in until we can agree on a solution to the
> problem.
> - Leave PEP 563 opt-in forever.
> - Deprecate PEP 563 and go back to status quo ante.
> 
> I haven't followed this closely enough — if PEP 649 were accepted
> today, would it even be ready for use before the 3.10 code freeze
> (which is in a few weeks)?
> 
> Assuming this is a real problem (and based in part on how long it
> took for attrs to get what support it has for PEP 563, I wouldn't be
> surprised if PEP 563 is quietly throwing a spanner in the works in
> several other places as well), my vote is to leave PEP 563 opt-in
> until at least 3.11 rather than try to rush through a discussion on
> and implementation of PEP 649.
> 
> Best,
> Paul
> On 4/15/21 4:20 PM, Bluenix wrote:
> 
> > Please accept PEP 649!
> > 
> > Python's type hinting has become so much more useful than originally 
> > thought, and without this change much of that will be hindered. For example 
> > (you already know about Pydantic and FastAPI) 
> > [discord.py](https://github.com/Rapptz/discord.py)'s commands system allows 
> > you to use typehinting to specify how arguments should be converted. Take 
> > the following code:
> > 
> > ```py
> > import discord
> > from discord.ext import commands
> > 
> > bot = commands.Bot(command_prefix='>')
> > 
> > @bot.command()
> > # discord.py reads the typehints and converts the arguments accordingly
> > async def reply(ctx, member: discord.Member, *, text: str):  # ctx is 
> > always passed
> > await ctx.send(f'{member.mention}! {text}')
> > 
> > bot.run('token')
> > ```
> > 
> > I must say, this is extremely ergonomic design! Don't break it :)
> > ___
> > 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/S2O7SE4QZQARAYSCOT7PQUEPNENHDJTQ/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/GT2HQDH2HOZFSOTA5LHTFL5OV46UPKTB/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/PBGFXPC7D3NFLJSFQBDAQQCW6JCMVCFC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Paul Bryan]

As demonstrated, protocols don't get us there because duck typing isn't
a matter of having an object exhibit all of the attributes of a duck,
but rather some subset of attributes to be used by the consumer. I want
this duck to quack; someone else will want it to waddle. I don't see
how type hints could reasonably support "file like object" in the duck
type sense (unless the consumer were to specify the exact attributes of
the duck it's interested in, which I fear would become a tedious type
writing style). 

I too have sensed static typing driving the typing development agenda
in Python recently, causing other typing methods to take a back seat,
so to speak. I add my voice to those requesting Python handle other
typing methods.

Barring an innovation to allow a "subset" of a type to be declared in a
type hint, I would conclude that static typing and duck typing are
diametrically opposed. If we agree that both are valuable, developers
could build consensus on that point, and work to ensure that one does
not move forward at the expense of the other.

Paul

On Wed, 2021-04-21 at 12:36 -0700, Christopher Barker wrote:
> Thanks Mark for posting this. I know some of us are uneasy about the
> pace of the typing train 
> 
> On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith 
> wrote:
> > > If you guarded your code with `isinstance(foo, Sequence)` then I
> > could
> > > not use it with my `Foo` even if my `Foo` quacked like a
> > sequence. I was
> > > forced to use nominal typing; inheriting from Sequence, or
> > explicitly
> > > registering as a Sequence.
> > 
> > You say this like it's a bad thing, but how is this avoidable, even
> > in
> > principle? Structural typing lets you check whether Foo is duck-
> > shaped
> > -- has appropriate attribute names, etc. But quacking like a duck
> > is
> > harder: you also have to implement the Sequence behavioral
> > contract,
> > and realistically the only way to know that is if the author of Foo
> > tells you.
> > 
> 
> 
> But that's not what duck typing is (at least to me :-) ) For a given
> function, I need the passed in object to quack (and yes, I need that
> quack to sound like a duck) -- but I usually don't care whether that
> object waddles like a duck.
> 
> So yes, isinstance(obj, Sequence) is really the only way to know that
> obj is a Sequence in every important way -- but if you only need it
> to do one or two things like a Sequence, then you don't care.
> 
> And this is not uncommon -- I suspect it's very rare for a single
> function to use most of the methods of a given ABC (or protocol, or
> whatever).
> 
> And a lot of the standard library works exactly this way. Two
> examples (chosen arbitrarily, I just happen to have thought about how
> they work):
> 
> json.load() simply calls ``fp.read()``, and passes the result on down
> to json.loads(). That's it -- no checking of anything.
> 
> If fp does not have a read() method, you get an AttributeError. If fp
> has a read() method, but it returns something other than a string,
> then you get some other Exception. And if it returns a string, but
> that string isn't valid JSON, you get yet another kind of error.
> 
> In short, json.load(fp, ...) requires fp to have a read() method that
> returns a valid JSON string. But it doesn't check, nor does it need
> to, if it's getting an actual io.TextIOBase object. Is that the right
> one? I'm not totally sure, which I kind of think makes my point --
> I've been using "file-like" objects for years (decades) without
> worrying about it.
> 
> Example 2:
> 
> The str.translate method takes:
> 
> "a mapping of Unicode ordinals to Unicode ordinals, strings, or None"
> 
> Ok, then you need to pass in a Mapping, yes? Well, no you don't. The
> docs go on to say:
> 
> The table must implement lookup/indexing via __getitem__, for
> instance a
> dictionary or list.
> 
> Ah -- so we don't need a Mapping -- we need anything indexable by an
> integer that contains "ordinals, strings, or None". What the heck ABC
> could we use for that?
> 
> The ABCs do have an already complex hierarchy of containers, but
> there is no "Indexable", (quacks) and certainly no "indexable and
> returns these particular things. (quacks a certain way). (maybe
> there's something in the typing module that would work for static
> typing -- I have no idea).
> 
> I'm pretty sure this particular API was designed to accommodate the
> old py2 str.translate, which took a length-256 sequence, while also
> accommodating full Unicode, which would have required a 2^32 length
> sequence to do the same thing :-)
> 
> But again -- this is duck typing, built into the stdlib, and it works
> just fine.
> 
> Granted, until PEP 563 (kind of) , there has been nothing that
> weakens or disallows such duck typing -- those of us that want to
> write fully duck-typed code can continue to do so.
> 
> But there is the "culture" of Python -- and it has been very much
> shifting toward more typing -- A recent publication (sorry can't fi

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Paul Bryan]

I agree, that's duck typing with a protocol, and precisely the tedious
type style I would want to avoid.

I don't know what would be a good suggestion. Something where you
reference a "fully equipped" type and cherry pick the attributes you
want? Something like `Protocol[Duck, ("quack", "waddle")]`?

Paul
 

On Wed, 2021-04-21 at 16:13 -0700, Jelle Zijlstra wrote:
> 
> 
> El mié, 21 abr 2021 a las 15:30, Paul Bryan ()
> escribió:
> > As demonstrated, protocols don't get us there because duck typing
> > isn't a matter of having an object exhibit all of the attributes of
> > a duck, but rather some subset of attributes to be used by the
> > consumer. I want this duck to quack; someone else will want it to
> > waddle. I don't see how type hints could reasonably support "file
> > like object" in the duck type sense (unless the consumer were to
> > specify the exact attributes of the duck it's interested in, which
> > I fear would become a tedious type writing style). '
> > 
> 
> 
> This approach (a Protocol that declares exactly what you need the
> file-like object to do) is in fact what we've been doing in typeshed,
> the repository that provides type hints for the standard library. For
> those unfamiliar, it would look something like this:
> 
> from typing import Protocol
> 
> class SupportsRead(Protocol):
>     def read(self) -> bytes: ...
> 
> def uses_a_file(f: SupportsRead) -> None:
>      f.read()
> 
> That's somewhat tedious, to be sure, but it is working duck typing.
>  
> > 
> > I too have sensed static typing driving the typing development
> > agenda in Python recently, causing other typing methods to take a
> > back seat, so to speak. I add my voice to those requesting Python
> > handle other typing methods.
> > 
> > Barring an innovation to allow a "subset" of a type to be declared
> > in a type hint, I would conclude that static typing and duck typing
> > are diametrically opposed. If we agree that both are valuable,
> > developers could build consensus on that point, and work to ensure
> > that one does not move forward at the expense of the other.
> > 
> 
> What would you suggest? Should the syntax for declaring Protocols be
> more concise?
>  
> > 
> > Paul
> > 
> > On Wed, 2021-04-21 at 12:36 -0700, Christopher Barker wrote:
> > > Thanks Mark for posting this. I know some of us are uneasy about
> > > the pace of the typing train 
> > > 
> > > On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith 
> > > wrote:
> > > > > If you guarded your code with `isinstance(foo, Sequence)`
> > > > then I could
> > > > > not use it with my `Foo` even if my `Foo` quacked like a
> > > > sequence. I was
> > > > > forced to use nominal typing; inheriting from Sequence, or
> > > > explicitly
> > > > > registering as a Sequence.
> > > > 
> > > > You say this like it's a bad thing, but how is this avoidable,
> > > > even in
> > > > principle? Structural typing lets you check whether Foo is
> > > > duck-shaped
> > > > -- has appropriate attribute names, etc. But quacking like a
> > > > duck is
> > > > harder: you also have to implement the Sequence behavioral
> > > > contract,
> > > > and realistically the only way to know that is if the author of
> > > > Foo
> > > > tells you.
> > > > 
> > > 
> > > 
> > > But that's not what duck typing is (at least to me :-) ) For a
> > > given function, I need the passed in object to quack (and yes, I
> > > need that quack to sound like a duck) -- but I usually don't care
> > > whether that object waddles like a duck.
> > > 
> > > So yes, isinstance(obj, Sequence) is really the only way to know
> > > that obj is a Sequence in every important way -- but if you only
> > > need it to do one or two things like a Sequence, then you don't
> > > care.
> > > 
> > > And this is not uncommon -- I suspect it's very rare for a single
> > > function to use most of the methods of a given ABC (or protocol,
> > > or whatever).
> > > 
> > > And a lot of the standard library works exactly this way. Two
> > > examples (chosen arbitrarily, I just happen to have thought about
> > > how they work):
> > > 
> > > json.load() simply calls ``fp.read()``, and passes the result on
>

[Python-Dev] Re: bz2.BZ2File doesn't support name?

[Paul Bryan]

I think one of the issues is that BZ2File accepts the filename as a
name or as a file-like object!

I don't see why it couldn't be enhanced to provide the filename though
(by pulling it from the fp). Meanwhile, the ugly way to get the
filename from a BZ2File object:

pbryan@dynamo:~$ python3
Python 3.9.3 (default, Apr  8 2021, 23:35:02) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> f = bz2.BZ2File("test.bz2")
>>> f._fp.name
'test.bz2'
>>> 

Paul


On Tue, 2021-04-27 at 04:04 +, r...@panix.com wrote:
> I was surprised recently to discover that BZ2File (at least in 3.7)
> doesn't have a name attribute.  Is there some fundamental reason name
> couldn't be supported, or is it just a bug that it wasn't
> implemented?
> ___
> 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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/S4KSWVFLM5JEZCI3OFWJSEKR3JUJL6XL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Documenting collections.abc __class_getitem__ type hints

[Paul Bryan]

I'm looking through the documentation, and not finding any good
reference for type hints for __class_getitem__ in the collections.abc
module.

I do see some of it covered in the typing module documentation, but
those are deprecated, and some are somewhat cryptic (e.g. Coroutine).

Make sense to open a BPO and start a PR for doc updates?

Paul 

___
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/U3QIWBXHKRSWNVE6F4QKOT2OJULNZBWY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Documenting collections.abc __class_getitem__ type hints

[Paul Bryan]

I should have probably written my message more clearly. I'm referring
to the specific expected parameters for generic types, especially those
in collections.abc (e.g. Callable, Coroutine, ...). Each expects
different parameters depending on its type.

Other examples, where are the (non-deprecated) generic type signatures
for dict, list, etc. defined?

Data model seems appropriate for covering how to expose generic types,
but the type-specific signatures should be defined closer to there
types?

Paul

On Thu, 2021-05-06 at 11:10 -0300, Luciano Ramalho wrote:
> Hello, Paul.
> 
> The docs for __class_getitem__ are here:
> 
> https://docs.python.org/3/reference/datamodel.html#emulating-generic-types
> 
> I think the Data Model chapter is the right place for it.
> 
> Cheers,
> 
> Luciano
> 
> On Thu, May 6, 2021 at 2:14 AM Paul Bryan  wrote:
> > 
> > I'm looking through the documentation, and not finding any good
> > reference for type hints for __class_getitem__ in the
> > collections.abc module.
> > 
> > I do see some of it covered in the typing module documentation, but
> > those are deprecated, and some are somewhat cryptic (e.g.
> > Coroutine).
> > 
> > Make sense to open a BPO and start a PR for doc updates?
> > 
> > Paul
> > 
> > ___
> > 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/U3QIWBXHKRSWNVE6F4QKOT2OJULNZBWY/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 

___
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/X2WORI3U3STO4TU6CE3KCJWUFEGAJJ6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

[Paul Bryan]

The way I see it, the concurrency model to be used is selected by
developers. They can choose between multi-threading, multi-process, or
asyncio, or even a hybrid. If developers select multithreading, then
they carry the burden of ensuring mutual exclusion and avoiding race
conditions, dead locks, live locks, etc.


On Mon, 2021-10-18 at 13:17 +, Mohamed Koubaa wrote:
> I love everything about this - but I expect some hesitancy due to
> this "Multithreaded programs are prone to concurrency bugs.".
> 
> If there is significant pushback, I have one suggestion:
> 
> Would it be helpful to think of the python concurrency mode as a
> property of interpreters?
> `interp = interpreters.create(concurrency_mode=interpreters.GIL)`
> or 
> `interp = interpreters.create(concurrency_mode=interpreters.NOGIL)`
> 
> and subsequently python _environments_ can make different choices
> about what to use for the 0th interpreter, via some kind of
> configuration.
> Python modules can declare which concurrency modes they supports. 
> Future concurrency modes that address specific use cases could be
> added.
> 
> This would allow python environments who would rather not audit their
> code for concurrency isuses to opt out, and allow incremental
> adoption.  I can't intuit whether this indirection would cause a
> performance problem in the C implementation or if there is some
> clever way to have different variants of relevant objects at compile
> time and switch between them based on the interpreter concurrency
> mode.
> ___
> 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/ZUEWHEOW34MNHKOY2TLTFI4LHYJX4YDW/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/36ENPZV6W3NXIUS3TPU4MQ235B2IF5XF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Paul Bryan]

NoneType is just another type, and in type checking scenarios should be
expressed with `Optional[type]` or more preferably in the future `type
| None`; `None` is not a non-value. Assuming what I just wrote is true,
I don't get what the basis of this thread is; what am I missing?

On Mon, 2021-10-18 at 14:13 +0100, Steve Dower wrote:
> Thanks for allowing me to speak for myself, as I said I would when 
> contacted off list :)
> 
> But as it happens, you've summarised my position very accurately:
> 
> > he now believes the implementation of these operators would lead
> > people to a style of coding which would lead to the proliferation
> > of None as an exception-less error result and also throughout data
> > structures. My understanding is that his current preference is to
> > focus on functional composition and styles of programming that
> > disallow the use of None.
> 
> As additional context, C# and the .NET Framework have just gone
> through 
> the exercise of making (and propagating) non-nullable reference types
> (and their "null" is far more like our None than C's NULL). Our type 
> checkers are also pushing in this direction by requiring Optional[].
> The 
> argument in all cases is that it allows for simpler code that can
> safely 
> ignore non-values because they cannot be passed.
> 
> Adding ??, ?. and ?[, particularly in their short-circuiting
> evaluation 
> form, encourages more complex code by adding value-based branching 
> within an expression. And it encourages it on the "outside" of the
> API, 
> not within it. Which means API designers can more easily justify 
> returning None because their caller can use None-aware operators to 
> basically ignore it. (I would argue that the API designer should work
> harder to create an API that doesn't ever have to return None.)
> 
> To be clear, I'm thinking very much in terms of "impact on what
> people 
> will consider to be Pythonic API design over the next 10 years", that
> is, what people think they *should* do with this, rather than simply 
> what they *could*. So it's all very hypothetical and I have no data
> for 
> it, much like when it was decided that Optional[] would be mandatory
> on 
> types where None is permitted.
> 
> And with that, I'm bowing out of the fresh discussion (unless the SC 
> wants to discuss it directly with me). I'll continue advocating for 
> tools/features that help people create better APIs, but I'm not going
> to 
> spend a lot of time arguing against those that I believe will not.
> 
> Cheers,
> Steve
> 
> On 10/15/2021 3:08 AM, Doug Swarin wrote:
> > Steven D'Aprano wrote:
> > > Hello Doug,
> > > On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> > > > I believe strong and valid arguments can be made about the use
> > > > of None
> > > > being a fundamental flaw in some types of coding
> > > > Can you elaborate on that? Obviously it is not always
> > > > appropriate to use
> > > None, but I've never seen it called a *fundamental* flaw.
> > > I know that the null pointer has been called a billion-dollar
> > > mistake,
> > > but Python's None is not a null pointer.
> > 
> > I apologize that I may have spoken too strongly here. When I
> > emailed Mr. Dower, he mentioned that he now believes the
> > implementation of these operators would lead people to a style of
> > coding which would lead to the proliferation of None as an
> > exception-less error result and also throughout data structures. My
> > understanding is that his current preference is to focus on
> > functional composition and styles of programming that disallow the
> > use of None.
> > 
> > I certainly don't mean to speak for him and I hope he will weigh in
> > with a more detailed explanation of his thoughts and objections,
> > but I personally disagree as a matter of pure practicality. It's
> > just plain useful to be able to easily take non-values and safely
> > deal with them without having to constantly check for None or to
> > catch and inspect exceptions to see if it's a case that can be
> > ignored.
> > 
> > I did indeed think about connecting None to the 'billion dollar
> > mistake' but decided against it since as you say None is not a null
> > pointer, and I should have chosen my words a little more carefully
> > when revising my initial post (likely by removing the word
> > 'fundamental').
> > 
> > Doug
> ___
> 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/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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 ar

[Python-Dev] Re: Having Sorted Containers in stdlib?

[Paul Bryan]

On Wed, 2021-11-10 at 17:16 +1100, Steven D'Aprano wrote:
> On Tue, Nov 09, 2021 at 10:01:35PM -0800, Christopher Barker wrote:
> > Maybe a stupid question:
> > 
> > What are use cases for sorted dicts?
> > 
> > I don’t think I’ve ever needed one.
> 
> Good question :-)

It could be handy for deterministic iteration of its values, for
example to  allow serialized values to be easily compared, or to
generate and verify a signatures. It's edge case material; I wouldn't
think it's strong enough use case for inclusion in stdlib.


___
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/WHA7HC7U7VTLALPDP7BS5QLOFDG54Y4T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

[Paul Bryan]

"Exactly the same" between Python versions, or exactly the same as
previously reported?

On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote:
> To eliminate the possibility of being affected by the different
> versions of numpy I have just now upgraded numpy in Python 3.8
> environment to the latest version, so both 3.8 and 3.10 and using
> numpy 1.21.4 and still the timing is exactly the same.
> ___
> 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/THPN4OWM3A335LDO7HVIQSIDFFVO5URZ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/V3FU2ZLXLFMDOPUZ4F6L725IO5FEABKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Paul Bryan]

You've proposed a "what", but I don't see a "why".

Indeed, it will break some code.

I've been (currently legally) expressing __slots__ as sets, which is
arguably more consistent with its purpose, and in testing appeared to
perform better than tuples.

So, I would request that you amend the allowed types to include sets.

Also, people are using dicts to provide docstrings on attributes, so
that would need to be addressed as well. 

On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
> 18.03.22 11:29, Serhiy Storchaka пише:
> > It will break some code (there are 2 occurrences in the stdlib an 1
> > in 
> > scripts), but that code can be easily fixed.
> 
> Actually it will break more code, because initializing __slots__ with
> a 
> list is pretty common. Maybe restrict it to tuple or list? But having
> an 
> immutable __slots__ may be more reliable.
> 
> ___
> 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/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Paul Bryan]

On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:
> The motivation has been explained already.

In this thread?

> What on earth did your test do that got a speedup by using sets? Was
> it repeatedly checking whether a variable was in a slot? The other
> thing this does is rearrange the order in which slots appear from run
> to run (since set order is affected by hash randomization) and you
> might have gotten lucky with a popular attribute being moved to the
> front, where it's more likely to be in the memory cache already
> (cache lines being 64 bytes and pointers being 8 bytes nowadays).

I created objects in a tight loop, populating attributes, noting the
elapsed time.

> I agree that dicts are a use case to preserve.
> 
> On Fri, Mar 18, 2022 at 08:59 Paul Bryan  wrote:
> > You've proposed a "what", but I don't see a "why".
> > 
> > Indeed, it will break some code.
> > 
> > I've been (currently legally) expressing __slots__ as sets, which
> > is arguably more consistent with its purpose, and in testing
> > appeared to perform better than tuples.
> > 
> > So, I would request that you amend the allowed types to include
> > sets.
> > 
> > Also, people are using dicts to provide docstrings on attributes,
> > so that would need to be addressed as well. 
> > 
> > On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
> > > 18.03.22 11:29, Serhiy Storchaka пише:
> > > > It will break some code (there are 2 occurrences in the stdlib
> > > > an 1 in 
> > > > scripts), but that code can be easily fixed.
> > > 
> > > Actually it will break more code, because initializing __slots__
> > > with a 
> > > list is pretty common. Maybe restrict it to tuple or list? But
> > > having an 
> > > immutable __slots__ may be more reliable.
> > > 
> > > ___
> > > 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/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > 
> > 
> > ___
> > 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/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
> > Code of Conduct: http://python.org/psf/codeofconduct/

___
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/YL2SX4TOFSE6U77C6VXEGPERN4V7WVW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[Paul Bryan]

Can someone state what's currently unpalatable about 649? It seemed to
address the forward-referencing issues, certainly all of the cases I
was expecting to encounter.

On Sun, 2022-05-01 at 15:35 -0600, Larry Hastings wrote:
> 
> FWIW, I'm in agreement.  My "forward class" proposal(s) were me
> trying to shine a light to find a way forward; I'm in no way adamant
> that we go that direction.  If we can make 649 palatable without
> introducing forward declarations for classes, that's great!  If in
> the future we discover more edge cases that Carl's approach doesn't
> easily solve, we could always revisit it later.  For now it goes in
> the freezer of "ideas we aren't moving forward with".
> 
> /arry
> On 4/29/22 19:08, Guido van Rossum wrote:
>  
> > 
> >  FWIW, Carl presented a talk about his proposed way forward using
> > PEP 649 with some small enhancements to handle cases like
> > dataclasses (*), and it was well received by those present. I
> > personally hope that this means the end of the "forward class
> > declarations" proposals (no matter how wonderful), but the final
> > word is up to the SC.
> > 
> > (*) Mostly fixing the edge cases of the "eval __code__ with tweaked
> > globals" hack that Carl came up with previously, see
> > https://github.com/larryhastings/co_annotations/issues/2#issuecomment-1092432875
> > .
> > 
> > -- 
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
> > 
> > 
> > ___
> > 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/EBDKGKPMOHM674PMUXCVZDRUD5NTIKZB/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/RXZWTIRVRVHOOKZ6FHIRLQRQBDNCL62X/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/OIHZVLRYJAT3JHX37U4QPDKJTXTGO3EM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[Paul Bryan]

Thanks, Carl and Larry for the explanations.

On Sun, 2022-05-01 at 16:13 -0600, Carl Meyer wrote:
> Hi Paul,
> 
> On Sun, May 1, 2022 at 3:47 PM Paul Bryan  wrote:
> > 
> > Can someone state what's currently unpalatable about 649? It seemed
> > to address the forward-referencing issues, certainly all of the
> > cases I was expecting to encounter.
> 
> Broadly speaking I think there are 3-4 issues to resolve as part of
> moving forward with PEP 649:
> 
> 1) Class decorators (the most relevant being @dataclass) that need to
> inspect something about annotations, and because they run right after
> class definition, the laziness of PEP 649 is not sufficient to allow
> forward references to work. Roughly in a similar boat are `if
> TYPE_CHECKING` use cases where annotations reference names that
> aren't
> ever imported.
> 
> 2) "Documentation" use cases (e.g. built-in "help()") that really
> prefer access to the original text of the annotation, not the repr()
> of the fully-evaluated object -- this is especially relevant if the
> annotation text is a nice short meaningful type alias name, and the
> actual value is some massive unreadable Union type.
> 
> 3) Ensuring that we don't regress import performance too much.
> 
> 4) A solid migration path from the status quo (where many people have
> already started adopting PEP 563) to the best future end state.
> Particularly for libraries that want to support the full range of
> supported Python versions.
> 
> Issues (1) and (2) can be resolved under PEP 649 by providing a way
> to
> run the __co_annotations__ function without erroring on
> not-yet-defined names, I think we have agreement on a plan there.
> Performance of the latest PEP 649 reference implementation does not
> look too bad relative to PEP 563 in my experiments, so I think this
> is
> not an issue -- there are ideas for how we could reduce the overhead
> even further. The migration path is maybe the most difficult issue --
> specifically how to weigh "medium-term migration pain" (which under
> some proposals might last for years) vs "best long-term end state."
> Still working on reaching consensus there, but we have options to
> choose from. Expect a more thorough proposal (probably in the form of
> an update to PEP 649?) sometime after PyCon.
> 
> Carl

___
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/M3ZPMSHFZBG4MQ4X55DPNAPA7J4T2ZXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Confusing naming of Optional type should be changed

[Paul Bryan]

Given that it's now presumably preferred spelling is `str | None` in
Python 3.10, why would we not seek to deprecate `Optional[str]` instead
of inventing a replacement?

On Thu, 2022-06-30 at 17:15 +, nveric...@gmail.com wrote:
> I am aware this is clarified in the Python documentation for the
> typing module but I and others have thought the naming of Optional is
> still quite confusing by itself. 
> 
> "Note that this is not the same concept as an optional argument,
> which is one that has a default. An optional argument with a default
> does not require the Optional qualifier on its type annotation just
> because it is optional." - typing.Optional docs
> 
> Google defines optional as this, "available to be chosen but not
> obligatory."
> 
> Pretend we have a function like this:
> def test_func(param: Optional[str]) -> None:
>     ...
> 
> The argument param is typed as Optional[str] meaning Union[str, None]
> or str | None. Optional here if we follow the definition above,
> basically means it can be str but not required or obligated to be
> that type. See the problem with the naming? This is a function where
> param can be None or str, not just it can be str but not obligated.
> Some interpretations may think optional means left to one's choice as
> well. The docs even have to clarify the use of Optional with typing
> because of this confusion. 
> 
> I believe this has been proposed before (not sure) but something like
> Nullable or Noneable (not sure about naming) would make much more
> sense in the context of typing. 
> def test_func(param: Noneable[str]) -> None:
>     ...
> 
> It also would work and still make sense if there is a default value
> for the argument:
> def test_func(param: Noneable[str] = None) -> None:
>     ...
> 
> def test_func(param: Noneable[str] = "hello world") -> None:
>     ...
> ___
> 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/QT7RJSDMWKTGB6PNVMGZ2NY2D4PT75Y7/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/CQQ6O4HBDA46ASYEG2M7BF3ZE26KSB5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 515: Non-empty return statement

[Paul Bryan]

Per PEP 515:

> It is a SyntaxError to have a non-empty return statement in an
> asynchronous generator.

Synchronus generators can return values that include it in the
StopIteration exception. Why would a return value in an asynchronous
generator not do the same in the StopAsyncIteration?

___
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/IYF6QKMNSTZEVEXBDIJH7NO2VNDJNUZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Enum bug?

[Paul Bryan via Python-Dev]

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
___
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/5IJPHFRLPZE5CGYZH6IXCDH2V4ODXMTB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Dusting off PEP 533?

[Paul Bryan via Python-Dev]

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
CancelledError, long after the context manager is assumed to be out of
scope. Per PEP 525, I can call aclose coroutine method to cleanup the
generator, but it requires the code iterating to be aware that that
closing the generator is necessary. 

Any appetite for putting PEP 533 back on the table to address this kind
of issue?

___
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/RZXOTQT3QXCVWCPZOWTIJNWTT2TZLWCW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

[Paul Bryan via Python-Dev]

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] sufficient for my needs in a runtime
type validation and encoding/decoding library.

[1] A pain point for me is the runtime cost of evaluating 3.10 style
type hints, as they're (re-)evaluated for every call to get_type_hints.
I've worked around this for now with my own function affix_type_hints,
which evaluates get_type_hints once and replaces __annotations__ with
the evaluated value. It also addresses a scoping problem where a type
hint may reference a value that's not globally scoped for the object
being annotated; the hint can be evaluated and affixed within that
scope.

Paul
___
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/36C5BLHJEBMFUNCC7L5GUHNLHKXH6GGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 to local variables or class
> attributes. 

Given get_type_hints can be provided localns argument, this statement
is not exactly true.

Using localns is how I currently address scoping issues when affixing
type hints. Maybe it could be argued that I'm abusing this feature, but
then I would ask what the intent of localns is if not to provide
additional (missing) scope during type hint evaluation?

Under PEP 649, when __co_annotations__ is called (presumably by calling
get_type_hints), would localns effectively be ignored?


2. __co_annotations__ scope?

I'm wondering why __co_annotations__ function could not be scoped
(within a closure?) such that it can access the values where the
function, method, class or module are being declared? I acknowledge
that I'm railing against PEP 563 again, trying to reclaim lost ground. 


On Mon, 2021-01-11 at 10:27 -0800, Larry Hastings wrote:
> 
> On 1/11/21 10:16 AM, Chris Angelico wrote:
> 
> > Number allocation is pretty informal. Go ahead and grab PEP 649;
> It's now checked in as PEP 649, with a modern header, modern
> copyright, and I went ahead and grabbed the formatting stanza from
> the end too.
> Welcome to the world, baby 649!
> 
> /arry
> ___
> 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/OKOQEAEPKYDX6AVEFD7DDPBKOHGXB4GB/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/5GLDASRAWNEJXYG3Y7NDUBPPNR6TTIGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 must assume they will be evaluated in
> > > module-level scope. They may no longer refer directly to local
> > > variables or class attributes. 
> > 
> > Given get_type_hints can be provided localns argument, this
> > statement is not exactly true.
> PEP 563 states:
> 
> > For code that uses type hints, the typing.get_type_hints(obj,
> > globalns=None, localns=None) function correctly evaluates
> > expressions back from its string form.
> So, if you are passing in a localns argument that isn't None, okay,
> but you're not using them "correctly" according to the language. 
> Also, this usage won't be compatible with static type checkers.
I acknowledge that this will not fly with static type checkers. I also
want to make sure that annotations can continue to serve runtime type
validation.

PEP 563 does go on to state:
> For code which uses annotations for other purposes, a
> regulareval(ann, globals, locals) call is enough to resolve the
> annotation.

And I believe this would no longer be true under PEP 649;
further, localns (and maybe globalns) parameters in get_type_hints
would become meaningless.

This passage in PEP 563 appears not true in Python 3.9 with __future__
annotations, emphasis mine:
> The get_type_hints() function automatically resolves the correct
> value of globalns for functions and classes. It also automatically
> provides the correct localns for classes.

If this passage was true, I believe the issue that resulted in my
affixing type hints could have been averted. 

> > Under PEP 649, when __co_annotations__ is called (presumably by
> > calling get_type_hints), would localns effectively be ignored?
> Yes.  You can experiment with this in Python 3.9--just turn off
> annotation stringizing.  It seems that you can still use strings as
> annotations and typing.get_type_hints() will evaluate them--and I
> assume it'll use localns at that point, just as it does today.
OK, would string representations of type hints continue be supported
under PEP 649 if strings are used as annotations? And, would
get_type_hints continue evaluate the annotations in that case? 

> > 2. __co_annotations__ scope?
> > 
> > I'm wondering why __co_annotations__ function could not be scoped
> > (within a closure?) such that it can access the values where the
> > function, method, class or module are being declared? I acknowledge
> > that I'm railing against PEP 563 again, trying to reclaim lost
> > ground.
> This is addressed in PEP 563, when it rejected the idea of using
> "function local state when defining annotations":

I wasn't thinking the function local state of that being annotated
(agree, this would be prohibitive), but rather the scope in which the
annotated function, class, module, etc. are being defined.

> > This would be prohibitively expensive for highly annotated code as
> > the frames would keep all their objects alive. That includes
> > predominantly objects that won't ever be accessed again.
> > 
> > https://www.python.org/dev/peps/pep-0563/#keeping-the-ability-to-use-function-local-state-when-defining-annotations
> Doing this automatically would indeed incur a sizeable runtime cost,
> for a feature that is already rarely used at runtime.  I guess it
> would be remotely possible? to add this as an optional feature?  But
> this gets crazy quickly--what if it's defined inside a function
> inside another function inside a class inside another function?--and
> the use cases seem few, and TOOWTDI.

I think this exactly the case for closures today.

> I've never understood how closures work in Python, so I'm not the guy
> to ask how possible / hard this would be.  Then again, the
> implementation of closures is obscure enough that I've never been
> able to understand them, so that seems to establish at least a base
> level of difficulty.
> Anyway, one of the concepts my PEP is built on is that "annotations
> are always evaluated at module-level scope". I'd be against changing
> that unless it could be achieved without runtime cost--which AFAIK is
> impossible.
> 
> Cheers,
> 
> /arry

___
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/ZOEQFZ4RPZJW7MWO7US5OH23357QQLNV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 will use
> its own __globals__ as the new function's globals.
I'm having trouble parsing this. Does this mean the newly bound
__co_annotations__ function will inherit __globals__ from the function
it's annotating?

Exceptions:
It's quite possible for a __co_annotation__ function call to raise an
exception (e.g. NameError). When accessing __annotations__, if such an
exception is raised during the call to __co_annotations__, what is the
expected behavior?

s/__co_//?:
I'm probably naive, but is there a reason that one could not just store
a callable in __annotations__, and use the descriptor to resolve it to
a dictionary and store it when it is accessed? It would be one less
dunder in the Python data model.


On Mon, 2021-01-11 at 15:46 -0800, Larry Hastings wrote:
> 
> On 1/11/21 3:02 PM, Paul Bryan wrote:
> 
> > PEP 563 does go on to state:
> > 
> > > For code which uses annotations for other purposes, a regular
> > > eval(ann, globals, locals) call is enough to resolve the
> > > annotation.
> > 
> > And I believe this would no longer be true under PEP 649;
> > further, localns (and maybe globalns) parameters in get_type_hints
> > would become meaningless.
> > 
> > [...]
> > And, would get_type_hints continue evaluate [string] annotations in
> > that case?
> I don't work on typing.get_type_hints() so someone else will have to
> answer this question.  All I can say is, with PEP 649 semantics, if
> you set an annotation to a string, you'll get a string back.  And in
> 3.9 (and my out-of-date 3.10) I observe that typing.get_type_hints()
> will eval() string annotations for you, and localns is significant.
> 
> 
> > This passage in PEP 563 appears not true in Python 3.9 with
> > __future__ annotations, emphasis mine:
> > 
> > > The get_type_hints() function automatically resolves the correct
> > > value of globalns for functions and classes. It also
> > > automatically provides the correct localns for classes.
> > 
> > If this passage was true, I believe the issue that resulted in my
> > affixing type hints could have been averted.
> As you've discovered, this is one of the places where PEP 563 seems
> to be out-of-date with respect to its implementation.  I sifted
> through the source code to typing.get_type_hints() twice, and near as
> I can figure out, localns is literally only ever set to None unless
> you override it with the parameter.
> 
> 
> > OK, would string representations of type hints continue be
> > supported under PEP 649 if strings are used as annotations?
> PEP 649 is itself totally agnostic as to what value you use as an
> annotation.  It disallows a couple funky things (yield, walrus
> operator), but beyond that it doesn't care.  Any Python expression or
> value is fine.
> 
> 
> > 
> > > 
> > > > 2. __co_annotations__ scope?
> > > > 
> > > > I'm wondering why __co_annotations__ function could not be
> > > > scoped (within a closure?) such that it can access the values
> > > > where the function, method, class or module are being declared?
> > > > I acknowledge that I'm railing against PEP 563 again, trying to
> > > > reclaim lost ground.
> > > This is addressed in PEP 563, when it rejected the idea of using
> > > "function local state when defining annotations":
> > 
> > I wasn't thinking the function local state of that being annotated
> > (agree, this would be prohibitive), but rather the scope in which
> > the annotated function, class, module, etc. are being defined.
> That's what PEP 563 is referring to.  If you read the thread from
> November 2017 where the idea was discussed, they were talking about
> referring to e.g. "class-level definitions", as in, things defined
> inside class scope.  Which is prohibitive.
> (If I understand you correctly, you thought it was referring to the
> scope inside the function when it runs?  Because I can't imagine how
> that would ever work.  What if the function hasn't been called yet? 
> What if it's been called a thousand times?  What if it's running
> right now in various stages of completeness in five threads and you
> inspect the annotation from a sixth thread?)
> 
> Cheers,
> 
> /arry

___
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/4EB5ZQQ65KLH3LDRLM4N4BQMVWGPKAAW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 instance as a method during
> > object creation?
> I'm not.  In PEP 649 I think every reference of "binding" is talking
> about binding a code object to a globals dict to produce a function
> object.   The process of binding a function to an object instance to
> make a method is conceptually very similar, but distinct.
> (and btw, functions aren't bound to their object to make methods
> during object creation, it's done lazily at the time you ask for it--
> that's what the "descriptor protocol" is all about!)
I think it'd be worth briefly describing binding, to avoid confusion.
I'm now more educated on function/method binding lifecycle though, so
bonus! 🙂

> > Function Annotations:
> > 
> > > When binding an unbound annotation code object, a function will
> > > use its own __globals__ as the new function's globals.
> > I'm having trouble parsing this. Does this mean the newly bound
> > __co_annotations__ function will inherit __globals__ from the
> > function it's annotating?
> Yes.  Though I wouldn't use "inherit", I'd just say it "uses" the
> __globals__ from the function.

Then I think this solves my particular scoping problem with 3.10
string-evaluated annotations!

> > Exceptions:
> > It's quite possible for a __co_annotation__ function call to raise
> > an exception (e.g. NameError). When accessing __annotations__, if
> > such an exception is raised during the call to __co_annotations__,
> > what is the expected behavior?
> If the function fails for any reason--throws an exception, or just
> doesn't return an acceptable value--then the getter immediately
> exits, and the internal state of the object is unchanged.  If you
> wanted to, you could catch the exception, fix the error, and get
> __annotations__ again, and it'd work.
OK.

> > s/__co_//?:
> > I'm probably naive, but is there a reason that one could not just
> > store a callable in __annotations__, and use the descriptor to
> > resolve it to a dictionary and store it when it is accessed? It
> > would be one less dunder in the Python data model.
> That would work, but I think the API is a bit of a code smell. 
> __annotations__ would no longer be stable:
> > a.__annotations__ = o
> > assert a.__annotations__ == o
> Would that assert fail?  It depends on what type(o) is, which is
> surprising.

Equally surprising?:

a.__co_annotations__ = o
a.__annotations__
assert a.__co_annotations__ == o

Paul

___
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/Z7SFYJZQHUQKZC77L4EMNZIYAQUXK3GJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 automatically resolves the
> > > > correct value of globalns for functions and classes. It also
> > > > automatically provides the correct localns for classes.
> > > 
> > > If this passage was true, I believe the issue that resulted in my
> > > affixing type hints could have been averted.
> > As you've discovered, this is one of the places where PEP 563 seems
> > to be out-of-date with respect to its implementation.  I sifted
> > through the source code to typing.get_type_hints() twice, and near
> > as I can figure out, localns is literally only ever set to None
> > unless you override it with the parameter.
> > 
> 
> 
> This seems to be a bug in get_type_hints() for which someone should
> file a bug on bpo, please!

___
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/LS36RQ2UPLFKIOJAXF7EAGEMKBOCEIKW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 __co_annotations__ function will get globals from the
function it annotates, doesn't it get more than just module scope?

Paul

___
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/VWY42HWKA5LQ7BZ7VROCEDWVYHWELSBI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

[Paul Bryan via Python-Dev]

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 that.
> > 
> 
> This has tripped up many people. Maybe we should just bite the bullet
> and change this?

+1, FWIW.

___
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/GBM2Z3TN42LR4DKMPMDXSD7WPKWGBFDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 getattr
__annotations__. I know this changes the descriptor behavior you
documented, but at least it would occur explicitly in a function call
and may be easier for developers to reason about?  It would also
address my other question of trying to access __annotations__, only to
be confronted with an exception raised within __co_annotations__.


On Fri, 2021-01-15 at 09:47 -0800, Larry Hastings wrote:
> 
> On 1/11/21 6:34 PM, Paul Bryan wrote:
> 
> On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote:
> 
> 
> > On 1/11/21 5:02 PM, Paul Bryan wrote:
> > 
> 
> > 
> > > I'm probably naive, but is there a reason that one could not just
> > > store a callable in __annotations__, and use the descriptor to
> > > resolve it to a dictionary and store it when it is accessed? It
> > > would be one less dunder in the Python data model.
> > That would work, but I think the API is a bit of a code smell. 
> > __annotations__ would no longer be stable:
> > 
> > > a.__annotations__ = o
> > > assert a.__annotations__ == o
> > Would that assert fail?  It depends on what type(o) is, which is
> > surprising.
> 
> Equally surprising?:
> 
> a.__co_annotations__ = o
> a.__annotations__
> assert a.__co_annotations__ == o
> 
> I've ruminated about this a bit over the past few days, and I finally
> realized exactly why, yes, I think behavior is more surprising.  It's
> because __annotations__ is now 12 years old (!), and never in that
> entire time has it silently changed its value.  It's always been
> completely stable, and we have twelve years' worth of installed base
> that may rely on that assumption.  In comparison, __co_annotations__
> is a new attribute.  While it's also surprising that
> __co_annotations__ can be automatically unset, at least this would be
> a documented part of its behavior from day 1.
> Relatedly, __co_annotations__ is behaving somewhat like a cached
> value, in that cached values get deleted when they're out-of-date. 
> (An observation that may provide some guidance if we decide to rename
> __co_annotations__.)  This idiom may be familiar to the user--unlike
> your proposed semantics, which I don't recall ever seeing used in an
> API.
> I admit it's only a small difference between what you proposed and
> what I propose, but in the end I definitely prefer my approach.
> Cheers,
> 
> /arry

___
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/AV6JRZZDDN4GAPE5MHRFEBFUY3TEO7VZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 caused by a to get_type_hints
> > instead of (mysteriously) occurring on an attempt to getattr
> > __annotations__.
> 
> I would say: absolutely not.  While all "type hints" are annotations,
> not all annotations are "type hints".  As mentioned previously in
> this thread, typing.get_type_hints() is opinionated in ways that
> users of annotations may not want.  And personally I bristle at the
> idea of gating a language feature behind a library function.
> Besides, most users will never know or care about
> __co_annotations__.  If you're not even aware that it exists, it's
> not mysterious ;-)
> 
> Cheers,
> 
> /arry

___
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/C3HINI65UIFCA4EON55WMR6YR6THXQCQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Paul Bryan via Python-Dev]

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 Ewing wrote:
> On 16/01/21 7:56 am, Larry Hastings wrote:
> > 
> > As mentioned previously in this 
> > thread, typing.get_type_hints() is opinionated in ways that users
> > of 
> > annotations may not want.
> 
> This brings us back to my idea of introducing a new
> annotations() function to hide the details. It wouldn't
> be the same as get_type_hints(), since it wouldn't make
> any assumptions about what the annotations mean.
> 

___
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/457EYGAJAE4BQHUWH32MRZNSLFGNR6MM/
Code of Conduct: http://python.org/psf/codeofconduct/