[Python-Dev] Re: PEP 563 and 649: The Great Compromise

Hi Larry, This is a creative option, but I am optimistic (now that the SC decision has removed the 3.10 deadline urgency) that we can find a path forward that is workable for everyone and doesn't require a permanent compiler feature flag and a language that is permanently split-brained about

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

On Sat, Apr 24, 2021 at 2:25 PM Larry Hastings wrote: > This is not to say that, in the fullness of time, those objects should > never have annotations. Even in the three random types I picked in my > example, there's at least one example: float.imag is a data member and > might theoretically

[Python-Dev] Re: Request for reviewers: pathlib improvements

Hi all, I hope I’m not in danger of abusing this mailing list - please let me know if this is too much noise. I’m very happy to share that 3 more pathlib PRs have landed - #18909 , #25240 and #25277

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

On 4/24/21 8:09 AM, Petr Viktorin wrote: On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts. The latter was more delicate than the former but

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

On 4/24/21 7:11 AM, Nick Coghlan wrote: On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, > wrote: So I now suspect that my knee-jerk answer is wrong.  Am I going too far down the rabbit hole? Should I /just/ make the change for user classes and leave builtin

[Python-Dev] Re: Asking for clarifications in PEP 646 and postponing to Python 3.11

Thanks for the feedback, Brett! This is a very reasonable response given the implications of a syntax change. We'll work on a more thorough implementation and add details to the PEP of the grammar changes that are necessary, and see you again in the cycle for Python 3.11. On Fri, 23 Apr 2021 at

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

On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for

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

On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, wrote: > > So I now suspect that my knee-jerk answer is wrong. Am I going too far > down the rabbit hole? Should I *just* make the change for user classes > and leave builtin classes untouched? What do you think? > I'd suggest kicking the can down

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

Am 24.04.2021 um 01:26 schrieb Gregory P. Smith: Practically speaking, one issue I have is how easy it is to write isinstance or issubclass checks. It has historically been much more difficult to write and maintain a check that something looks like a duck.  `if hasattr(foo, 'close') and

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

On Thu, 22 Apr 2021 12:47:42 -0300 Luciano Ramalho wrote: > > Go is by far the most successful statically typed language created so > far in the 21st century, First, it seems gratuitous to restrict your search to "created so far in the 21st century". I suppose that allows you to eliminate

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

On Wed, 21 Apr 2021 12:36:34 -0700 Christopher Barker wrote: > > 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

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

I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for both.  I have this much working, including

[Python-Dev] Re: OTish: Define Protocols near consumers [was: Keeping Python a Duck Typed Language.]

Paul Moore writes: > What you're missing, I think, is that we're talking about > typing.Protocol - see here: > https://docs.python.org/3/library/typing.html#typing.Protocol I understand that we're talking about typing. What I don't understand is how any general facility provided in a

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

Chris Angelico writes: > On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote: > > Duck typing usually falls squarely into the EAFP category. > > Isn't it orthogonal? Not really. If you ask 'thing' to 'thing[0]', you don't find out whether it is a list or a dict (or any number of other