[Python-Dev] Re: The current state of typing PEPs
Steven D'Aprano writes: > I don't think that's what PEP 563 says. Annotations are not > *restricted* to only be strings, it is merely that when the > function or class object is built, the annotations are left as > strings. You're right, I was imprecise. I meant as PEP 563 is implemented now, I doubt it can handle non-strings nicely. > So we can post-process annotations and destringify them: True, but you face the dread "double-decode problem": if the annotation happens to destringify to a string, then the "post- processor" may try to destringify again. I guess we can mark each annotation as already destringified or not. As long as this is done by some sort of API, you're probably OK (but it makes me nervous since __annotations__ is completely exposed to the program, as in your example). > There may be scoping issues to be sorted out, but I don't think they are > insurmountable. But isn't there still the issue of forward reference, which motivates these PEPs in the first place? ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LX7EOMA7RPVJUTS5ADMLBIK2CZN2TMLQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote: > > My memory is also hazy, but I'm quite sure that *in my mind* annotations were > intended as a compromise between conflicting proposals for *typing*. We > didn't have agreement on the syntax or semantics, but we did know we wanted > to do something with types eventually. More hazy memories here, but I think the original proposal left open the possibility of annotations not being types at all - for example, being docstrings for the arguments, or option names for a "function call to CLI" tool, etc. I think that some libraries took this approach (in particular the "CLI builder" idea). At some point (probably around PEP 484) it became clear that the expectation was that annotations would be *types*, and in particular would be the expected/intended type of the annotated value. I think there was some discussion at that point about "what do we do about the CLI builders" but the conclusion was that they had relatively low adoption rates, and could adapt (or more accurately, abandon the annotation approach). That was the point, in my recollection, where the "annotations are for types" principle was established. However, I feel that many people got (or were given) the impression that static type checkers were the core use case (probably as a result of the emphasis on the message that "type annotations will never be mandatory"), for better or worse. I think that by now, it's long been understood by most people that annotations are types. This may actually be one reason why people are so uncomfortable with the idea of stringified annotations, because it violates that assumption - personally, I have the same discomfort about using explicit string annotations for forward references, it feels like I'm not declaring a "proper type". If what I say above is right, the debate here isn't about whether annotations "are for types", but rather about whether reading the types in annotations and using them to affect behaviour *at runtime* is a legitimate use of annotations. That is the use case that stringifying annotations makes more difficult, and which doesn't seem to have a strong enough voice in the direction of typing proposals. I lurk on the typing-sig, and from an outsider's perspective, the participants seem to be almost entirely designers or heavy users of static type checkers. That gives a certain emphasis to the proposals coming from that group. I'd therefore interpret Barry's plea as being for *anyone* with a use for annotations to provide their feedback (at least, anyone who accepts that annotations are types), with particular emphasis on people who want to use the types declared in annotations to affect runtime behaviour, as that's the most under-represented group at the moment (and it's not clear whether it's under-represented because there aren't many such uses, or because the users aren't being heard from). Paul ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5N5GTSWQPVALCTJDWZ4G4JSBPDS6324V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Thu, 25 Nov 2021 at 21:45, Christopher Barker wrote:
> The issue is that, intended or not, typing is making it's way into Python
> culture. As an instructor of beginning python users, I am unsure at this
> point when to introduce type annotations.
>
> What is their role? Up to today, I have treated them as an advanced feature,
> useful for "complex codebases". But there are any number of examples
> springing up on the internet, to the point where many students now think they
> are "best practice", if not actually required.
Agreed this is somewhat OT, but I also think the messaging around
annotations needs to be reviewed. I suspect that students will also
not clearly understand the fact that annotations aren't checked at
runtime. And IMO this is particularly difficult to get across in the
case of non-typechecker uses of annotations.
The following, for example, is extremely non-intuitive to me:
>>> from dataclasses import dataclass
>>>
>>> @dataclass
... class A:
... n: int
...
>>> a = A("didn't expect this!")
>>> a
A(n="didn't expect this!")
Even though the "typing is optional" message is well-understood, my
instincts still lead me to expect that declaring the type of n will
result in a runtime type-check, in the constructor at least. (If I
check the code with mypy, it does raise an error, so that's good.
Although the more I think about it, given that I believe dataclasses
use eval "under the hood", the less I understand *how* it manages to
do that without special-case knowledge of the dataclass decorator...)
I'd like to see a clearer statement from "somewhere" about how APIs
should use annotations at runtime, such that Python users have a much
clearer intuition about APIs like the dataclass one, and library
designers can build their APIs based on a clear "common understanding"
of what to expect when annotations are used.
Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/NBE7YL6EBVBB3NQ33DJI4KY3NSYL2Q5W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Am 26.11.21 um 01:48 schrieb Rob Cliffe via Python-Dev: ISTM that typing/annotations have been allowed to drift without a clear end in view, rather like a ship that is steered in one direction by one person, then in another by someone else, with nobody knowing what the destination port is. I believe the problem is less within the typing community itself (whether static or runtime), but a fundamental conflict between the typing community and what Stephen called the "typing-suspicious crowd". typing in Python has always been hampered by sometimes valid, often unfounded fears that typing is "taking over" and somehow becomes a requirement. For example, PEP 484 made no changes to Python or the stdlib, except the introduction of a new module, often to the detriment of readability and usability of type annotations. And while progress is made slowly (for example with generics in standard collections or the new callable syntax proposal), I'm sure the typing community would love to progress faster and with less obstacles. - Sebastian ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HC43AFLA2RCTBXZ3K5O2IIYGPCMYQXOX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Thu, 25 Nov 2021 23:51:58 + Oscar Benjamin wrote: > > > > Not a PEP proponent (or even a typing user), but I thought this had > > been made clear long ago. My understanding is that optional, > > incremental type hints are and have always been considered the primary > > use case for annotations by the BDFL and AFAICT the SC following the > > BDFL. If compatibility with typing is an issue, then the burden of > > implementing that is on the other application. Typing *might* do > > something to help, but it's not obligated to do so. > > This was not my understanding of annotations when they were introduced e.g.: > https://www.python.org/dev/peps/pep-3107/#use-cases > > As I remember it, a decision about the purpose of annotations was > *explicitly* not made when they were introduced. This is also what I remember from the discussions at the time of PEP 3107. Annotations were purposefully use case-agnostic, and there was no stated desire to push for one use case or another. I don't think gradual typing was even on the radar, not in public comments anyway. Regards Antoine. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DD2OTSIWZ3KMR6PDK3CSLOMDJQMQSUHL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Fri, Nov 26, 2021 at 1:37 AM Paul Moore wrote:
> On Thu, 25 Nov 2021 at 21:45, Christopher Barker
> wrote:
> > The issue is that, intended or not, typing is making it's way into
> Python culture. As an instructor of beginning python users, I am unsure at
> this point when to introduce type annotations.
> >
> > What is their role? Up to today, I have treated them as an advanced
> feature, useful for "complex codebases". But there are any number of
> examples springing up on the internet, to the point where many students now
> think they are "best practice", if not actually required.
>
> Agreed this is somewhat OT, but I also think the messaging around
> annotations needs to be reviewed. I suspect that students will also
> not clearly understand the fact that annotations aren't checked at
> runtime. And IMO this is particularly difficult to get across in the
> case of non-typechecker uses of annotations.
>
> The following, for example, is extremely non-intuitive to me:
>
> >>> from dataclasses import dataclass
> >>>
> >>> @dataclass
> ... class A:
> ... n: int
> ...
> >>> a = A("didn't expect this!")
> >>> a
> A(n="didn't expect this!")
>
> Even though the "typing is optional" message is well-understood, my
> instincts still lead me to expect that declaring the type of n will
> result in a runtime type-check, in the constructor at least. (If I
> check the code with mypy, it does raise an error, so that's good.
> Although the more I think about it, given that I believe dataclasses
> use eval "under the hood", the less I understand *how* it manages to
> do that without special-case knowledge of the dataclass decorator...)
>
Static checkers special-case the @dataclass decorator. Eric Traut has a
proposal to generalize this support (sorry, I'm in a rush, otherwise I'd
dig up the link, but it's in the typing-sig archives).
> I'd like to see a clearer statement from "somewhere" about how APIs
> should use annotations at runtime, such that Python users have a much
> clearer intuition about APIs like the dataclass one, and library
> designers can build their APIs based on a clear "common understanding"
> of what to expect when annotations are used.
>
Note that @dataclass itself is very careful not to use the annotations, it
only looks for their *presence*. With one exception for ClassVar.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-11-19 - 2021-11-26) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7266 (-24) closed 50367 (+81) total 57633 (+57) Open issues with patches: 2879 Issues opened (36) == #45774: Detect SQLite in configure.ac https://bugs.python.org/issue45774 reopened by erlendaasland #45853: Misspelled _IGNORED_ERROS in Lib/pathlib.py https://bugs.python.org/issue45853 opened by andrei.avk #45854: winreg: implement RegGetValue https://bugs.python.org/issue45854 opened by imba-tjd #45855: PyCapsule_Import still using PyImport_ImportModuleNoBlock https://bugs.python.org/issue45855 opened by georg.brandl #45857: PEP 604 Union syntax does not support forward references https://bugs.python.org/issue45857 opened by TNThung #45858: Deprecate default converters in sqlite3 https://bugs.python.org/issue45858 opened by iafisher #45860: UnboundLocalError leads to Illegal instruction crashing CPytho https://bugs.python.org/issue45860 opened by xxm #45863: tarfile zeroes ustar header fields unnecessarily https://bugs.python.org/issue45863 opened by jmr #45868: xattr support missing in os module under cygwin https://bugs.python.org/issue45868 opened by enok2 #45869: Unicode and acii regular expressions do not agree on ascii spa https://bugs.python.org/issue45869 opened by control-k #45870: There's no readline module on Windows Python (cmd.Cmd) https://bugs.python.org/issue45870 opened by keeely #45872: Turtle documentation, write() https://bugs.python.org/issue45872 opened by willyns #45874: urllib.parse.parse_qsl does not parse empty query string with https://bugs.python.org/issue45874 opened by sattler #45875: gzip.decompress performance can be improved with memoryviews https://bugs.python.org/issue45875 opened by rhpvorderman #45876: Improve accuracy of stdev functions in statistics https://bugs.python.org/issue45876 opened by rhettinger #45877: Inconsistency in minimal supported version of Microsoft Visual https://bugs.python.org/issue45877 opened by arhadthedev #45878: Use `self.assertRaises` instead of `try/except` in `ctypes/tes https://bugs.python.org/issue45878 opened by sobolevn #45879: Access violation https://bugs.python.org/issue45879 opened by vladexl #45881: Cross compiling on Linux is untested, undocumented, and broken https://bugs.python.org/issue45881 opened by christian.heimes #45882: mailbox fails to read message from mbox https://bugs.python.org/issue45882 opened by peter.wurmsdobler #45883: reuse_address mistakenly removed from loop.create_server https://bugs.python.org/issue45883 opened by jcristharif #45885: Specialize COMPARE_OP https://bugs.python.org/issue45885 opened by Dennis Sweeney #45886: Fix Program/_freeze_module for cross compiling Python https://bugs.python.org/issue45886 opened by christian.heimes #45887: [subinterpreters] Pull all interpreter-global objects into one https://bugs.python.org/issue45887 opened by eric.snow #45888: Revisit: start_tls() difficult when using asyncio.start_server https://bugs.python.org/issue45888 opened by rob-blackbourn #45889: pathlib: Path.match does not work on paths https://bugs.python.org/issue45889 opened by nickpapior #45890: Add tests for tracing try-except-finally blocks https://bugs.python.org/issue45890 opened by iritkatriel #45894: exception lost when loop.stop() in finally https://bugs.python.org/issue45894 opened by Amos.Anderson #45896: Conflicting statements in docs about default support for async https://bugs.python.org/issue45896 opened by Rob4226 #45897: Frozen dataclasses with slots raise TypeError https://bugs.python.org/issue45897 opened by trey #45898: ctypes cfield.c defines duplicate ffi_type_* symbols https://bugs.python.org/issue45898 opened by christian.heimes #45901: store app file type ignores command-line arguments https://bugs.python.org/issue45901 opened by eryksun #45902: Bytes and bytesarrays can be sorted with a much faster count s https://bugs.python.org/issue45902 opened by rhpvorderman #45903: What???s New In Python 3.11: wrong reference to Signature.from https://bugs.python.org/issue45903 opened by jwilk #45904: Pasting the U00FF character into Python REPL misinterprets cha https://bugs.python.org/issue45904 opened by gwk #45905: Provide a C API for introspectable frames for Cython and simil https://bugs.python.org/issue45905 opened by Mark.Shannon Most recent 15 issues with no replies (15) == #45905: Provide a C API for introspectable frames for Cython and simil https://bugs.python.org/issue45905 #45903: What???s New In Python 3.11: wrong reference to Signature.from https://bugs.python.org/issue45903 #45901: store app file type ignores command-line arguments https://bugs.python.org/issue45901 #45890: Add tests for tracing try-exc
[Python-Dev] Re: The current state of typing PEPs
On Fri, 26 Nov 2021 at 17:13, Guido van Rossum wrote: >> Although the more I think about it, given that I believe dataclasses >> use eval "under the hood", the less I understand *how* it manages to >> do that without special-case knowledge of the dataclass decorator...) > > Static checkers special-case the @dataclass decorator. Eric Traut has a > proposal to generalize this support (sorry, I'm in a rush, otherwise I'd dig > up the link, but it's in the typing-sig archives). :-( That's what I suspected, but it does mean that dataclasses has a privilege that other libraries (like attrs, I guess?) don't get. >> I'd like to see a clearer statement from "somewhere" about how APIs >> should use annotations at runtime, such that Python users have a much >> clearer intuition about APIs like the dataclass one, and library >> designers can build their APIs based on a clear "common understanding" >> of what to expect when annotations are used. > > Note that @dataclass itself is very careful not to use the annotations, it > only looks for their *presence*. With one exception for ClassVar. Understood. What I'm suggesting is that it would be good to have a clear "common understanding" about whether libraries should be careful like this, or whether it's OK to base runtime behaviour on type annotations. And if it is OK, then what are good patterns of design and behaviour? This is where the proposal to store annotations as strings hit issues, because it appears to take the view that libraries *shouldn't* be looking at the actual types specified by annotations (or maybe that they should only do so via something like `typing.get_type_hints`). There are other subtleties here (runtime code needs to deal with the fact that int and "int" should be treated the same) that there's no guidance on, again possibly because no-one is really considering that use case. Paul PS I've never written code myself that does runtime introspection of type annotations - so it's quite possible that there *is* guidance that I've just missed. But it wasn't obvious to me from a quick search - the "introspection helpers" section of the typing module docs is pretty basic... ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/Y4WTMMHZ5XR6PCPKRP4FTIX4R2YJCS7L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Fri, Nov 26, 2021 at 11:58 AM Paul Moore wrote: > On Fri, 26 Nov 2021 at 17:13, Guido van Rossum wrote: > > >> Although the more I think about it, given that I believe dataclasses > >> use eval "under the hood", the less I understand *how* it manages to > >> do that without special-case knowledge of the dataclass decorator...) > > > > Static checkers special-case the @dataclass decorator. Eric Traut has a > proposal to generalize this support (sorry, I'm in a rush, otherwise I'd > dig up the link, but it's in the typing-sig archives). > > :-( That's what I suspected, but it does mean that dataclasses has a > privilege that other libraries (like attrs, I guess?) don't get. > Actually both are done through plugins (since what they do just doesn't fit in the PEP 484 type system) and both have the same status, at least in mypy. (In fact we have twice as many lines of code dedicated to attrs than to dataclasses. https://github.com/python/mypy/tree/master/mypy/plugins) The proposal I mentioned by Eric Traut (pyright's author) would make it easier to support many similar libraries across all static type checkers. ( https://mail.python.org/archives/list/[email protected]/thread/TXL5LEHYX5ZJAZPZ7YHZU7MVFXMVUVWL/ ) > >> I'd like to see a clearer statement from "somewhere" about how APIs > >> should use annotations at runtime, such that Python users have a much > >> clearer intuition about APIs like the dataclass one, and library > >> designers can build their APIs based on a clear "common understanding" > >> of what to expect when annotations are used. > > > > Note that @dataclass itself is very careful not to use the annotations, > it only looks for their *presence*. With one exception for ClassVar. > > Understood. What I'm suggesting is that it would be good to have a > clear "common understanding" about whether libraries should be careful > like this, or whether it's OK to base runtime behaviour on type > annotations. And if it is OK, then what are good patterns of design > and behaviour? This is where the proposal to store annotations as > strings hit issues, because it appears to take the view that libraries > *shouldn't* be looking at the actual types specified by annotations > (or maybe that they should only do so via something like > `typing.get_type_hints`). There are other subtleties here (runtime > code needs to deal with the fact that int and "int" should be treated > the same) that there's no guidance on, again possibly because no-one > is really considering that use case. > You are hitting the nail on the head here. I'd say that so far the recommendation has been "use typing.get_type_hints(x) rather than x.__annotations__" -- this handles the equivalence between int and "int" (and hence forward references as well as 'from __future__ import annotations'). There's now also inspect.get_annotations() which has roughly the same functionality without quite so much bias towards typing, so perhaps we should recommend it over typing.get_type_hints() -- though before 3.10 inspect.get_annotations() didn't exist so you might have to fall back on using the other. (There are some semantic differences between the two that I'm glossing over here, because I'm not sure about what exactly they are. :-) We now also have a document that recommends best practices ( https://docs.python.org/3/howto/annotations.html) although it's very new -- it appears Larry Hastings wrote it while he was pushing for PEP 649 (but it received buy-in from the static typing community as well). So perhaps it isn't as bad as it seems, *if* you know where to look? That said, I don't think the current static typing infrastructure would be prepared for an onslaught of modules that use type introspection at runtime to modify the behavior of classes a la attrs and dataclasses. I don't know enough about pydantic to say whether it also falls in this category. But it's definitely difficult to write code that makes use of type annotations at runtime that *also* passes static type checks by mypy etc.; you certainly shouldn't attempt to do so without having CI jobs to run the static checker and test the runtime-introspecting framework you're using. (It's not quite like trying to write code that's valid Python and Fortran at the same time, but it's not trivial. :-) There are also features of our static type system that tend not to be supported by the runtime-introspecting frameworks -- in particular, I'd expect generics and callable types to be hard to deal with at runtime. It's easy enough to do something at runtime with `def f(a: list[int]) -> int`. It's not so simple to handle `def f(a: Sequence[T]) -> T` or `def f(cb: (T) -> tuple[str, T], Sequence[T]) -> Mapping[str, T]`. Presumably frameworks like pydantic just don't support such things and tell the user not to do that. (Someone should look where pydantic draws the line and report back here.) > > Paul > > PS I've never written code myself that does runtime introspection of > type ann
[Python-Dev] Re: The current state of typing PEPs
> There may > be scoping issues to be sorted out, > Yes, the scoping issues are the main problem. > > but I don't think they are > > insurmountable. Probably not — and LLukas Langa has some good ideas that the SC is considering. (Sorry I can’t get your name right in a phone) Maybe inspect.get_annotations() does, or will be able to, solve many of these issues. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/Z74WROINRFUWXNLDSC4WYBSRCHHDNJSC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On Fri, Nov 26, 2021 at 1:47 PM Guido van Rossum wrote > It's easy enough to do something at runtime with `def f(a: list[int]) -> int`. It's not so simple to handle `def f(a: Sequence[T]) -> T` or `def f(cb: (T) -> tuple[str, T], Sequence[T]) -> Mapping[str, T]`. Presumably frameworks like pydantic just don't support such things and tell the user not to do that. I don’t know about Pydantic, but that’s exactly my use case: the type needs to be an actual intstantiatable type. So list and tuple is fine, and Sequence[t] won’t work. But it’s fine that this use case is restricted. In fact, other than the basic core types, you need to use specialized types with this system anyway. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CFRHK622JYFQ3MD6UBTAUS3UDY2UQ52F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
So does your library work both with and without ‘from __future__ import annotations’? If it does, you shouldn’t have to worry. If it doesn’t, it would be useful if you could post some detailed examples of what goes wrong. On Fri, Nov 26, 2021 at 14:24 Christopher Barker wrote: > > > On Fri, Nov 26, 2021 at 1:47 PM Guido van Rossum wrote > > It's easy enough to do something at runtime with `def f(a: list[int]) > -> int`. It's not so simple to handle `def f(a: Sequence[T]) -> T` or `def > f(cb: (T) -> tuple[str, T], Sequence[T]) -> Mapping[str, T]`. Presumably > frameworks like pydantic just don't support such things and tell the user > not to do that. > > I don’t know about Pydantic, but that’s exactly my use case: the type > needs to be an actual intstantiatable type. > > So list and tuple is fine, and Sequence[t] won’t work. But it’s fine > that this use case is restricted. > > In fact, other than the basic core types, you need to use specialized > types with this system anyway. > > -CHB > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- --Guido (mobile) ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KQDOEO7CIDIFG6N26EYRYUSRW4UYPRZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Paul Moore wrote: > More hazy memories here, but I think the original proposal left open > the possibility of annotations not being types at all - for example, > being docstrings for the arguments, or option names for a "function > call to CLI" tool, etc. Absolutely. While it was clear that Guido's own use cases were about typing, annotations were explicitly not limited to typing, which is one reason why some of the later changes have felt to some people like bait and switch. Maybe it is already too late to avoid that. > ... the expectation was that annotations > would be *types*, Even from the start, it was assumed that they would be objects. (Specifically types was expected to be common, but not universal.) The particular way strings are being substituted for evaluated objects has sometimes reminded me of raising a string instead of an exception class/object. It will work, but it can seem sloppy, and it can be annoying if you were assuming otherwise and suddenly have to add a bunch of evals. (That said, I haven't yet been sufficiently motivated to even tease out exactly what the problems are, let alone to propose an alternative that also satisfies the typing fans -- in part because it feels like the obvious optimization is to just not run typing, and it isn't clear what middle grounds are generally worthwhile.) >... personally, I have the same discomfort > about using explicit string annotations for forward references, it > feels like I'm not declaring a "proper type". > If what I say above is right, the debate here isn't about whether > annotations "are for types", but rather about whether reading the > types in annotations and using them to affect behaviour *at runtime* > is a legitimate use of annotations. I see that as a second dispute, which I had previously missed. I think you're right, though. On the other hand, I'm not sure the solution to both isn't just a helper function that does the 2nd-pass resolution -- preferably without requiring that all the rest of typing be imported, since even the people who want to use the typing package agree that importing it is not lightweight. > ... I lurk on the typing-sig, and from an outsider's perspective, the > participants seem to be almost entirely designers or heavy users of > static type checkers. That gives a certain emphasis to the proposals > coming from that group. At times, it sort of reminds me of OWL and "Semantic Web". There are plenty of people who will want to use annotations as a tool, but won't be willing to wade through what can feel like "How many angels can dance on the head of a pin?" discussions. That said, I'm not sure how to best reach people who just want a rough-and-ready usually-good-enough tool. -jJ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JL3AQ4UVEVWXYTRFAVGVHNT23W2NCUDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Steven D'Aprano wrote: > On Sat, Nov 20, 2021 at 11:46:56PM -0800, Christopher Barker wrote: > Maybe PEP 563 could include a decorator in the typing module to > destringify all the annotations in a class or function? If it were in an annotations module, that would probably be sufficient. If it is in typing, then it is a very heavyweight dependency -- heavy enough that even the people actually using that module for development (and not for production runs) are worried about the costs. If the costs of the typing module are that high, it is not acceptable to impose them on people not otherwise using the module. -jJ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ZQHP24T2PKRTDBGZ36KLBHLLOKITP5ON/ Code of Conduct: http://python.org/psf/codeofconduct/
