[Python-Dev] Re: The current state of typing PEPs

On Fri, 3 Dec 2021 at 00:10, Shantanu Jain wrote: > > @Paul > > > ... missing resource is a central set of typing documentation that includes > > examples, FAQs and best practices as well as reference materials > > Like Sebastian, I agree, and this is something we're making progress on. That's

[Python-Dev] Re: The current state of typing PEPs

On Thu, Dec 2, 2021 at 6:57 PM Stephan Richter wrote: > So maybe this is my time to chime in. I have used annotations for runtime > behavior. My primary use case is an injection library that I wrote. Does it work with __future__ annotations? -CHB > It allows > something along the lines

[Python-Dev] Re: The current state of typing PEPs

So maybe this is my time to chime in. I have used annotations for runtime behavior. My primary use case is an injection library that I wrote. It allows something along the lines of: class IMyService(IService): pass @inject def call_something(arg1: str, arg2: int, svc: IMyService = None):

[Python-Dev] Re: The current state of typing PEPs

On Thu, Dec 2, 2021 at 3:35 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I assume you accidentally pressed Send prematurely. > Actually, it was my phone making the text white -- what the heck? why is it so hard to send plain text email? resent now. -CHB > Still, maybe you

[Python-Dev] Re: The current state of typing PEPs

resent -- damn iPhone! On Thu, Dec 2, 2021 at 3:20 PM Christopher Barker wrote: > >for library authors. > > > > Providing high quality stubs and the best user experience is not easy. > > But I believe that referring people to typeshed can help. > > > This is actually very helpful. It provides

[Python-Dev] Re: The current state of typing PEPs

@Paul > ... missing resource is a central set of typing documentation that includes examples, FAQs and best practices as well as reference materials Like Sebastian, I agree, and this is something we're making progress on. > ... easy way of testing that the stubs are correct mypy ships with a

[Python-Dev] Re: The current state of typing PEPs

I assume you accidentally pressed Send prematurely. Still, maybe you have inadvertently listed everything that is agreed about typing PEPs.  Rob Cliffe On 02/12/2021 23:20, Christopher Barker wrote: >for library authors. Providing high quality stubs and the best user experience is not

[Python-Dev] Re: The current state of typing PEPs

>for library authors. > Providing high quality stubs and the best user experience is not easy. > But I believe that referring people to typeshed can help. This is actually very helpful. It provides an answer for open source projects for which do users want typing. One can say to the users that

[Python-Dev] Re: The current state of typing PEPs

Am 01.12.21 um 13:36 schrieb Paul Moore: On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau wrote: Please note that users of you library usually won't care that the library uses type hints. It's more important that there are type hints for the API, which can also be supplied using a stub file.

[Python-Dev] Re: The current state of typing PEPs

On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano wrote: > On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote: > [...] > Aside: I'm a little disappointed in the way the typing ecosystem has > developed. What I understood was that we'd get type inference like ML or > Haskell use, so we

[Python-Dev] Re: The current state of typing PEPs

On Wed, 1 Dec 2021 at 12:12, Sebastian Rittau wrote: > > Am 30.11.21 um 13:39 schrieb Oscar Benjamin: > >> Others have mentioned the pressure on libraries to adopt typing and >> I've certainly noticed this with SymPy. I think type hints could be >> good for SymPy for internal use but it seems

[Python-Dev] Re: The current state of typing PEPs

On 2021-11-30 09:01, Steven D'Aprano wrote: Heh. We could update PEP 8 to ban type annotations, then watch as the people who over-zealously apply PEP 8 to everything AND over-zealously insist on adding type annotations to everything have their heads explode. Captain Kirk would be proud:

[Python-Dev] Re: The current state of typing PEPs

On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau wrote: > Please note that users of you library usually won't care that the library > uses type hints. It's more important that there are type hints for the API, > which can also be supplied using a stub file. I tried that route, but I was informed

[Python-Dev] Re: The current state of typing PEPs

Am 30.11.21 um 13:39 schrieb Oscar Benjamin: Others have mentioned the pressure on libraries to adopt typing and I've certainly noticed this with SymPy. I think type hints could be good for SymPy for internal use but it seems that a lot of users want it for external reasons that I don't always

[Python-Dev] Re: The current state of typing PEPs

On 11/26/21 1:13 AM, Paul Moore wrote: > 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

[Python-Dev] Re: The current state of typing PEPs

This is great Patrick, thanks. My use case is similar to Patrick's, except it builds on dataclasses directly: It's part of a larger system, but I've just pulled it out into its own poorly documented and poorly tested package: https://github.com/PythonCHB/flexi (I think it's generally useful,

[Python-Dev] Re: The current state of typing PEPs

On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote: > And to be clear, it's often very non-obvious how to annotate something > - in https://github.com/pfmoore/editables I basically gave up because > I couldn't work out how to write a maintainable annotation for an > argument that is "a

[Python-Dev] Re: The current state of typing PEPs

On Fri, 26 Nov 2021 at 09:14, Paul Moore wrote: > 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

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 12:39, Oscar Benjamin wrote: > There are other open "issues" like this for SymPy where the > presumption is that not having type hints is now to be considered a > deficiency of the library regardless of whether the hints have any > benefit for internal use. I don't object

[Python-Dev] Re: The current state of typing PEPs

On 29 Nov 2021, at 23:56, Barry Warsaw wrote: [...] (not that you're not allowed to use for anything else, of course you are, but that other uses won;t be taken into account when designing the new interface) But I have never seen that clearly stated anywhere. The closest is from PEP 563,

[Python-Dev] Re: The current state of typing PEPs

On Tue, Nov 30, 2021 at 09:17:13AM +, Paul Moore wrote: > Also, related to the question Terry raised, IMO it would be useful to > have a clear statement on code that *does* use type annotations, but > violates them at runtime. To be specific, is the following considered > as an error? > >

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 09:23, Paul Moore wrote: > > On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote: > > > > THAT'S the kind of thing that also has been happening with typing, and > > why some of us feel the need to publicly re-state things that are all > > agreed upon within this group, but are

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 09:37, Chris Angelico wrote: > > On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote: > > Also, related to the question Terry raised, IMO it would be useful to > > have a clear statement on code that *does* use type annotations, but > > violates them at runtime. To be

[Python-Dev] Re: The current state of typing PEPs

On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote: > Also, related to the question Terry raised, IMO it would be useful to > have a clear statement on code that *does* use type annotations, but > violates them at runtime. To be specific, is the following considered > as an error? > > >>> def

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote: > > THAT'S the kind of thing that also has been happening with typing, and > why some of us feel the need to publicly re-state things that are all > agreed upon within this group, but are struggling to be heard over the > public discourse on the

[Python-Dev] Re: The current state of typing PEPs

I don't think the issue of how typing is making its way intot he community is particular relevant to this thread, but I was directly asked a question, so I'll answer it: I don't know exactly where the impression is coming from that typing is a best practice, but it's certainly creeping into

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 7:10 PM, Inada Naoki wrote: Anyone against making a statement that "PEP 563 will never be the default behavior"? I think only the SC is empowered to make such a statement. Then, we do not need to decide "PEP 563 or 649". We can focus on whether we can replace "stock semantics +

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 8:17 PM Guido van Rossum wrote: > Why would it need to be reiterated? Are there really people who believe > that such code would become invalid? AFAIK *everybody* here agrees that > this should stay valid. So who would we be reiterating it for? > I'm certainly not alone,

[Python-Dev] Re: The current state of typing PEPs

On Thu, Nov 18, 2021 at 8:00 AM Barry Warsaw wrote: > > Does PEP 563 or 649 satisfy static and dynamic typing needs? > > In the interest of full transparency, we want to let the Python community > know that the Steering Council continues to discuss PEP 563 (Postponed > Evaluation of

[Python-Dev] Re: The current state of typing PEPs

On 11/30/2021 1:16 AM, Guido van Rossum wrote: Why would it need to be reiterated? Are there really people who believe that such code would become invalid? AFAIK *everybody* here agrees that this should stay valid. So who would we be reiterating it for? (Yes, several static type checkers have

[Python-Dev] Re: The current state of typing PEPs

On Nov 29, 2021, at 15:57, Larry Hastings wrote: > > On 11/29/21 2:56 PM, Barry Warsaw wrote: >> PEP 563 and 649 have visible effects that even within that domain can have >> important side effects. For example, PEP 563’s loss of local scope, which >> even “de-stringify-ing” can’t recover.

[Python-Dev] Re: The current state of typing PEPs

On 11/29/2021 8:16 PM, Guido van Rossum wrote: On Mon, Nov 29, 2021 at 5:01 PM Terry Reedy > wrote: On 11/29/2021 5:56 PM, Barry Warsaw wrote: > On Nov 25, 2021, at 13:41, Christopher Barker mailto:python...@gmail.com>> wrote: >> What is their role?

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 5:01 PM Terry Reedy wrote: > On 11/29/2021 5:56 PM, Barry Warsaw wrote: > > > On Nov 25, 2021, at 13:41, Christopher Barker > wrote: > >> What is their role? Up to today, I have treated them as an advanced > feature, useful for "complex codebases". But there are any

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 07:56:16PM -0500, Terry Reedy wrote: > Maybe it should be reiterated with whatever decision comes forth that > > >>> def muladd(x, y, z): > ... return x * (y+z) > ... [...] > and other duck-typed code will always be legal, idiomatic, and even > expected as good

[Python-Dev] Re: The current state of typing PEPs

On 11/29/2021 5:56 PM, Barry Warsaw wrote: On Nov 25, 2021, at 13:41, Christopher Barker wrote: 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

[Python-Dev] Re: The current state of typing PEPs

Here's a use case for runtime type annotations: dataclasses use annotations to define fields. With the exception of ClassVar, the actual type is ignored. There's code in dataclasses.py to deal with stringized annotations, specifically just looking for ClassVar. I'd like to see this special

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 2:56 PM, Barry Warsaw wrote: PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. Well, sure.  If PEP 563 and

[Python-Dev] Re: The current state of typing PEPs

I hope my understanding of where the SC’s debate about this currently sits isn’t a misrepresentation, but since I sent the email on behalf of the SC, let me try to clarify what I was trying to say. Aside: A little insight into how the SC works. For communications like this, after whatever

[Python-Dev] Re: The current state of typing PEPs

On Nov 26, 2021, at 01:13, Paul Moore wrote: > 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

[Python-Dev] Re: The current state of typing PEPs

On Fri, Nov 26, 2021 at 5:47 PM Jim J. Jewett wrote: > Steven D'Aprano 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Python-Dev] Re: The current state of typing PEPs

On Fri, Nov 26, 2021 at 12:15:10AM +0900, Stephen J. Turnbull wrote: > I will grant that restricting the type of compiled annotations from > typing.Any to "string serializing an object's AST" could reasonably be > said to be "going out of your way to break other use cases". You have > a valid

[Python-Dev] Re: The current state of typing PEPs

On Thu, Nov 25, 2021 at 3:49 PM Greg Ewing wrote: > On 26/11/21 4:15 am, Stephen J. Turnbull wrote: > > My understanding is that optional, > > incremental type hints are and have always been considered the primary > > use case for annotations by the BDFL > > I'm not sure that's true. The way I

[Python-Dev] Re: The current state of typing PEPs

My 2¢ from a position of *extreme ignorance*, not to mention zero interest in annotations (all welcome to shoot me down in flames, or treat me with contemptuous silence.  But *occasionall*y the "idiot's" point of view is worth considering, so here goes). ISTM that typing/annotations have been

[Python-Dev] Re: The current state of typing PEPs

On Thu, 25 Nov 2021 at 15:16, Stephen J. Turnbull wrote: > > Executive summary: > > The typing-suspicious crowd has a valid complaint about PEPs 563 and > 649, but it's not that they weren't warned. > > Christopher Barker writes: > > > Annotations can be, and are, used for other things than

[Python-Dev] Re: The current state of typing PEPs

On 26/11/21 4:15 am, Stephen J. Turnbull wrote: My understanding is that optional, incremental type hints are and have always been considered the primary use case for annotations by the BDFL I'm not sure that's true. The way I remember it, back when annotations were first introduced, the BDFL

[Python-Dev] Re: The current state of typing PEPs

First: At this point, I am not advocating anything in particular. I am just asking that the SC makes a clear statement about the intention at this point. >From Barry's email: """ This is also a call to you, the folks who both care deeply about typing in Python, and have a solid understanding of

[Python-Dev] Re: The current state of typing PEPs

On 25/11/2021 15:15, Stephen J. Turnbull wrote: Executive summary: The typing-suspicious crowd has a valid complaint about PEPs 563 and 649, but it's not that they weren't warned. “As you will no doubt be aware, the plans for development of the outlying regions of the Galaxy require the

[Python-Dev] Re: The current state of typing PEPs

On Sat, Nov 20, 2021 at 11:46:56PM -0800, Christopher Barker wrote: > One example is a use case of mine -- I have built a hierarchical object > system, built on dataclasses, in which the annotation absolutely has to be > an actual type(class) object. PEP 563 will very much break this use case. I

[Python-Dev] Re: The current state of typing PEPs

Executive summary: The typing-suspicious crowd has a valid complaint about PEPs 563 and 649, but it's not that they weren't warned. Christopher Barker writes: > Annotations can be, and are, used for other things than "typing". I > just noticed that PEP 563 apparently deprecated those other

[Python-Dev] Re: The current state of typing PEPs

On 21/11/2021 11:04, Paul Moore wrote: On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote: It's becoming harder and harder for people not particularly interested in static typing to simply ignore it (Raises hand.)  +1 Rob Cliffe ___ Python-Dev

[Python-Dev] Re: The current state of typing PEPs

On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote: > > TL;DR: > > Annotations can be, and are, used for other things than "typing". I just > noticed that PEP 563 apparently deprecated those other uses (well, sort of: > "uses for annotations incompatible with the aforementioned PEPs should

[Python-Dev] Re: The current state of typing PEPs

Thanks to Barry and the SC for giving us this update. > In the interest of full transparency, we want to let the Python community know that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of Annotations) and PEP 649 (Deferred Evaluation Of Annotations Using Descriptors).

[Python-Dev] Re: The current state of typing PEPs

On 11/17/2021 5:47 PM, Barry Warsaw wrote: Does PEP 563 or 649 satisfy static and dynamic typing needs? In the interest of full transparency, we want to let the Python community know that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of Annotations) and PEP 649