Mailing List Archive

> How about having a pseudo-module called __typing__ that is
> ignored by the compiler:
>
> from __typing__ import ...
>
> would be compiled to a no-op, but recognised by type checkers.

If you want to do run-time typing stuff, you would use
There is already a way of doing that: `if typing.TYPE_CHECKING: ...` https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
But yes, the issue with it is that this constant is defined in the `typing` module …

However, I think this is a part of the solution. Indeed, the language could define another builtin constants, let's name it `__static__`, which would simply be always false (at runtime), while linters/type checkers would use it the same way `typing.TYPE_CHECKING` is used:
```python
if __static__:
import typing
import expensive_module
```
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/ORL4B4RISFYIROSPGL4B4AVNWEOXP2TS/
Code of Conduct: http://python.org/psf/codeofconduct/

By the way, without adding an other constant, `__debug__` can also be used. It discards runtime overhead when it matters, in optimized mode.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/FSNLQARSUQ3DP4X3DD4UMEK2TAIUNJHD/
Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez <joperez@hotmail.fr> wrote:
>
> > How about having a pseudo-module called __typing__ that is
> > ignored by the compiler:
> >
> > from __typing__ import ...
> >
> > would be compiled to a no-op, but recognised by type checkers.
>
> If you want to do run-time typing stuff, you would use
> There is already a way of doing that: `if typing.TYPE_CHECKING: ...` https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
> But yes, the issue with it is that this constant is defined in the `typing` module …
>
> However, I think this is a part of the solution. Indeed, the language could define another builtin constants, let's name it `__static__`, which would simply be always false (at runtime), while linters/type checkers would use it the same way `typing.TYPE_CHECKING` is used:
> ```python
> if __static__:
> import typing
> import expensive_module
> ```


Please note that this is a thread about PEP 649.

If PEP 649 accepted and PEP 563 dies, all such idioms breaks
annotation completely.

Users need to import all heavy modules and circular references used
only type hints, or user can not get even string form annotation which
is very useful for REPLs.


--
Inada Naoki <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GB5ZD2OQ5XALMZX46DK3HWVV7ROZJHH2/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Feb 14, 2021 at 7:17 PM Inada Naoki <songofacandy@gmail.com> wrote:

> On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez <joperez@hotmail.fr> wrote:
> >
> > > How about having a pseudo-module called __typing__ that is
> > > ignored by the compiler:
> > >
> > > from __typing__ import ...
> > >
> > > would be compiled to a no-op, but recognised by type checkers.
> >
> > If you want to do run-time typing stuff, you would use
> > There is already a way of doing that: `if typing.TYPE_CHECKING: ...`
> https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
> > But yes, the issue with it is that this constant is defined in the
> `typing` module …
> >
> > However, I think this is a part of the solution. Indeed, the language
> could define another builtin constants, let's name it `__static__`, which
> would simply be always false (at runtime), while linters/type checkers
> would use it the same way `typing.TYPE_CHECKING` is used:
> > ```python
> > if __static__:
> > import typing
> > import expensive_module
> > ```
>
>
> Please note that this is a thread about PEP 649.
>
> If PEP 649 accepted and PEP 563 dies, all such idioms breaks
> annotation completely.
>
> Users need to import all heavy modules and circular references used
> only type hints, or user can not get even string form annotation which
> is very useful for REPLs.
>

Hm, that's a rather serious problem with Larry's PEP 649 compared to `from
__future__ import annotations`, actually.

Larry, what do you think?

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

I don't work on these sorts of codebases, and I don't use type hints or
static type checking.  So I'm not really qualified to judge how bad /
widespread a problem this is.  It's my hope that the greater Python core
dev / user community can ascertain how serious this is.

My main observation is that, for users facing this problem, they still
have options.  Off the top of my head, they could:

* maintain a lightweight "mock" version of expensive_module, or
* stringize their type hints by hand, or
* perhaps use with some hypothetical stringizing support library that
makes it less-painful to maintain stringized annotations.

(I assume that static type checkers could continue to support stringized
type hints even if PEP 649 was accepted.)

I admit I'd be very surprised if PEP 649 was judged to be unworkable,
given how similar it is to stock Python semantics for annotations at
runtime.


Cheers,


//arry/

On 2/15/21 8:14 PM, Guido van Rossum wrote:
> On Sun, Feb 14, 2021 at 7:17 PM Inada Naoki <songofacandy@gmail.com
> <mailto:songofacandy@gmail.com>> wrote:
>
> On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez <joperez@hotmail.fr
> <mailto:joperez@hotmail.fr>> wrote:
> >
> > > How about having a pseudo-module called __typing__ that is
> > > ignored by the compiler:
> > >
> > > from __typing__ import ...
> > >
> > > would be compiled to a no-op, but recognised by type checkers.
> >
> > If you want to do run-time typing stuff, you would use
> > There is already a way of doing that: `if typing.TYPE_CHECKING:
> ...`
> https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
> <https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING>
> > But yes, the issue with it is that this constant is defined in
> the `typing` module …
> >
> > However, I think this is a part of the solution. Indeed, the
> language could define another builtin constants, let's name it
> `__static__`, which would simply be always false (at runtime),
> while linters/type checkers would use it the same way
> `typing.TYPE_CHECKING` is used:
> > ```python
> > if __static__:
> >     import typing
> >     import expensive_module
> > ```
>
>
> Please note that this is a thread about PEP 649.
>
> If PEP 649 accepted and PEP 563 dies, all such idioms breaks
> annotation completely.
>
> Users need to import all heavy modules and circular references used
> only type hints, or user can not get even string form annotation which
> is very useful for REPLs.
>
>
> Hm, that's a rather serious problem with Larry's PEP 649 compared to
> `from __future__ import annotations`, actually.
>
> Larry, what do you think?
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

> Please note that this is a thread about PEP 649.
>
> If PEP 649 accepted and PEP 563 dies, all such idioms breaks
annotation completely.
>
> Users need to import all heavy modules and circular references used
only type hints, or user can not get even string form annotation which
is very useful for REPLs.

I don't see why `if TYPE_CHECKING:` idiom breaks annotations with PEP 649. There will be no error as long as `__annotations__` descriptor is not called.
And currently in 3.9 (with or without `from __future__ import annotations`), the issue is the same: you `get_type_hints` fails if some of the types in the annotations have been imported in a `if TYPE_CHECKING:` block.

> Hm, that's a rather serious problem with Larry's PEP 649 compared to from
__future__ import annotations, actually.

As I've written above, this is not a new issue, and neither this PEP nor PEP 563 can fix it.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/PVPCJV6GATMRACXIPPNSNCUV7OFGDEU3/
Code of Conduct: http://python.org/psf/codeofconduct/

It is an issue if you use `__annotations__` directly and you are using PEP
563's `from __future__ import annotations`. This currently gives some
strings that may or may not refer to existing globals. With Larry's PEP 649
it will raise an error.

On Tue, Feb 16, 2021 at 9:35 AM Joseph Perez <joperez@hotmail.fr> wrote:

> > Please note that this is a thread about PEP 649.
> >
> > If PEP 649 accepted and PEP 563 dies, all such idioms breaks
> annotation completely.
> >
> > Users need to import all heavy modules and circular references used
> only type hints, or user can not get even string form annotation which
> is very useful for REPLs.
>
> I don't see why `if TYPE_CHECKING:` idiom breaks annotations with PEP 649.
> There will be no error as long as `__annotations__` descriptor is not
> called.
> And currently in 3.9 (with or without `from __future__ import
> annotations`), the issue is the same: you `get_type_hints` fails if some of
> the types in the annotations have been imported in a `if TYPE_CHECKING:`
> block.
>
> > Hm, that's a rather serious problem with Larry's PEP 649 compared to from
> __future__ import annotations, actually.
>
> As I've written above, this is not a new issue, and neither this PEP nor
> PEP 563 can fix it.
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/PVPCJV6GATMRACXIPPNSNCUV7OFGDEU3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

If I've understood the PEP correctly, it would cause the following simple example to fail:
```python
from dataclasses import dataclass

@dataclass
class User:
name: str
friends: list[User]
```
In fact, when the `dataclass` decorator is called, `User` class is not yet added to the module namespace, so when class `__annotations__` descriptor will be called inside the decorator, it will raise a `NameError` because of `friends` recursive annotation.

By the way, in the example given by the PEP:
```python
def foo(x: int = 3, y: MyType = None) -> float:
...
class MyType:
...
```
if `foo` is decorated with a decorator calling `__annotations__` or `get_type_hints`, it will fail too.

Using stringified annotations would prevent `NameError` to be raised, but it really mitigates the PEP claim that
> This PEP also solves the forward reference problem

Not only this PEP doesn't solve (again, if I understand it correctly) the forward reference problem, but also it makes it a lot more tricky. And I think my first example is not so uncommon.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/CDCDXBKQF6ALDEM4EEUGEK654XOKJG3I/
Code of Conduct: http://python.org/psf/codeofconduct/

PEP 649 doesn't prevent to use stringified annotations (Larry has previously mentioned it in its response to Paul Bryan), and they seem to be still required when `if TYPE_CHECKING:` is used, despite the PEP claim.

And my last message bring some use cases where strings are also required (notably, in recursive dataclasses).
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/7QA3Z4CNYHW3GOEDAST6WW37O5OUJRW6/
Code of Conduct: http://python.org/psf/codeofconduct/

I certainly wouldn't want to keep `from __future__ import annotations` in
the language forever if Larry's PEP is accepted.

Of course you can still use explicit string literals in annotations.

Your observation about the @dataclass decorator is significant. Thanks for
that.

On Tue, Feb 16, 2021 at 10:36 AM Joseph Perez <joperez@hotmail.fr> wrote:

> PEP 649 doesn't prevent to use stringified annotations (Larry has
> previously mentioned it in its response to Paul Bryan), and they seem to be
> still required when `if TYPE_CHECKING:` is used, despite the PEP claim.
>
> And my last message bring some use cases where strings are also required
> (notably, in recursive dataclasses).
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/7QA3Z4CNYHW3GOEDAST6WW37O5OUJRW6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>