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

> > As far as I know, both Pydantic and marshmallow start using annotation > for runtime type after PEP 563 is accepted. Am I right? Not quite, pydantic was released in June 2017 (see HN post: https://news.ycombinator.com/item?id=14477222) and always used annotations, PEP 563 was created in

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

There are a number of issues around recursive types, in general PEP 563 doesn't make a big difference either way in this case. I think you mean something like from pydantic import BaseModel from typing import Optional class Foo(BaseModel): x: int foo: Optional['Foo']

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

Hi Samuel, I have a naive question about pydantic. IIRC there's something in your tracker about not being able to handle recursive definitions correctly with PEP 563. But I must be misremembering, because PEP 563 actually makes that easier, not harder. Without PEP 563, how does it handle classes

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

As far as I know, both Pydantic and marshmallow start using annotation for runtime type after PEP 563 is accepted. Am I right? When PEP 563 is accepted, there are some tools using runtime type in annotation, but they are not adopted widely yet. But we didn't have any good way to emit

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

I'd like to chime in with an example of how PEP 563 breaks code that uses dataclasses. I've written a library instant_api (https://github.com/alexmojaki/instant_api) that is heavily inspired by FastAPI but uses dataclasses for complex types instead of pydantic. The example at the beginning of

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

On 4/17/2021 6:44 PM, Christopher Barker wrote: On Sat, Apr 17, 2021 at 6:12 AM Eric V. Smith > wrote: I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I have! Thanks Eric. In retrospect, that field probably should have

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

On Sat, Apr 17, 2021 at 6:12 AM Eric V. Smith wrote: > I wonder if anyone has considered the impact of PEP 563 on dataclasses ? > > I have! > Thanks Eric. > In retrospect, that field probably should have been named "annotation". > Regardless, the intent was always "store what's in >

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

Related, `inspect.Parameter.annotation` is affected too, but at least this attribute is called `annotation` instead of `type`. I noticed this today with `multipledispatch` (though [reported](https://github.com/mrocklin/multipledispatch/issues/104) in 2019) and some other internal code, both

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

El vie, 16 abr 2021 a las 21:32, Christopher Barker () escribió: > ... > dataclasses may be the only part of the stdlib that uses annotations. > > > There's another one, actually: functools.singledispatch, at https://github.com/python/cpython/blob/3.9/Lib/functools.py#L860. It uses the

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

On 4/17/2021 12:28 AM, Christopher Barker wrote: I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I have! I did find this SO post: https://stackoverflow.com/questions/52171982/new-annotations-break-inspection-of-dataclasses

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

I wonder if anyone has considered the impact of PEP 563 on dataclasses ? I did find this SO post: https://stackoverflow.com/questions/52171982/new-annotations-break-inspection-of-dataclasses which is related, but not quite the same -- THAT issue was fixed. My issue does show up in this BPO:

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

Thank you everyone for your responses. I entirely accept that I should have brought this up earlier, perhaps much earlier. In my defence, when PEP 563 first came on my radar I assumed that get_type_hint() would be improved before it became the default behaviour, AFAIK it hasn't really

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

> Are you sure about PEP 563 break it and discord.py can not fix it? PEP 563 has been supported by discord.py since the PEP was introduced -- the change was not particularly hard to support on my end. Newer versions of the library are even more supportive of things like `ForwardRef` and the

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

On Fri, Apr 16, 2021 at 8:27 AM Inada Naoki wrote: > After PEP 563, only `'List[int]'` is practical so we can stop > supporting `List["int"]` and others at some point. > There's a lot of code written before PEP 563 was available (and code that needs to support earlier Python versions) that

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

Guido: > It seems a little disingenuous to claim discussions about annotations don’t > concern you when you’re actively using them (for typing, no less, in the > case of pydantic). And I am sure a project as popular (by their own > description) as pydantic will find a way forward if PEP 649 is

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

On Fri, 16 Apr 2021 10:35:19 +0900 Inada Naoki wrote: > > And personally, I love static typing but I don't use type hint for > performance/memory usage reason. > I spend much effort to optimize PEP 563 to minimize type hinting overhead. > So it's very sad that if I can not use type hinting when

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

On Fri, Apr 16, 2021 at 6:03 AM 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) >

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

On 4/15/21 6:09 PM, Barry Warsaw wrote: On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11.

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

On Thu, Apr 15, 2021 at 18:20 Barry Warsaw wrote: > On Apr 15, 2021, at 17:47, Oscar Benjamin > wrote: > > > > Would it be problematic to postpone making __future__.annotations the > default? > > This is a good question, and I think the SC would really like to know if > anybody has objections

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

On Fri, Apr 16, 2021 at 9:49 AM Oscar Benjamin wrote: > > > > That said, I agree it is better that this came up before the feature freeze > > than after the release. And I am willing to accept that the hypothetical > > future where annotations are not always syntactically expressions (which >

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

On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: > > Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11. We haven’t discussed it yet (this

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

On Fri, 16 Apr 2021 at 01:13, Guido van Rossum wrote: > > On Thu, Apr 15, 2021 at 16:48 Christopher Barker wrote: >> >> And as I noted in my last post — many folks have not been paying attention >> to the typing discussions because they didn’t realize it concerned them. > > It seems a little

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

On Thu, Apr 15, 2021 at 16:48 Christopher Barker wrote: > And as I noted in my last post — many folks have not been paying attention > to the typing discussions because they didn’t realize it concerned them. > It seems a little disingenuous to claim discussions about annotations don’t concern

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

On Thu, Apr 15, 2021 at 4:20 PM Brett Cannon wrote: > > Making this an "us versus them" discussion just makes the whole situation > feel confrontational when instead everyone is trying to figure out the best > thing for everybody when there's no perfect answer. > I agree that that was strong

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

It seems evident that the problems with PEP 563 have been well-known at least to pydantic for several years, as you can see in the issue Samuel Colvin linked: https://github.com/samuelcolvin/pydantic/issues/2678 That said, while I do think that "please contact upstream when you see a problem

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

On Thu, Apr 15, 2021 at 12:01 PM Samuel Colvin wrote: > I've read the recent discussions > > regarding PEP 649 and PEP 563 with interest, Larry Hastings

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

On Thu, Apr 15, 2021 at 3:29 PM Bernat Gabor wrote: > I'm a bit surprised that this topic is brought up just days before the feature freeze of Python 3.10. I have not idea about the technical details, but I think there is a bit of a discomment in the community: Annotations have been around for

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

Hello, I'm a bit surprised that this topic is brought up just days before the feature freeze of Python 3.10. How did tools work until now with from future import annotations? This feature has been in the language for years (since 3.7), and I haven't heard until today anyone complaining about

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

On 4/15/21 2:49 PM, Paul Ganssle wrote: 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)? Perhaps I'm a poor judge of the quality of my own code.   But I'd say I have a working

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

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

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

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

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

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

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

I haven't commented on these, as I don't use type annotations in the "usual" way., but: On Thu, Apr 15, 2021 at 12:06 PM Samuel Colvin wrote: > I maintain pydantic which uses > type annotations to provide runtime data validation. > I maintain in in-house