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

[Carl Meyer]

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 annotation semantics. Since I have access to a
real-world large codebase with almost complete adoption of type
annotations (and I care about its import performance), I'm willing to
test PEP 649 on it (can't commit to doing it right away, but within
the next month or so) and see how much import performance is impacted,
and how much of that can be gained back by interning tweaks as
discussed in the other thread. My feeling is that if the performance
turns out to be reasonably close in a real codebase, and we can find a
workable solution for `if TYPE_CHECKING`, we should go ahead with PEP
649: IMO aside from those two issues its semantics are a better fit
for the rest of the language and preferable to PEP 563.

I do think that a solution to the `if TYPE_CHECKING` problem should be
identified as part of PEP 649. My favorite option there would be a new
form of import that is lazy (the import does not actually occur until
the imported name is loaded at runtime). This has prior art in
previous discussions about "module descriptors"; IIRC Neil Schemenauer
even had a branch a while ago where all module attributes were
modified to behave this way (I might be remembering the details
wrong.) It also has overlap with use cases served by the existing
`demandimport` library used by hg, and `importlib.util.LazyLoader`,
although it is strictly more capable because it can work with `from
module import Thing` style imports as well. If there's any interest in
this as a solution to inter-module annotation forward references, I'm
also willing to work on that in the 3.11 timeframe.

Carl
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/VBG2LXU6OHROQ3NPF373L7W4W23B24DE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 be annotated.  But we can certainly kick this can down
> the road too.  Maybe by the time we get around to it, we'll have a
> read-only dictionary we can use for the purpose.
>

We already have one -- the mappingproxy  type you get back from a class'
__dict__ attribute. (Though in the fullness of times, type objects
presumably won't be shared between multiple interpreters, which solves the
problem in a different way.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/JXJQ76AUSI5U7JOB5G4AAGPVAKWDFR6U/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barney Gale]

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
. Thanks for the reviews - I
appreciate reviewer time is scarce!

I may be pushing my luck here, but there are *just two* PRs outstanding
before work on AbstractPath can begin in earnest.

I would love for these to land before the 3.10 feature freeze so that we
can spend the entire 3.11 development cycle getting the
design/implementation of AbstractPath exactly right. The PRs are:

   - #25271  / bpo-42998
    - Add ‘user’ parameter to
   Path.home()
  - A simple patch. No reviewers yet
   - #25264  / bpo-43757
    - Make Path.resolve() use
   os.path.realpath() to resolve all symlinks in a path
  - A more complex patch with several contributions from reviewers
  - Adds keyword-only ‘strict’ param to realpath()
  - Now backwards compatible! No longer changes default realpath()
  behaviour

If anyone can spare the time over the next week to help get these patches
over the line, I would really appreciate it!

A quick elevator pitch for why AbstractPath is an important future feature:

   - pathlib is a wonderful library that beautifully shows off Python’s
   “everything is an object” approach. It’s rightly front-and-centre of many
   Python beginner tutorials. If we can extend that “everything” to include
   files in tarballs, zip files, disc images, FTP servers, S3, etc, it allows
   Python users to easily apply their pathlib knowledge to new (and common!)
   tasks.
   - In DevOps it’s common to deal with remote or embedded filesystems.
   There’s a need for pathlib-like interfaces, and that need is already met in
   popular third-party packages either by *emulating* Path APIs (often with
   subtle differences) or *hackily extending* Path/_Accessor/_Flavour
   (which is brittle and totally unsupported). Even in the standard library,
   zipfile.Path is a mostly-compatible emulation of pathlib.Path. Providing a
   supported route for extending an AbstractPath saves a bunch of heartache
   and makes the wider pathlib ecosystem more robust.

Thanks again to everyone who has contributed their time and expertise up to
this point.

Cheers

Barney

On Fri, 9 Apr 2021 at 01:17, Barney Gale  wrote:

> Thanks so much to everyone who discussed and reviewed the code and made
> suggestions.
>
> The bulk of these patches have now landed. For those following along at
> home, here’s a summary of the remaining PRs/bugs :
>
>- #18909  / bpo-39950
>: Add Path.hardlink_to() method
>that supersedes link_to()
>   - Note: already under core review
>- #25271  / bpo-42998
>: Add ‘user’ parameter to
>Path.home()
>- #25240  / bpo-40107
>: Stop using os.open() to
>implement Path.open()
>- #25264  / bpo-43757
>: Make Path.resolve() use
>os.path.realpath() to resolve all symlinks in a path
>   - Note: changes realpath() behaviour when symlink loops are
>   encountered (!), and adds a keyword-only 'strict' param.
>- #25277  / bpo-39899
>: Follow-up fix for oversight in
>#18841 
>
> I believe this is a complete account of the outstanding prep work. Once
> these land, pathlib’s *path*, *flavour* and *accessor* abstractions will
> be less leaky, which allows work on pathlib.AbstractPath to proceed.
>
> Thanks again to Antoine Pitrou, Brett Cannon, Serhiy Storchaka, Steve
> Dower and Eryk Sun for their invaluable contributions.
>
> Barney
>
> On Sat, 3 Apr 2021 at 03:02, Barney Gale  wrote:
>
>> I’m working towards supporting subclassing pathlib.Path for things like
>> zip/tar archives, iso files, S3, etc. This was first brought up a few years
>> ago in bpo-24132  and discussed
>> further on the python-ideas forum
>> .
>>
>> Before I can approach the meat of the issue, I'd like to land a handful
>> of backwards-compatible patches that tidy up the pathlib internals. These
>> are:
>>
>>- #19220  / bpo-39924
>>: Handle missing os fu

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

[Larry Hastings]

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 I think I figured out a good spot 
for both.  I have this much working, including fixing the test suite.


But now I realize (*head-slap* here): if *every* class is going to 
have annotations, does that mean builtin classes too? StructSequence 
classes like float? Bare-metal type objects like complex?  Heck, what 
about type itself?!


My knee-jerk initial response: yes, those too.  Which means adding a 
new getsetdef to the type object.  But that's slightly complicated.  
The point of doing this is to preserve the existing best-practice of 
peeking in the class dict for __annotations__, to avoid inheriting 
it.  If I'm to preserve that, the get/set for __annotations__ on a 
type object would need to get/set it on tp_dict if tp_dict was not 
NULL, and use internal storage somewhere if there is no tp_dict.


It's worth noticing that builtin types don't currently have 
__annotations__ set, and you can't set them. (Or, at least, float, 
complex, and type didn't have them set, and wouldn't let me set 
annotations on them.)  So presumably people using current best 
practice--peek in the class dict--aren't having problems.


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?


Beware of adding mutable state to bulit-in (C static) type objects: 
these are shared across interpreters, so changing them can “pollute” 
unwanted contexts.


This has been so for a long time [0]. There are some subinterpreter 
efforts underway that might eventually lead to making __annotations__ 
on static types easier to add, but while you're certainly welcome to 
explore the neighboring rabbit hole as well, I do think you're going 
in too far for now :)


[0] 
https://mail.python.org/archives/list/python-dev@python.org/message/KLCZIA6FSDY3S34U7A72CPSBYSOMGZG3/



That's a good point!  The sort of detail one forgets in the rush of the 
moment.


Given that the lack of annotations on builtin types already isn't a 
problem, and given this wrinkle, and generally given the "naw you don't 
have to" vibe I got from you and Nick (and the lack of "yup you gotta" I 
got from anybody else), I'm gonna go with not polluting the builtin 
types for now.


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 be annotated.  But we can certainly kick this can 
down the road too.  Maybe by the time we get around to it, we'll have a 
read-only dictionary we can use for the purpose.



Cheers,


//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/CXJGWWHXK2UUDJQGLSJKU5JKZVKV6TFK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Larry Hastings]

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 classes untouched?  What do you think?


I'd suggest kicking the can down the road: leave builtin classes alone 
for now, but file a ticket to reconsider the question for 3.11.


In the meantime, inspect.get_annotations can help hide the discrepancy.



The good news: inspect.get_annotations() absolutely can handle it.  
inspect.get_annotations() is so paranoid about examining the object you 
pass in, I suspect you could pass in an old boot and it would pull out 
the annotations--if it had any.


Cheers,


//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/X2AQ5XTXKHPKSNVG6E5F5TROFKWY4CDM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Matthew Rahtz via Python-Dev]

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 20:16, Brett Cannon  wrote:

> First, the SC is postponing considering accepting
> https://www.python.org/dev/peps/pep-0646/ any further until Python 3.11.
> There's unfortunately not enough time before b1 to get requested updates
> into the PEP, discuss the PEP again, approve it, and then review an
> implementation thoroughly.
>
> Second, this PEP is proposing new syntax for Python but that detail is
> barely touched upon. For instance, there isn't a direct proposal of what
> grammar changes that should be made. There's also no discussion of what the
> exact runtime semantics should be. While a lot could be inferred by "it's
> allowing * within indexing contexts" (which is basically what the PEP is
> proposing from a syntactic perspective), that isn't a spec. 😉 As such, we
> are asking that the PEP be expanded upon to fully explain the proposed
> syntactic change, it's impact on the language and it's spec, etc.
>
> Once this update happens, we will be happy to look at the PEP again for
> consideration of inclusion in Python 3.11.
>
>
> -Brett (on behalf of the SC)
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/J3YYZ4PB5HZQSKGDZCKPTNPKDPBUETOB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

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 
both.  I have this much working, including fixing the test suite.


But now I realize (*head-slap* here): if *every* class is going to have 
annotations, does that mean builtin classes too?  StructSequence classes 
like float? Bare-metal type objects like complex?  Heck, what about type 
itself?!


My knee-jerk initial response: yes, those too.  Which means adding a new 
getsetdef to the type object.  But that's slightly complicated.  The 
point of doing this is to preserve the existing best-practice of peeking 
in the class dict for __annotations__, to avoid inheriting it.  If I'm 
to preserve that, the get/set for __annotations__ on a type object would 
need to get/set it on tp_dict if tp_dict was not NULL, and use internal 
storage somewhere if there is no tp_dict.


It's worth noticing that builtin types don't currently have 
__annotations__ set, and you can't set them. (Or, at least, float, 
complex, and type didn't have them set, and wouldn't let me set 
annotations on them.)  So presumably people using current best 
practice--peek in the class dict--aren't having problems.


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?


Beware of adding mutable state to bulit-in (C static) type objects: 
these are shared across interpreters, so changing them can “pollute” 
unwanted contexts.


This has been so for a long time [0]. There are some subinterpreter 
efforts underway that might eventually lead to making __annotations__ on 
static types easier to add, but while you're certainly welcome to 
explore the neighboring rabbit hole as well, I do think you're going in 
too far for now :)


[0] 
https://mail.python.org/archives/list/python-dev@python.org/message/KLCZIA6FSDY3S34U7A72CPSBYSOMGZG3/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/3GIZO2R2IRIN47THXRWAZKEQ5JBFRITP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

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 the road: leave builtin classes alone for
now, but file a ticket to reconsider the question for 3.11.

In the meantime, inspect.get_annotations can help hide the discrepancy.

Cheers,
Nick.


>
> Cheers,
>
>
> */arry*
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/IK7IWUCTESD5OZE47J45EY3FRVM7GEKM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/2OPILFSQYQP4ERZB6OGABL5ENEWFTRQN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Rittau]

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 hasattr(foo, 'seek') and hasattr(foo, 
'read'):`


Just does not roll off the figurative tongue and that is a relatively 
simple example of what is required for a duck check.


To prevent isinstance use when a duck check would be better, we're 
missing an easy builtin elevated to the isinstance() availability 
level behaving as lookslikeaduck() that does matches against a (set 
of) declared typing.Protocol shape(s). An implementation of this 
exists - 
https://www.python.org/dev/peps/pep-0544/#runtime-checkable-decorator-and-narrowing-types-by-isinstance 
 
- but it requires the protocols to declare runtime checkability and 
has them work with isinstance similar to ABCs...  technically accurate 
/BUT via isinstance/? Doh!  It promotes the use of isinstance when it 
really isn't about class hierarchy at all...


Edit: Maybe that's okay, isinstance can be read leniently to mean "is 
an instance of something that one of these things over here says it 
matches" rather than meaning "a parent class type is..."?  From a past 
experience user perspective I don't read "isinstance" as "looks like a 
duck" when I read code.  I assume I'm not alone.


I'm using isinstance from time to time, mostly to satisfy the type 
checker in some cases. I think having a "hasshape()" builtin would be a 
huge win. In addition it would be useful for type checkers to better 
support hasattr() for distinguishing between separate types. For 
example, mypy has a problem with the following:


    class A: pass
    class B:
    x: int

    def foo(x: A | B) -> None:
    if hasattr(x, "b"):
    accepts_b(x)
    else:
    accepts_a(x)

As Nathaniel indicated, how deep do we want to go down this rabbit 
hole of checking?  just names? signatures and types on those?  What 
about exceptions (something our type system has no way to declare at 
all)?  and infinite side effects?  At the end of the day we're 
required to trust the result of whatever check we use and any 
implementation may not conform to our desires no matter how much 
checking we do. Unless we solve the halting problem. :P
I think a PEP to discuss these questions would be appropriate. Things 
like also checking types could also be optional.
Not quite.  A Protocol is merely a way to describe a structural type.  
You do not /need/ to have your /implementations/ of anything inherit 
from typing.Protocol.  I'd /personally/ advise people /do not inherit/ 
from Protocol in their implementation.


+1

Luciano notes that it is preferred to define your protocols as narrow 
and define them in places *where they're used*, to follow a golang 
interface practice.  My thinking aligns with that.


My background is with TypeScript, not go. But TypeScript uses 
"interfaces" extensively to describe the shape of expected objects. I 
agree mostly with you and Luciano here, but it can make sense to define 
some protocols in a more visible location. Examples are the protocols in 
collections.abc. In typeshed we collected a few more common protocols in 
the type-check only module _typeshed. 
(https://github.com/python/typeshed/tree/master/stdlib/_typeshed) These 
are a bit experimental, but could eventually find their way into the 
standard library.


A bit off-topic: But intersection types (as discussed here: 
https://github.com/python/typing/issues/213) could also make a nice 
addition to quickly compose ad-hoc protocols from pre-made protocols:


    def read_stuff(f: HasRead & HasSeek) -> None: ...

That inheritance is used in the /declaration/ of the protocol is an 
implementation detail because our language has never had a syntax for 
declaring an interface. 544 fit within our existing language syntax.


Jukka Lehtosalo proposed a new "type" keyword over at typing-sig: 
https://mail.python.org/archives/list/typing-...@python.org/thread/LV22PX454W4VDTXY6NDJV7NZD4LFK464/ 
This could also be used to define protocols a bit more succintly, and 
with additional syntax constraints, making protocols feel a bit more 
"first class" than they feel now.


 - Sebastian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/VJEBP3U37RFN36TJDNLDQTHKCW7D4KHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

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 Java,
which is extremely successful and was created a bit before the 21st
century.

Second, I'll ask for a source supporting your statement.  I looked for
one and the first result I got is this:
https://pypl.github.io/PYPL.html

... which seems to suggest that Go is less popular than Swift,
TypeScript, or even the relatively obscure Kotlin language.  It's also
behind C# and Objective-C, and the former can probably be considered a
21st century language.

My conclusion from this is that Go's popularity is mostly visible in a
few restricted circles of computing, and in those it doesn't seem to
fare that much better than Rust, either.  But focussing on those two
languages shows a certain selection bias.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/K5AI6KUMBVG2S6BO3TWP6HPLT45P3IFA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

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 like a duck.
> 
> So yes, isinstance(obj, Sequence) is really the only way to know that obj
> is a Sequence in every important way -- but if you only need it to do one
> or two things like a Sequence, then you don't care.

It depends on the context, though.  Sometimes it's better to check
explicitly and raise a nice error message, then raise a cryptic error
much further that seems to bear little relationship to the line of code
the user wrote.  Especially if that error is raised at the end of a
10-minute computation, or after sending 1GB of data to a S3 bucket.

For this reason, when there's no use case for accepting many kinds of
sequences in a user-facing API, I find it useful to do a `isinstance(x,
(list, tuple))` check before proceeding.

Yes, it's not pure duck typing, but who cares?

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/D2WLZTH7X34Y57DRSQVCMTDFOTOWSIQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Larry Hastings]

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 fixing the test suite.


But now I realize (*head-slap* here): if *every* class is going to have 
annotations, does that mean builtin classes too?  StructSequence classes 
like float? Bare-metal type objects like complex?  Heck, what about type 
itself?!


My knee-jerk initial response: yes, those too.  Which means adding a new 
getsetdef to the type object.  But that's slightly complicated.  The 
point of doing this is to preserve the existing best-practice of peeking 
in the class dict for __annotations__, to avoid inheriting it.  If I'm 
to preserve that, the get/set for __annotations__ on a type object would 
need to get/set it on tp_dict if tp_dict was not NULL, and use internal 
storage somewhere if there is no tp_dict.


It's worth noticing that builtin types don't currently have 
__annotations__ set, and you can't set them. (Or, at least, float, 
complex, and type didn't have them set, and wouldn't let me set 
annotations on them.)  So presumably people using current best 
practice--peek in the class dict--aren't having problems.


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?



Cheers,


//arry/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/IK7IWUCTESD5OZE47J45EY3FRVM7GEKM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

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 standard library can be
"defined close to the consumer".  By definition, these facilities are
far from the provider, since they're abstract (whether they're defined
ABCs, "small" protocols, or duck typing).

The point of my example is that indeed, my tiny "SJIS protocol"
*arose* near the original consumer, but it was refined and is now
*defined* "far" from any consumer.  (The fact that it's self-
providing is an accident of the fact that it's a concrete protocol.)
I think that this is a useful process for software development (ie,
design APIs from the point of view of the consumers and then make sure
the backends provide them) but I don't see how this applies to
structuring the Python stdlib or typing.*.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WT5JCNKYWTXWDR3CA3UYJ4XY5AVJWJU3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

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 things, for
that matter).  EAFP can only verify the presence of the facilities you
actually use, not what thing is, so it *implies* duck-typing.

Nick's statement is not even close to a logical implication, as you
point out, but I think it's the state of the art.  The question I have
is whether that's something essential about duck-typing, or if perhaps
as Gregory points out it's that we don't have TOOWDTI for LYBL duck-
typing.

It's interesting in this regard that so much effort goes into strict
typing and pattern matching which (so far) are LYBL concepts, while
EAFP + duck-typing is "No Reason," "Just Do It" and nobody seems to
have a big problem with that once they get used to it. :-)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/3GQ5LJ43HFQAWNQG65UF7RMNK6T7XAGJ/
Code of Conduct: http://python.org/psf/codeofconduct/