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

[Larry Hastings]

On 4/23/21 9:26 PM, Guido van Rossum wrote:
This is happening, right? Adding a default `__annotations = {}` to 
modules and classes. (Though https://bugs.python.org/issue43901 
 seems temporarily stuck.)



It's happening, and I wouldn't say it's stuck.  I'm actively working on 
it--currently puzzling my way through some wild unit test failures.  I 
expect to ship my first PR over the weekend.



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/TQNOMVBPIH2NSYNDSYCIOCMOZ3VX3SXR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

This is happening, right? Adding a default `__annotations = {}` to modules
and classes. (Though https://bugs.python.org/issue43901 seems temporarily
stuck.)

On Mon, Apr 19, 2021 at 10:10 PM Larry Hastings  wrote:

>
>
> As long as I'm gravedigging old conversations...!  Remember this one, also
> from January of this year?  Here's a link to the thread in the c.l.p-d
> Mailman archive.  The first message in the thread is a good overview of the
> problem:
>
>
> https://mail.python.org/archives/list/python-dev@python.org/thread/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/
>
>
> Here's kind of where we left it:
>
> On 1/12/21 7:48 PM, Guido van Rossum wrote:
>
> On Tue, Jan 12, 2021 at 6:35 PM Larry Hastings  wrote:
>
>> On 1/12/21 5:28 PM, Brett Cannon wrote:
>>
>> The other thing to keep in mind is we are talking about every module,
>> class, and function getting 64 bytes ... which I bet isn't that much.
>>
>> Actually it's only every module and class.  Functions don't have this
>> problem because they've always stored __annotations__ internally--meaning,
>> peeking in their __dict__ doesn't work, and they don't support inheritance
>> anyway.  So the number is even smaller than that.
>>
>> If we can just make __annotations__ default to an empty dict on classes
>> and modules, and not worry about the memory consumption, that goes a long
>> way to cleaning up the semantics.
>>
>
> I would like that very much. And the exception for functions is especially
> helpful.
>
>
> First of all, I've proposed a function that should also help a lot:
>
> https://bugs.python.org/issue43817
>
> The function will be called inspect.get_annotations(o).  It's like
> typing.get_type_hints(o) except less opinionated.  This function would
> become the best practice for everybody who wants annotations**, like so:
>
> import inspect
> if hasattr(inspect, "get_annotations"):
> how_i_get_annotations = inspect.get_annotations
> else:
> # do whatever it was I did in Python 3.9 and before...
>
>
> ** Everybody who specifically wants *type hints* should instead call
> typing.get_type_hints(), and good news!, *that* function has existed for
> several versions now.  So they probably already *do* call it.
>
>
> I'd still like to add a default empty __annotations__ dict to all classes
> and modules for Python 3.10, for everybody who doesn't switch to using this
> as-yet-unwritten inspect.get_annotations() function.  The other changes I
> propose in that thread (e.g. deleting __annotations__ always throws
> TypeError) would be nice, but honestly they aren't high priority.  They can
> wait until after Python 3.10.  Just these these two things
> (inspect.get_annotations() and always populating __annotations__ for
> classes and modules) would go a long way to cleaning up how people examine
> annotations.
>
> Long-term, hopefully we can fold the desirable behaviors of
> inspect.get_annotations() into the language itself, at which point we could
> probably deprecate the function.  That wouldn't be until a long time from
> now of course.
>
>
> Does this need a lot of discussion, or can I just go ahead with the bpo
> and PR and such?  I mean, I'd JFDI, as Barry always encourages, but given
> how much debate we've had over annotations in the last two weeks, I figured
> I should first bring it up here.
>
>
> Happy two-weeks'-notice,
>
>
> */arry*
>
> p.s. I completely forgot about this until just now--sorry.  At least I
> remembered before Python 3.10b1!
> ___
> 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/J4LZEIZTYZQWGIM5VZGNMQPWB5ZWVEXP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--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/IPVNH2EMHGB5W62SRKBVSLVNBBZRRDFL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Interaction of PEP 563's Annotations with Symbol Table

[Guido van Rossum]

+1 to what Jelle said -- I don't see anyone seriously using this except in
code golf or obfuscated code contests.

On Fri, Apr 23, 2021 at 11:51 AM Jelle Zijlstra 
wrote:

> For what it's worth, Larry's PEP 649 branch currently prohibits yield,
> yield from, await, and the walrus operator in annotations. That seems like
> the right choice unless there's some realistic use case for any of these.
>
> El vie, 23 abr 2021 a las 11:27, Batuhan Taskaya ()
> escribió:
>
>> About 4 months ago, I've created bpo-42725 in order to
>> resolve some of the points below though I decided to
>> postpone it for various reasons that blocked it completely
>> until the point of where we have a beta cut in a week or
>> so. So I'm asking for comments regarding how should we resolve
>> this behavior.
>>
>> Even though PEP 563 blocks having all compiler-related activities
>> for annotations by behaving them strings, this doesn't happen until
>> the symbol is constructed which results with different problems. For
>> example you can use yield in annotation, and since PEP 563 will stringify
>> it you'd expect your function to act accordingly but it currently doesn't.
>> Also references to the upper scope variables will still be contained as
>> closures
>> of the current function, and some other oddities that I've found
>> regarding misc
>> stuff (usage of super() etc).
>>
>> Here is a quick demo:
>>
>> def foo():
>> for number in range(5):
>> foo: (yield number)
>> return number
>>
>> foo() # ==> this will be a generator
>>
>> We could go with acting these as strings and letting them stay as
>> annotations
>> but making them no-op on the symbol table (which is the straight forward
>> choice)
>> or we could restrict usage of those inside of annotations and raise
>> SyntaxErrors. I've
>> drafted patches for both of those ideas, though it definitely needs
>> more work and
>> there is not much time left so any comments would be appreciated.
>>
>> P.S: I intend to submit a PR with the most likely option by, at latest,
>> end of
>> saturday so that we can give reviewers enough time and also catch the
>> beta freeze
>> considering this is a clear behavioral change.
>> ___
>> 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/5NQH5GURAYW6XINPBO6VSF45CWLQOHUQ/
>> 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/PZJXENJP2PDZ3OARUEJS5YDQ2HEQ5VI6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--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/KBWUTQTHHDNPHWW4WWXBT5IKRA4RQY5R/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan  wrote:
>
>
>
> On Sat, 24 Apr 2021, 10:02 am Skip Montanaro,  
> wrote:
>>
>>
>>> 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,
>>
>>
>> I'm going to chime in briefly then return to lurking on this topic, trying 
>> to figure out all the changes to typing while I wasn't paying attention. 
>> Back in ancient times I recall "look before you leap" as the description of 
>> either of the above styles of checks, no matter which was easier to type. At 
>> the time, I thought the general recommendation was to document what 
>> attributes you expected objects to provide and just make the relevant 
>> unguarded references. I no longer recall what the tongue-in-cheek 
>> description of that style was (just "leap"?) Is that more simple usage more 
>> akin to classic "duck typing" than always guarding accesses? I assume that 
>> will still have a place in the pantheon of Python type variants.
>
>
> LBYL: Look before you leap (check then use)
> EAFP: Easier to ask forgiveness than permission (use, then handle any 
> exceptions or let them escape)
>
> (for accessing external resources rather than satisfying internal type 
> consistency, you usually need the latter, as the external state may change 
> between checking and usage)
>
> Duck typing usually falls squarely into the EAFP category.

Isn't it orthogonal? LBYL means checking first, EAFP means going ahead
and doing things, and coping with failure. Duck typing means caring
about it having a specific method/attribute, nominal typing means
caring about it "being a list". You can test either form in advance,
and you can certainly duck-type in EAFP style, so there's only one
quadrant that might not be possible (and even that, I'm sure, would be
possible somehow).

ChrisA
___
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/FJA52VPBTOI5JSOYIEIZDRCJGEOQ6V3P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On Fri, 23 Apr 2021, 12:34 pm Inada Naoki,  wrote:

>
> I think using ABC to distinguish sequence or mapping is a bad idea.
>
> There are three policies:
>
> a) Use duck-typing; just us it as sequence. No type check at all.
> b) Use strict type checking; isinstance(x, list) / isinstance(x, (list,
> tuple)).
> c) Use ABC.
>
> But (c) is broken by design. It is not fixable.
> IMHO, We should chose (a) or (b) and reject any idea relying on Sequence
> ABC.
>


That ship sailed long ago, since distinguishing sequences from mappings was
one of the original motivating use cases for ABCs (see the last sentence in
https://www.python.org/dev/peps/pep-3119/#abcs-vs-duck-typing ).

One of the important things to remember about ABCs is that passing a
*runtime* isinstance check is a matter of calling
"the_abc.register(my_type)". Hence the comment earlier in the thread that
with ABCs, passing "isinstance(obj, the_abc)" becomes just another
criterion for quacking like a duck.

Cheers,
Nick.




>
___
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/6G5EBNTHXMQJAD6FRVRPNDHNZBPVAOIK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On Sat, 24 Apr 2021, 10:02 am Skip Montanaro, 
wrote:

>
> 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,
>>
>
> I'm going to chime in briefly then return to lurking on this topic, trying
> to figure out all the changes to typing while I wasn't paying attention.
> Back in ancient times I recall "look before you leap" as the description of
> either of the above styles of checks, no matter which was easier to type.
> At the time, I thought the general recommendation was to document what
> attributes you expected objects to provide and just make the relevant
> unguarded references. I no longer recall what the tongue-in-cheek
> description of that style was (just "leap"?) Is that more simple usage more
> akin to classic "duck typing" than always guarding accesses? I assume that
> will still have a place in the pantheon of Python type variants.
>

LBYL: Look before you leap (check then use)
EAFP: Easier to ask forgiveness than permission (use, then handle any
exceptions or let them escape)

(for accessing external resources rather than satisfying internal type
consistency, you usually need the latter, as the external state may change
between checking and usage)

Duck typing usually falls squarely into the EAFP category.

Cheers,
Nick.


> Skip
> ___
> 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/QW7NQ5KTOQLV27MKZO5B3TMSTXIR5MC5/
> 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/ZA6IHKR3DOICMTEILXCBTX3LJXEVCFMX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Skip Montanaro]

> 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,
>

I'm going to chime in briefly then return to lurking on this topic, trying
to figure out all the changes to typing while I wasn't paying attention.
Back in ancient times I recall "look before you leap" as the description of
either of the above styles of checks, no matter which was easier to type.
At the time, I thought the general recommendation was to document what
attributes you expected objects to provide and just make the relevant
unguarded references. I no longer recall what the tongue-in-cheek
description of that style was (just "leap"?) Is that more simple usage more
akin to classic "duck typing" than always guarding accesses? I assume that
will still have a place in the pantheon of Python type variants.

Skip
___
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/QW7NQ5KTOQLV27MKZO5B3TMSTXIR5MC5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gregory P. Smith]

When reading this, I wrote most of it early and left a draft to bake
Then deleted a ton of it after other people replied. I'm conscious that my
terminology might be all over the map.  Keep that in mind before hitting
reply.  It'll take me a while to digest and pedantically use Luciano's
terms, they appear to be a great start. :)

On Tue, Apr 20, 2021 at 10:09 AM Mark Shannon  wrote:

> Hi everyone,
>
> Once upon a time Python was a purely duck typed language.
>
> Then came along abstract based classes, and some nominal typing starting
> to creep into the language.
>
> If you guarded your code with `isinstance(foo, Sequence)` then I could
> not use it with my `Foo` even if my `Foo` quacked like a sequence. I was
> forced to use nominal typing; inheriting from Sequence, or explicitly
> registering as a Sequence.
>

True.  Though in practice I haven't run into this often *myself*.  Do you
have practical examples of where this has bitten users such that code they
would've written pre-abc is no longer possible?  This audience can come up
with plenty of theoretical examples, those aren't so interesting to me.
I'm more interested in observances of actual real world fallout due to
something "important" (as defined however each user wants) using isinstance
checks when it ideally wouldn't.

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'd prefer something not involving metaclasses and __instancecheck__ type
class methods.  Something direct so that the author and reader both
explicitly see that they're seeing a duck check rather than a type
hierarchy check.  I don't think this ship has sailed, it could be built up
on top of what already exists if we want it.  Was this already covered in
earlier 544 discussions perhaps?

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

PEP 544 supports structural typing, but to declare a structural type you
> must inherit from Protocol.
> That smells a lot like nominal typing to me.
>

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. Leave that for a structural type
declaration for type description and annotation purposes only, even though
Protocol appears to support direct inheritance. I understand why some don't
like this separate shape declaration concept.

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.

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.

Then came PEP 563 and said that if you wanted to access the annotations
> of an object, you needed to call typing.get_type_hints() to get
> annotations in a meaningful form.
> This smells a bit like enforced static typing to me.
>

I think useful conversations are ongoing here.  Enforced is the wrong
word.  *[rest of comment deleted in light of Larry's work in progress
response]*

Nominal typing in a dynamically typed language makes 

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

[Caleb Donovick]

We can add .keys() to Mapping to distinguish Mapping and Sequence.
But it is breaking change, of course. We shouldn’t change it.

We could use the presence of .keys in the subclasses hook only after first
checking
explicit cases (i.e. actual subclass or has been registered). Yes this
would break code
that uses issubclass(X, Mapping) where X looks mapping but isn’t a mapping.
But is this really a concern? What if X had to have all 3 keys, values, and
items
to qualify? Are there really a bunch of classes with __getitem__,
__len__, __iter__, keys, values, and items where the class is expected to
not
be considered a subclass of Mapping?

If there really is a classes like this we could add a warning the subclass
hook about saying
that in a feature version that X is going to be considered a mapping.
Additionally we
could add a black list to the ABCs which would function like the inverse of
register.


On Thu, Apr 22, 2021 at 7:32 PM Inada Naoki songofaca...@gmail.com
 wrote:

On Fri, Apr 23, 2021 at 10:33 AM Chris Angelico  wrote:
> >
> > On Fri, Apr 23, 2021 at 11:22 AM Larry Hastings 
> wrote:
> > >
> > >
> > > On 4/20/21 10:03 AM, Mark Shannon wrote:
> > >
> > > If you guarded your code with `isinstance(foo, Sequence)` then I could
> not use it with my `Foo` even if my `Foo` quacked like a sequence. I was
> forced to use nominal typing; inheriting from Sequence, or explicitly
> registering as a Sequence.
> > >
> > >
> > > If I'm reading the library correctly, this is correct--but, perhaps,
> it could be remedied by adding a __subclasshook__ to Sequence that looked
> for an __iter__ attribute.  That technique might also apply to other ABCs
> in collections.abc, Mapping for example.  Would that work, or am I missing
> an critical detail?
> > >
> >
> > How would you distinguish between a Sequence and a Mapping? Both have
> > __iter__ and __len__. Without actually calling those methods, how
> > would the subclass hook tell them apart?
> >
> > ChrisA
>
> We can add .keys() to Mapping to distinguish Mapping and Sequence.
> But it is breaking change, of course. We shouldn't change it.
>
> I think using ABC to distinguish sequence or mapping is a bad idea.
>
> There are three policies:
>
> a) Use duck-typing; just us it as sequence. No type check at all.
> b) Use strict type checking; isinstance(x, list) / isinstance(x, (list,
> tuple)).
> c) Use ABC.
>
> But (c) is broken by design. It is not fixable.
> IMHO, We should chose (a) or (b) and reject any idea relying on Sequence
> ABC.
>
> Regards,
>
> --
> Inada Naoki  
> ___
> 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/ESLOPO4GLC2QZW4ZDBYEQDPPGB4ZYDWM/
> 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/ZJQMGI7345TC4AU4MQTWZZA2ENK4NWAL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Request For Review: Fix test_socket.CANTest.testSendFrame (bpo-40297)

[Karl Ding]

Hi all,

Could someone help take a look at the following PR, which fixes one of the
broken socket module tests that exercises part of the standard library?

PR Link: https://github.com/python/cpython/pull/19548
BPO Link: https://bugs.python.org/issue40297

The test can be run locally on Linux by setting up the virtual SocketCAN
interface the test expects:

# Load SocketCAN vcan kernel module
sudo modprobe vcan

# Start and set up a virtual SocketCAN interface
# Note: The SocketCAN tests expect a network interface called 'vcan0' to
exist
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# Run the socket tests using locally built Python
./python -m unittest -v test.test_socket.CANTest

Thanks!

-- 
Karl Ding
___
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/54BGN5TO3UWXD3EBTUVPWLJJCFJCDACV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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/5BVYPRJKQHKDLLN3T7H4WXP2NAD2ITFH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Interaction of PEP 563's Annotations with Symbol Table

[Jelle Zijlstra]

For what it's worth, Larry's PEP 649 branch currently prohibits yield,
yield from, await, and the walrus operator in annotations. That seems like
the right choice unless there's some realistic use case for any of these.

El vie, 23 abr 2021 a las 11:27, Batuhan Taskaya ()
escribió:

> About 4 months ago, I've created bpo-42725 in order to
> resolve some of the points below though I decided to
> postpone it for various reasons that blocked it completely
> until the point of where we have a beta cut in a week or
> so. So I'm asking for comments regarding how should we resolve
> this behavior.
>
> Even though PEP 563 blocks having all compiler-related activities
> for annotations by behaving them strings, this doesn't happen until
> the symbol is constructed which results with different problems. For
> example you can use yield in annotation, and since PEP 563 will stringify
> it you'd expect your function to act accordingly but it currently doesn't.
> Also references to the upper scope variables will still be contained as
> closures
> of the current function, and some other oddities that I've found regarding
> misc
> stuff (usage of super() etc).
>
> Here is a quick demo:
>
> def foo():
> for number in range(5):
> foo: (yield number)
> return number
>
> foo() # ==> this will be a generator
>
> We could go with acting these as strings and letting them stay as
> annotations
> but making them no-op on the symbol table (which is the straight forward
> choice)
> or we could restrict usage of those inside of annotations and raise
> SyntaxErrors. I've
> drafted patches for both of those ideas, though it definitely needs
> more work and
> there is not much time left so any comments would be appreciated.
>
> P.S: I intend to submit a PR with the most likely option by, at latest,
> end of
> saturday so that we can give reviewers enough time and also catch the
> beta freeze
> considering this is a clear behavioral change.
> ___
> 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/5NQH5GURAYW6XINPBO6VSF45CWLQOHUQ/
> 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/PZJXENJP2PDZ3OARUEJS5YDQ2HEQ5VI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Interaction of PEP 563's Annotations with Symbol Table

[Batuhan Taskaya]

About 4 months ago, I've created bpo-42725 in order to
resolve some of the points below though I decided to
postpone it for various reasons that blocked it completely
until the point of where we have a beta cut in a week or
so. So I'm asking for comments regarding how should we resolve
this behavior.

Even though PEP 563 blocks having all compiler-related activities
for annotations by behaving them strings, this doesn't happen until
the symbol is constructed which results with different problems. For
example you can use yield in annotation, and since PEP 563 will stringify
it you'd expect your function to act accordingly but it currently doesn't.
Also references to the upper scope variables will still be contained as closures
of the current function, and some other oddities that I've found regarding misc
stuff (usage of super() etc).

Here is a quick demo:

def foo():
for number in range(5):
foo: (yield number)
return number

foo() # ==> this will be a generator

We could go with acting these as strings and letting them stay as annotations
but making them no-op on the symbol table (which is the straight forward choice)
or we could restrict usage of those inside of annotations and raise
SyntaxErrors. I've
drafted patches for both of those ideas, though it definitely needs
more work and
there is not much time left so any comments would be appreciated.

P.S: I intend to submit a PR with the most likely option by, at latest, end of
saturday so that we can give reviewers enough time and also catch the
beta freeze
considering this is a clear behavioral change.
___
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/5NQH5GURAYW6XINPBO6VSF45CWLQOHUQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-04-16 - 2021-04-23)
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:
  open7474 (-48)
  closed 48187 (+101)
  total  55661 (+53)

Open issues with patches: 2971 


Issues opened (41)
==

#10663: configure shouldn't set a default OPT
https://bugs.python.org/issue10663  reopened by Arfrever

#28254: Add C API for gc.enable, gc.disable, and gc.isenabled
https://bugs.python.org/issue28254  reopened by scoder

#38605: [typing] PEP 563: Postponed evaluation of annotations: enable 
https://bugs.python.org/issue38605  reopened by pablogsal

#38659: enum classes cause slow startup time
https://bugs.python.org/issue38659  reopened by pablogsal

#43874: argparse crashes on subparsers with no dest/metava
https://bugs.python.org/issue43874  opened by terence.honles

#43875: glob.glob with ** does not always detect symlink loops
https://bugs.python.org/issue43875  opened by rrt

#43877: Logging Cookbook ambiguity
https://bugs.python.org/issue43877  opened by bluebloodpole

#43878: ./configure fails on Apple Silicon with coreutils uname
https://bugs.python.org/issue43878  opened by keith

#43879: Add native_thread_id to PyThreadState
https://bugs.python.org/issue43879  opened by Gabriele Tornetta

#43880: 3.10 SSL module deprecations
https://bugs.python.org/issue43880  opened by christian.heimes

#43881: add platform availabity information for os.sched_getaffinity
https://bugs.python.org/issue43881  opened by guoci

#43882: [security] urllib.parse should sanitize urls containing ASCII 
https://bugs.python.org/issue43882  opened by orsenthil

#43883: Making urlparse WHATWG conformant
https://bugs.python.org/issue43883  opened by orsenthil

#43884: Cannot cleanly kill a subprocess using high-level asyncio APIs
https://bugs.python.org/issue43884  opened by rabraham

#43886: Extending/embedding Python documentation outdated/incomplete
https://bugs.python.org/issue43886  opened by fede.evol

#43888: GitHub Actions CI/CD `Coverage` job is broken on master
https://bugs.python.org/issue43888  opened by webknjaz

#43889: Pickle performance regression in 3.10
https://bugs.python.org/issue43889  opened by kj

#43890: Deadlock when mixing event loops and subprocesses
https://bugs.python.org/issue43890  opened by thomas

#43891: co_annotations branch caused a crash in stackeffect() in compi
https://bugs.python.org/issue43891  opened by larry

#43892: Make match patterns explicit in the AST
https://bugs.python.org/issue43892  opened by ncoghlan

#43893: typing.get_type_hints does not accept type annotations with le
https://bugs.python.org/issue43893  opened by jarryshaw

#43894: IDLE editor file minor refactoring
https://bugs.python.org/issue43894  opened by epaine

#43895: Unnecessary Cache of Shared Object Handles
https://bugs.python.org/issue43895  opened by Ian.H

#43897: Implement support for validation of pattern matching ASTs
https://bugs.python.org/issue43897  opened by BTaskaya

#43899: separate builtin function
https://bugs.python.org/issue43899  opened by alvarezdqal

#43901: Add an empty annotations dict to all unannotated classes and m
https://bugs.python.org/issue43901  opened by larry

#43902: ssl module: add getter for SSL_CTX* and SSL*
https://bugs.python.org/issue43902  opened by christian.heimes

#43905: dataclasses.astuple does deepcopy on all fields
https://bugs.python.org/issue43905  opened by mandolaerik

#43907: pickle.py bytearray memoization bug with protocol 5
https://bugs.python.org/issue43907  opened by Carl.Friedrich.Bolz

#43908: array.array should remain immutable
https://bugs.python.org/issue43908  opened by gvanrossum

#43910: cgi.parse_header does not handle escaping correctly
https://bugs.python.org/issue43910  opened by msg555

#43912: http.client.BadStatusLine raised and response contains request
https://bugs.python.org/issue43912  opened by andymaier

#43913: unittest module cleanup functions not run unless tearDownModul
https://bugs.python.org/issue43913  opened by rtarpine

#43914: Highlight invalid ranges in SyntaxErrors
https://bugs.python.org/issue43914  opened by pablogsal

#43916: Check that new heap types cannot be created uninitialised
https://bugs.python.org/issue43916  opened by pablogsal

#43918: anext builtin docstring has no signature text or info about de
https://bugs.python.org/issue43918  opened by eriknw

#43921: test_ssl fails on Windows buildbots
https://bugs.python.org/issue43921  opened by pablogsal

#43922: Double dots in quopri transported emails
https://bugs.python.org/issue43922  opened by Julien Castiaux

#43923: Can't create generic NamedTuple as of py3.9
https://bugs.python.org/issue43923  opened by FHTMitchell

#43924: print unexpected values in infinite loop
https://bugs.python.org/issue43924  opened by rafihassan190041234

#43925: Add hangul syllables to unicodedata.decomposititon

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[gopinathinchennai01]

How does C++ fare in binary compatibility? Last time I checked it out (about 10 
years ago), there was completely none, every compiler's ABI 

https://www.credosystemz.com/courses/aws-training-chennai/
___
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/VGM6GMX2ZXPTOO33WTMG257SY4GPKXOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Sebastian Rittau]

Am 23.04.21 um 17:38 schrieb Nathaniel Smith:
I just got the reply below sent directly to my personal account, and 
I'm confused about what's going on. If it's just a one off I'll chalk 
it up to random internet weirdness, but if other folks are getting 
these too it might be something the list admins should look into? 
Or... something?


I also got one of these from the same sender, Same rambling, incoherent 
style, which I have always connected to mental issues. To protect both 
the sender and other list members, I would suggest to the list owners to 
manually unsubscribe the sender from the mailing list.


 - 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/6SRZW4BI2ONGD4NG2AID5F5GEYNMLAJE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[David Mertz]

This reads like a much worse variation on GPT-3.

On Fri, Apr 23, 2021, 11:52 AM Pablo Galindo Salgado 
wrote:

> I had I and still don't know what's going on. Mine was in a response to a
> release announcement so it was extra weird. Here is what I received:
>
> I have now formally filed a final lawsuit against the manager of the
>> python program company, because all of him is also a criminal act, and GNU
>> has EU legal certification, only my key can log in, and the key must be
>> recycled after the death of the holder, and gitlab allows to change It’s
>> the most basic and important crime to log in by people who support the
>> snatching of the key. I have to explain to you that the key is to be
>> registered and authenticated. My girlfriend wants to authenticate me
>> with this key, and my information is also there. The key is
>> authenticated, so I will not log in now, and I have submitted a lawsuit
>> against him and the authority of the key holder to the U.S. Supreme
>> Court and the European Union. I will not log in until there is a judgment
>> or the U.S. Supreme Court allows me. People will be litigated, and the
>> information that has been changed online will be found out, and I have
>> library files, I have all the original materials, please cooperate with me,
>> my key is called the Boss key, all websites of the program, companies,
>> Institutions, banks, third-party platforms, and only my keys can have
>> them, including patents and copyrights.
>
>
> On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith  wrote:
>
>> I just got the reply below sent directly to my personal account, and I'm
>> confused about what's going on. If it's just a one off I'll chalk it up to
>> random internet weirdness, but if other folks are getting these too it
>> might be something the list admins should look into? Or... something?
>>
>> -- Forwarded message -
>> From: Hoi lam Poon 
>> Date: Fri, Apr 23, 2021, 02:01
>> Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except*
>> [REPOST]
>> To: Nathaniel Smith 
>>
>>
>> Stop pretending, I can definitely get the key control file, your working
>> group, all past actions and instructions cannot be cleared in front of me
>> at all. You have been playing around for a few days, and I won’t stop you.
>> Your face? I won’t, you know, you can’t drive me away, and that file is
>> all, after I get it, you will be convicted even if you disband, I swear
>>
>> 在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：
>>
>>> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum 
>>> wrote:
>>> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
>>> >> Sure. This was in my list of reasons why the backwards compatibility
>>> >> tradeoffs are forcing us into awkward compromises. I only elaborated
>>> >> on it b/c in your last email you said you didn't understand why this
>>> >> was a problem :-). And except* is definitely useful. But I think there
>>> >> are options for 'except' that haven't been considered fully.
>>> >
>>> > Do you have any suggestions, or are you just telling us to think
>>> harder? Because we've already thought as hard as we could and within all
>>> the constraints (backwards compatibility and otherwise) we just couldn't
>>> think of a better one.
>>>
>>> The main possibility that I don't think we've examined fully is to
>>> make 'except' blocks fire multiple times when there are multiple
>>> exceptions. We ruled it out early b/c it's incompatible with nested
>>> EGs, but if flat EGs are better anyway, then the balance shifts around
>>> and it might land somewhere different. it's a tricky discussion
>>> though, b/c both the current proposal and the alternative have very
>>> complex implications and downsides. So we probably shouldn't get too
>>> distracted by that until after the flat vs nested discussion has
>>> settled down more.
>>>
>>> I'm not trying to filibuster here -- I really want some form of EGs to
>>> land. I think python has the potential to be the most elegant and
>>> accessible language around for writing concurrent programs, and EGs
>>> are a key part of that. I don't want to fight about anything; I just
>>> want to work together to make sure we have a full picture of our
>>> options, so we can be confident we're making the best choice.
>>>
>>> > The real cost here is that we would need a new "TracebackGroup"
>>> concept, since the internal data structures and APIs keep the traceback
>>> chain and the exception object separated until the exception is caught. In
>>> our early design stages we actually explored this and the complexity of the
>>> data structures was painful. We eventually realized that we didn't need
>>> this concept at all, and the result is much clearer, despite what you seem
>>> to think.
>>>
>>> I'm not talking about TracebackGroups (at least, I think I'm not?). I
>>> think it can be done with exactly our current data structures, nothing
>>> new.
>>>
>>> - When an EG is raised, build the traceback for just that EG while
>>> 

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Antoine Pitrou]

Perhaps an unconventional artistic performance ;-)
But more probably some kind of loony with a lot of free time...


On Fri, 23 Apr 2021 16:49:15 +0100
Pablo Galindo Salgado  wrote:
> I had I and still don't know what's going on. Mine was in a response to a
> release announcement so it was extra weird. Here is what I received:
> 
> I have now formally filed a final lawsuit against the manager of the python
> > program company, because all of him is also a criminal act, and GNU has EU
> > legal certification, only my key can log in, and the key must be recycled
> > after the death of the holder, and gitlab allows to change It’s the most
> > basic and important crime to log in by people who support the snatching of
> > the key. I have to explain to you that the key is to be registered and
> > authenticated. My girlfriend wants to authenticate me with this key, and
> > my information is also there. The key is authenticated, so I will not log
> > in now, and I have submitted a lawsuit against him and the authority of the
> > key holder to the U.S. Supreme Court and the European Union. I will not
> > log in until there is a judgment or the U.S. Supreme Court allows me.
> > People will be litigated, and the information that has been changed online
> > will be found out, and I have library files, I have all the original
> > materials, please cooperate with me, my key is called the Boss key, all
> > websites of the program, companies, Institutions, banks, third-party
> > platforms, and only my keys can have them, including patents and
> > copyrights.  
> 
> 
> On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith  wrote:
> 
> > I just got the reply below sent directly to my personal account, and I'm
> > confused about what's going on. If it's just a one off I'll chalk it up to
> > random internet weirdness, but if other folks are getting these too it
> > might be something the list admins should look into? Or... something?
> >
> > -- Forwarded message -
> > From: Hoi lam Poon 
> > Date: Fri, Apr 23, 2021, 02:01
> > Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except*
> > [REPOST]
> > To: Nathaniel Smith 
> >
> >
> > Stop pretending, I can definitely get the key control file, your working
> > group, all past actions and instructions cannot be cleared in front of me
> > at all. You have been playing around for a few days, and I won’t stop you.
> > Your face? I won’t, you know, you can’t drive me away, and that file is
> > all, after I get it, you will be convicted even if you disband, I swear
> >
> > 在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：
> >  
> >> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum 
> >> wrote:  
> >> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:  
> >> >> Sure. This was in my list of reasons why the backwards compatibility
> >> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> >> on it b/c in your last email you said you didn't understand why this
> >> >> was a problem :-). And except* is definitely useful. But I think there
> >> >> are options for 'except' that haven't been considered fully.  
> >> >
> >> > Do you have any suggestions, or are you just telling us to think  
> >> harder? Because we've already thought as hard as we could and within all
> >> the constraints (backwards compatibility and otherwise) we just couldn't
> >> think of a better one.
> >>
> >> The main possibility that I don't think we've examined fully is to
> >> make 'except' blocks fire multiple times when there are multiple
> >> exceptions. We ruled it out early b/c it's incompatible with nested
> >> EGs, but if flat EGs are better anyway, then the balance shifts around
> >> and it might land somewhere different. it's a tricky discussion
> >> though, b/c both the current proposal and the alternative have very
> >> complex implications and downsides. So we probably shouldn't get too
> >> distracted by that until after the flat vs nested discussion has
> >> settled down more.
> >>
> >> I'm not trying to filibuster here -- I really want some form of EGs to
> >> land. I think python has the potential to be the most elegant and
> >> accessible language around for writing concurrent programs, and EGs
> >> are a key part of that. I don't want to fight about anything; I just
> >> want to work together to make sure we have a full picture of our
> >> options, so we can be confident we're making the best choice.
> >>  
> >> > The real cost here is that we would need a new "TracebackGroup"  
> >> concept, since the internal data structures and APIs keep the traceback
> >> chain and the exception object separated until the exception is caught. In
> >> our early design stages we actually explored this and the complexity of the
> >> data structures was painful. We eventually realized that we didn't need
> >> this concept at all, and the result is much clearer, despite what you seem
> >> to think.
> >>
> >> I'm not talking about TracebackGroups (at least, I think I'm not?). 

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Pablo Galindo Salgado]

I had I and still don't know what's going on. Mine was in a response to a
release announcement so it was extra weird. Here is what I received:

I have now formally filed a final lawsuit against the manager of the python
> program company, because all of him is also a criminal act, and GNU has EU
> legal certification, only my key can log in, and the key must be recycled
> after the death of the holder, and gitlab allows to change It’s the most
> basic and important crime to log in by people who support the snatching of
> the key. I have to explain to you that the key is to be registered and
> authenticated. My girlfriend wants to authenticate me with this key, and
> my information is also there. The key is authenticated, so I will not log
> in now, and I have submitted a lawsuit against him and the authority of the
> key holder to the U.S. Supreme Court and the European Union. I will not
> log in until there is a judgment or the U.S. Supreme Court allows me.
> People will be litigated, and the information that has been changed online
> will be found out, and I have library files, I have all the original
> materials, please cooperate with me, my key is called the Boss key, all
> websites of the program, companies, Institutions, banks, third-party
> platforms, and only my keys can have them, including patents and
> copyrights.


On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith  wrote:

> I just got the reply below sent directly to my personal account, and I'm
> confused about what's going on. If it's just a one off I'll chalk it up to
> random internet weirdness, but if other folks are getting these too it
> might be something the list admins should look into? Or... something?
>
> -- Forwarded message -
> From: Hoi lam Poon 
> Date: Fri, Apr 23, 2021, 02:01
> Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except*
> [REPOST]
> To: Nathaniel Smith 
>
>
> Stop pretending, I can definitely get the key control file, your working
> group, all past actions and instructions cannot be cleared in front of me
> at all. You have been playing around for a few days, and I won’t stop you.
> Your face? I won’t, you know, you can’t drive me away, and that file is
> all, after I get it, you will be convicted even if you disband, I swear
>
> 在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：
>
>> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum 
>> wrote:
>> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
>> >> Sure. This was in my list of reasons why the backwards compatibility
>> >> tradeoffs are forcing us into awkward compromises. I only elaborated
>> >> on it b/c in your last email you said you didn't understand why this
>> >> was a problem :-). And except* is definitely useful. But I think there
>> >> are options for 'except' that haven't been considered fully.
>> >
>> > Do you have any suggestions, or are you just telling us to think
>> harder? Because we've already thought as hard as we could and within all
>> the constraints (backwards compatibility and otherwise) we just couldn't
>> think of a better one.
>>
>> The main possibility that I don't think we've examined fully is to
>> make 'except' blocks fire multiple times when there are multiple
>> exceptions. We ruled it out early b/c it's incompatible with nested
>> EGs, but if flat EGs are better anyway, then the balance shifts around
>> and it might land somewhere different. it's a tricky discussion
>> though, b/c both the current proposal and the alternative have very
>> complex implications and downsides. So we probably shouldn't get too
>> distracted by that until after the flat vs nested discussion has
>> settled down more.
>>
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land. I think python has the potential to be the most elegant and
>> accessible language around for writing concurrent programs, and EGs
>> are a key part of that. I don't want to fight about anything; I just
>> want to work together to make sure we have a full picture of our
>> options, so we can be confident we're making the best choice.
>>
>> > The real cost here is that we would need a new "TracebackGroup"
>> concept, since the internal data structures and APIs keep the traceback
>> chain and the exception object separated until the exception is caught. In
>> our early design stages we actually explored this and the complexity of the
>> data structures was painful. We eventually realized that we didn't need
>> this concept at all, and the result is much clearer, despite what you seem
>> to think.
>>
>> I'm not talking about TracebackGroups (at least, I think I'm not?). I
>> think it can be done with exactly our current data structures, nothing
>> new.
>>
>> - When an EG is raised, build the traceback for just that EG while
>> it's unwinding. This means if any C code peeks at exc_info while it's
>> in flight, it'll only see the current branch of the traceback tree,
>> but that seems fine.
>> - When the exception is caught and we go 

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Jelle Zijlstra]

I got a few of these too. I'm not sure anything can be done about it, since
the mailing list is publicly archived, so anyone could send emails to
anyone who posts here.

El vie, 23 abr 2021 a las 8:42, Nathaniel Smith () escribió:

> I just got the reply below sent directly to my personal account, and I'm
> confused about what's going on. If it's just a one off I'll chalk it up to
> random internet weirdness, but if other folks are getting these too it
> might be something the list admins should look into? Or... something?
>
> -- Forwarded message -
> From: Hoi lam Poon 
> Date: Fri, Apr 23, 2021, 02:01
> Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except*
> [REPOST]
> To: Nathaniel Smith 
>
>
> Stop pretending, I can definitely get the key control file, your working
> group, all past actions and instructions cannot be cleared in front of me
> at all. You have been playing around for a few days, and I won’t stop you.
> Your face? I won’t, you know, you can’t drive me away, and that file is
> all, after I get it, you will be convicted even if you disband, I swear
>
> 在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：
>
>> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum 
>> wrote:
>> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
>> >> Sure. This was in my list of reasons why the backwards compatibility
>> >> tradeoffs are forcing us into awkward compromises. I only elaborated
>> >> on it b/c in your last email you said you didn't understand why this
>> >> was a problem :-). And except* is definitely useful. But I think there
>> >> are options for 'except' that haven't been considered fully.
>> >
>> > Do you have any suggestions, or are you just telling us to think
>> harder? Because we've already thought as hard as we could and within all
>> the constraints (backwards compatibility and otherwise) we just couldn't
>> think of a better one.
>>
>> The main possibility that I don't think we've examined fully is to
>> make 'except' blocks fire multiple times when there are multiple
>> exceptions. We ruled it out early b/c it's incompatible with nested
>> EGs, but if flat EGs are better anyway, then the balance shifts around
>> and it might land somewhere different. it's a tricky discussion
>> though, b/c both the current proposal and the alternative have very
>> complex implications and downsides. So we probably shouldn't get too
>> distracted by that until after the flat vs nested discussion has
>> settled down more.
>>
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land. I think python has the potential to be the most elegant and
>> accessible language around for writing concurrent programs, and EGs
>> are a key part of that. I don't want to fight about anything; I just
>> want to work together to make sure we have a full picture of our
>> options, so we can be confident we're making the best choice.
>>
>> > The real cost here is that we would need a new "TracebackGroup"
>> concept, since the internal data structures and APIs keep the traceback
>> chain and the exception object separated until the exception is caught. In
>> our early design stages we actually explored this and the complexity of the
>> data structures was painful. We eventually realized that we didn't need
>> this concept at all, and the result is much clearer, despite what you seem
>> to think.
>>
>> I'm not talking about TracebackGroups (at least, I think I'm not?). I
>> think it can be done with exactly our current data structures, nothing
>> new.
>>
>> - When an EG is raised, build the traceback for just that EG while
>> it's unwinding. This means if any C code peeks at exc_info while it's
>> in flight, it'll only see the current branch of the traceback tree,
>> but that seems fine.
>> - When the exception is caught and we go to write back the traceback
>> to its __traceback__ attribute, instead "peek through" the EG and
>> append the built-up traceback entries onto each of the constituent
>> exceptions.
>>
>> You could get cleverer for efficiency, but that basic concept seems
>> pretty simple and viable to me. What am I missing?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>> ___
>> 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/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/
>> 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/4BAOL763Y2O2AXLEILYGHSNG2VMZJIN6/
> Code of Conduct: 

[Python-Dev] Anyone else gotten bizarre personal replies to mailing list posts?

[Nathaniel Smith]

I just got the reply below sent directly to my personal account, and I'm
confused about what's going on. If it's just a one off I'll chalk it up to
random internet weirdness, but if other folks are getting these too it
might be something the list admins should look into? Or... something?

-- Forwarded message -
From: Hoi lam Poon 
Date: Fri, Apr 23, 2021, 02:01
Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
To: Nathaniel Smith 


Stop pretending, I can definitely get the key control file, your working
group, all past actions and instructions cannot be cleared in front of me
at all. You have been playing around for a few days, and I won’t stop you.
Your face? I won’t, you know, you can’t drive me away, and that file is
all, after I get it, you will be convicted even if you disband, I swear

在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：

> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum  wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> on it b/c in your last email you said you didn't understand why this
> >> was a problem :-). And except* is definitely useful. But I think there
> >> are options for 'except' that haven't been considered fully.
> >
> > Do you have any suggestions, or are you just telling us to think harder?
> Because we've already thought as hard as we could and within all the
> constraints (backwards compatibility and otherwise) we just couldn't think
> of a better one.
>
> The main possibility that I don't think we've examined fully is to
> make 'except' blocks fire multiple times when there are multiple
> exceptions. We ruled it out early b/c it's incompatible with nested
> EGs, but if flat EGs are better anyway, then the balance shifts around
> and it might land somewhere different. it's a tricky discussion
> though, b/c both the current proposal and the alternative have very
> complex implications and downsides. So we probably shouldn't get too
> distracted by that until after the flat vs nested discussion has
> settled down more.
>
> I'm not trying to filibuster here -- I really want some form of EGs to
> land. I think python has the potential to be the most elegant and
> accessible language around for writing concurrent programs, and EGs
> are a key part of that. I don't want to fight about anything; I just
> want to work together to make sure we have a full picture of our
> options, so we can be confident we're making the best choice.
>
> > The real cost here is that we would need a new "TracebackGroup" concept,
> since the internal data structures and APIs keep the traceback chain and
> the exception object separated until the exception is caught. In our early
> design stages we actually explored this and the complexity of the data
> structures was painful. We eventually realized that we didn't need this
> concept at all, and the result is much clearer, despite what you seem to
> think.
>
> I'm not talking about TracebackGroups (at least, I think I'm not?). I
> think it can be done with exactly our current data structures, nothing
> new.
>
> - When an EG is raised, build the traceback for just that EG while
> it's unwinding. This means if any C code peeks at exc_info while it's
> in flight, it'll only see the current branch of the traceback tree,
> but that seems fine.
> - When the exception is caught and we go to write back the traceback
> to its __traceback__ attribute, instead "peek through" the EG and
> append the built-up traceback entries onto each of the constituent
> exceptions.
>
> You could get cleverer for efficiency, but that basic concept seems
> pretty simple and viable to me. What am I missing?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> 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/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/
> 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/4BAOL763Y2O2AXLEILYGHSNG2VMZJIN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith  wrote:

> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum  wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> on it b/c in your last email you said you didn't understand why this
> >> was a problem :-). And except* is definitely useful. But I think there
> >> are options for 'except' that haven't been considered fully.
> >
> > Do you have any suggestions, or are you just telling us to think harder?
> Because we've already thought as hard as we could and within all the
> constraints (backwards compatibility and otherwise) we just couldn't think
> of a better one.
>
> The main possibility that I don't think we've examined fully is to
> make 'except' blocks fire multiple times when there are multiple
> exceptions. We ruled it out early b/c it's incompatible with nested
> EGs, but if flat EGs are better anyway, then the balance shifts around
> and it might land somewhere different. it's a tricky discussion
> though, b/c both the current proposal and the alternative have very
> complex implications and downsides. So we probably shouldn't get too
> distracted by that until after the flat vs nested discussion has
> settled down more.
>
> I'm not trying to filibuster here -- I really want some form of EGs to
> land.


I'm very glad to hear that. It's been hard to know where you stand, because
you didn't even decline our invitation in October to work together on this,
and several later invitations to look at the implementation and try it with
Trio -- you just didn't reply.   The only responses I saw were public, on
this list, taking us right back to the drawing board (for example - the
suggestion you mention in the previous paragraph as
not-sufficiently-explored, actually appears in the rejected ideas section
of the PEP, and the reason for rejection is not that it's incompatible with
nesting). So thank you for clarifying that you are, ultimately, supportive
of our efforts.

We do realize that we didn't adequately credit you for the contributions of
your 2018 work to this PEP, and have now added an acknowledgements section
for that purpose. Apologies for that.

I'm confused about the flattening suggestion - above you talk about "flat
EG", but below about tracebacks. It's not clear to me whether you want EG
to be flat (ie no nesting of EGs) or just the traceback to be flat (but you
can still have a nested EG). I also don't know what problem you are trying
to solve with this.

Fortunately we're not at the whiteboard stage anymore, we have a fully
working implementation and you can use it to demonstrate any problems you
see with what we did.

Irit



> I think python has the potential to be the most elegant and
> accessible language around for writing concurrent programs, and EGs
> are a key part of that. I don't want to fight about anything; I just
> want to work together to make sure we have a full picture of our
> options, so we can be confident we're making the best choice.
>
> > The real cost here is that we would need a new "TracebackGroup" concept,
> since the internal data structures and APIs keep the traceback chain and
> the exception object separated until the exception is caught. In our early
> design stages we actually explored this and the complexity of the data
> structures was painful. We eventually realized that we didn't need this
> concept at all, and the result is much clearer, despite what you seem to
> think.
>
> I'm not talking about TracebackGroups (at least, I think I'm not?). I
> think it can be done with exactly our current data structures, nothing
> new.
>
> - When an EG is raised, build the traceback for just that EG while
> it's unwinding. This means if any C code peeks at exc_info while it's
> in flight, it'll only see the current branch of the traceback tree,
> but that seems fine.
> - When the exception is caught and we go to write back the traceback
> to its __traceback__ attribute, instead "peek through" the EG and
> append the built-up traceback entries onto each of the constituent
> exceptions.
>
> You could get cleverer for efficiency, but that basic concept seems
> pretty simple and viable to me. What am I missing?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
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/DO3ESI4RRXHSY7C3YC5VAEPN3XNN5XIY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Fri, 23 Apr 2021 at 10:31, Stephen J. Turnbull
 wrote:

> SJIS = 'shift_jisx0213'
>
> *Now* that is a personal protocol, serving the same function of
> telling me "this code deals with a legacy Japanese encoding" and
> implementing it behind the scenes.  But I don't see how that can be
> "defined close to its consumers", which are all over the place,
> including interactive sessions.
>
> What am I missing, and how might that be applied to Python?

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

Paul
___
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/E4F6APQCEU3CDP22FPVMGYG6NY4LJWON/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Chris Angelico]

On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith  wrote:
>
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum  wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> on it b/c in your last email you said you didn't understand why this
> >> was a problem :-). And except* is definitely useful. But I think there
> >> are options for 'except' that haven't been considered fully.
> >
> > Do you have any suggestions, or are you just telling us to think harder? 
> > Because we've already thought as hard as we could and within all the 
> > constraints (backwards compatibility and otherwise) we just couldn't think 
> > of a better one.
>
> The main possibility that I don't think we've examined fully is to
> make 'except' blocks fire multiple times when there are multiple
> exceptions.

Vanilla except blocks? Not sure if I'm misunderstanding, but that
could cause some problems. Consider:

trn.begin()
try:
...
except BaseException:
trn.rollback()
raise
else:
trn.commit()

What happens if multiple exceptions get raised? Will the transaction
be rolled back more than once? What gets reraised?

If I'm completely misunderstanding you here, my apologies.

ChrisA
___
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/SGFE3XG4COLBC747U7IBVWRKWAULY43C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Luciano Ramalho writes:

 > A HUGE insight I learned studying Go is that Protocols should be
 > defined near the code that CONSUMES it, and not near the code that
 > PROVIDES it. That's exactly the opposite of how we use ABCs, or
 > Java folks use interfaces (most of the time).

I don't see how that works for "public" protocols or ABCs in a
standard library (maybe I drank too much C in my tea?)  Yes, I write
wrapper classes or factory functions that deal with the niggling
details, even if they're only called once.  And of course that's near
where they're used.  For example, Python's "default" 'shift_jis' codec
uses an ancient version of the coded character set which errors on
about half the Shift JIS files I get nowadays, so I wrote:

def open_sjis(f, **kwargs):
return open(f, encoding='shift_jisx0213', **kwargs)

because I never remember the exact name, and Ireally don't care about
the Shift JIS version, only that it's Japanese and not UTF-8.  When
called, the wrapper function expresses what's going on more clearly
than the builtin call would.  But that seems more like good
programming workflow, not a protocol.

Continuing the example, 'open_sjis' ended up in a small personal "tool
box".  Then it quickly became not a function at all when I realized
that I wasn't going to ever add more "fixed" arguments, and I needed
the string in many other places:

SJIS = 'shift_jisx0213'

*Now* that is a personal protocol, serving the same function of
telling me "this code deals with a legacy Japanese encoding" and
implementing it behind the scenes.  But I don't see how that can be
"defined close to its consumers", which are all over the place,
including interactive sessions.

What am I missing, and how might that be applied to Python?

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/WKMYVOGVELPBYXRUG2HSO5XTM53XCDJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Nathaniel Smith]

On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum  wrote:
> On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
>> Sure. This was in my list of reasons why the backwards compatibility
>> tradeoffs are forcing us into awkward compromises. I only elaborated
>> on it b/c in your last email you said you didn't understand why this
>> was a problem :-). And except* is definitely useful. But I think there
>> are options for 'except' that haven't been considered fully.
>
> Do you have any suggestions, or are you just telling us to think harder? 
> Because we've already thought as hard as we could and within all the 
> constraints (backwards compatibility and otherwise) we just couldn't think of 
> a better one.

The main possibility that I don't think we've examined fully is to
make 'except' blocks fire multiple times when there are multiple
exceptions. We ruled it out early b/c it's incompatible with nested
EGs, but if flat EGs are better anyway, then the balance shifts around
and it might land somewhere different. it's a tricky discussion
though, b/c both the current proposal and the alternative have very
complex implications and downsides. So we probably shouldn't get too
distracted by that until after the flat vs nested discussion has
settled down more.

I'm not trying to filibuster here -- I really want some form of EGs to
land. I think python has the potential to be the most elegant and
accessible language around for writing concurrent programs, and EGs
are a key part of that. I don't want to fight about anything; I just
want to work together to make sure we have a full picture of our
options, so we can be confident we're making the best choice.

> The real cost here is that we would need a new "TracebackGroup" concept, 
> since the internal data structures and APIs keep the traceback chain and the 
> exception object separated until the exception is caught. In our early design 
> stages we actually explored this and the complexity of the data structures 
> was painful. We eventually realized that we didn't need this concept at all, 
> and the result is much clearer, despite what you seem to think.

I'm not talking about TracebackGroups (at least, I think I'm not?). I
think it can be done with exactly our current data structures, nothing
new.

- When an EG is raised, build the traceback for just that EG while
it's unwinding. This means if any C code peeks at exc_info while it's
in flight, it'll only see the current branch of the traceback tree,
but that seems fine.
- When the exception is caught and we go to write back the traceback
to its __traceback__ attribute, instead "peek through" the EG and
append the built-up traceback entries onto each of the constituent
exceptions.

You could get cleverer for efficiency, but that basic concept seems
pretty simple and viable to me. What am I missing?

-n

--
Nathaniel J. Smith -- https://vorpus.org
___
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/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/
Code of Conduct: http://python.org/psf/codeofconduct/