[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Mark Shannon]

Hi Guido,

Thanks for the feedback.

On 27/03/2021 10:15 pm, Guido van Rossum wrote:

Hi Mark,

Reading that spec will take some time. Can you please summarize the 
differences in English, in a way that is about as precise as PEP 634? I 
have some comments inline below as well.


On Sat, Mar 27, 2021 at 10:16 AM Mark Shannon > wrote:


Hi Oscar,

Thanks for the feedback.

On 27/03/2021 4:19 pm, Oscar Benjamin wrote:
 > On Sat, 27 Mar 2021 at 13:40, Mark Shannon mailto:m...@hotpy.org>> wrote:
 >>
 >
 > Hi Mark,
 >
 > Thanks for putting this together.
 >
 >> As the 3.10 beta is not so far away, I've cut down PEP 653 down
to the
 >> minimum needed for 3.10. The extensions will have to wait for 3.11.
 >>
 >> The essence of the PEP is now that:
 >>
 >> 1. The semantics of pattern matching, although basically
unchanged, are
 >> more precisely defined.
 >>
 >> 2. The __match_kind__ special attribute will be used to
determine which
 >> patterns to match, rather than relying on the collections.abc
module.
 >>
 >> Everything else has been removed or deferred.
 >
 > It would take me some time to compare exactly how this differs from
 > the current state after PEP 634 but I certainly prefer the
 > object-model based approach. It does seem that there are a lot of
 > permutations of how matching works but I guess that's just trying to
 > tie up all the different cases introduced in PEP 634.


It would be simpler if this was simply an informational PEP without 
proposing new features -- then we wouldn't have to rush.


It is about to close to that as I can get it. The change to using 
__match_kind__ requires some small changes to behaviour.




You could then propose the new __match_kind__ attribute in a separate 
PEP, written more in the style of PEP 634, without pseudo code.


I find it difficult to wrap my head around the semantics of 
__match_kind__ because it really represents a few independent flags 
(with some constraints) but all the text is written using explicit, 
hard-to-read bitwise and/or operations. Let me give it a try.


- Let's call the four flag bits by short names: SEQUENCE, MAPPING, 
DEFAULT, SELF.


SEQUENCE and MAPPING are for use when an instance of a class appears in 
the subject position (i.e., for `match x`, we look for these bits in 
`type(x).__match_kind__`). Neither of these is set by default. At most 
one of them should be set.


- If SEQUENCE is set, the subject is treated like a sequence (this is 
set for list, tuple and other sequences, but not for str, bytes and 
bytearray).


- Similarly, MAPPING means the subject should be treated as a mapping, 
and is set for dict and other mapping types.


The DEFAULT and SELF flags are for use when a class is used in a class 
pattern (i.e., for `case cls(...)` we look for these bits in 
`cls.__match_kind__`). At most one of these should be set. DEFAULT is 
set on class `object` and anything that doesn't explicitly clear it.


- If DEFAULT is set, semantics of PEP 634 apply except for the special 
behavior enabled by the SELF flag.


- If SELF is set, `case cls(x)` binds the subject to x, and no other 
forms of `case cls(...)` are allowed.


`case cls():` is always allowed, regardless of flags.



- If neither DEFAULT nor SELF is set, `case cls(...)` does not take 
arguments at all.


Please correct any misunderstandings I expressed here! (And please 
include some kind of summary like this in your PEP.)


I think you expressed it well. I'll add a more informal overview section 
to the PEP.




Also, I think that we should probably separate this out in two separate 
flag sets, one for subjects and one for class patterns -- it is pretty 
confusing to merge the flag sets into a single value when their 
applicability (subject or class pattern) is so different.


That would require two different special attributes, which adds bulk 
without adding any value.


   __match_kind__ = MATCH_SEQUENCE | MATCH_DEFAULT

should be clear to anyone familiar with integer flags.




 >> The PEP now has only the slightest changes to semantics, which
should be
 >> undetectable in normal use. For those corner cases where there is a
 >> difference, it is to make pattern matching more robust.
 >
 > Maybe I misunderstood but it looks to me as if this (PEP 653) changes
 > the behaviour of a mapping pattern in relation to extra keys. In PEP
 > 634 extra keys in the target are ignored e.g.:
 >
 > obj = {'a': 1, 'b': 2}
 > match(obj):
 >      case {'a': 1}:
 >           # matches obj because key 'b' is ignored
 >
 > In PEP 634 the use of **rest is optional if it is desired to
catch the
 > other keys but does not affect matching. Here in PEP 653 there is the
 > pseudocode:
 >
 > # A pattern not including a double-star pattern:
 > if $kind & MATCH_MA

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Nick Coghlan]

On Mon, 29 Mar 2021, 7:47 pm Mark Shannon,  wrote:

[Guido wrote]

> >
> > Also, I think that we should probably separate this out in two separate
> > flag sets, one for subjects and one for class patterns -- it is pretty
> > confusing to merge the flag sets into a single value when their
> > applicability (subject or class pattern) is so different.
>
> That would require two different special attributes, which adds bulk
> without adding any value.
>
> __match_kind__ = MATCH_SEQUENCE | MATCH_DEFAULT
>
> should be clear to anyone familiar with integer flags.
>

The combined flags might be clearer if the class matching flags were
"MATCH_CLS_DEFAULT" and "MATCH_CLS_SELF"

Without that, it isn't obvious that they're modifying the way class
matching works.

Alternatively, given Guido's suggestion of two attributes, they could be
"__match_container__" and "__match_class__".

The value of splitting them is that they should compose better under
inheritance - the container ABCs could set "__match_container__"
appropriately without affecting the way "__match_class__" is set.

An implementation might flatten them out at class definition time for
optimisation reasons, but it wouldn't need to be part of the public API.

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

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Guido van Rossum]

On Mon, Mar 29, 2021 at 7:35 AM Nick Coghlan  wrote:

> On Mon, 29 Mar 2021, 7:47 pm Mark Shannon,  wrote:
>
> [Guido wrote]
>
>> >
>> > Also, I think that we should probably separate this out in two separate
>> > flag sets, one for subjects and one for class patterns -- it is pretty
>> > confusing to merge the flag sets into a single value when their
>> > applicability (subject or class pattern) is so different.
>>
>> That would require two different special attributes, which adds bulk
>> without adding any value.
>>
>> __match_kind__ = MATCH_SEQUENCE | MATCH_DEFAULT
>>
>> should be clear to anyone familiar with integer flags.
>>
>
> The combined flags might be clearer if the class matching flags were
> "MATCH_CLS_DEFAULT" and "MATCH_CLS_SELF"
>
> Without that, it isn't obvious that they're modifying the way class
> matching works.
>
> Alternatively, given Guido's suggestion of two attributes, they could be
> "__match_container__" and "__match_class__".
>
> The value of splitting them is that they should compose better under
> inheritance - the container ABCs could set "__match_container__"
> appropriately without affecting the way "__match_class__" is set.
>

+1

An implementation might flatten them out at class definition time for
> optimisation reasons, but it wouldn't need to be part of the public API.
>

Since the two flag sets are independent the bult is only apparent. Few
classes would need to set one of these, let alone two. In the C layer they
may be combined as part oftp_flags (assuming there are enough free bits).

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

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[Theallredman via Python-Dev]

No need to be condescending. Trust me when I say I know the bit length relates 
to the collision resistance. Also trust me when I say there are other 
dimensions upon which to consider one hash algo over another other then just 
collision resistance such as, power consumption, execution time, whether or not 
the algorithm suffers from length extension attacks.

I'm assuming the reason MD5 and SHA1 were both disallowed were because they 
have been proven to have a collision resistance less then 1/2 their bit length. 
But this is not the case for SHA224. It is just a truncated version of SHA256 
and thus the underlying algorithm is just as strong as SHA256 except that you 
can expect to find a collision in about 16 bits of work less.

So going back to my actual question SHA224 is disallowed in record files 
because it's bit length is less then 256?___
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/NKMWTOLR5GVSKGYWPBHB7FGMD33IYCNK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[Paul Moore]

On Mon, 29 Mar 2021 at 17:40, Theallredman via Python-Dev
 wrote:
> So going back to my actual question SHA224 is disallowed in record files 
> because it's bit length is less then 256?

It doesn't look like it's ever been excluded. The only explicit
exclusions are MD5 and SHA1 as you point out. Do you have a particular
reason to want to use SHA224? Pretty much everyone is using SHA256, as
far as I know.

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

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[Paul Bryan]

I suggest that SHA224 does not qualify as "SHA256 or better".
Truncating any hash should not be considered equivalent or better.
Reductio ad absurdum: truncate to 128 bits, 16 bits, 8 bits, or 1 bit.

On Mon, 2021-03-29 at 08:15 +, Theallredman via Python-Dev wrote:
> No need to be condescending.  Trust me when I say I know the bit
> length relates to the collision resistance.  Also trust me when I say
> there are other dimensions upon which to consider one hash algo over
> another other then just collision resistance such as, power
> consumption, execution time, whether or not the algorithm suffers
> from length extension attacks.
> 
> I'm assuming the reason MD5 and SHA1 were both disallowed were
> because they have been proven to have a collision resistance less
> then 1/2 their bit length.  But this is not the case for SHA224.  It
> is just a truncated version of SHA256 and thus the underlying
> algorithm is just as strong as SHA256 except that you can expect to
> find a collision in about 16 bits of work less.
> 
> So going back to my actual question SHA224 is disallowed in record
> files because it's bit length is less then 256?
> ___
> 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/NKMWTOLR5GVSKGYWPBHB7FGMD33IYCNK/
> 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/2RGX3KHUWHTL55RJ252RSY67HXCNWOLY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Yury Selivanov]

Just a few comments to add to Irit's response.

On Sat, Mar 27, 2021 at 11:03 AM Paul Sokolovsky  wrote:
[..]
> Bottom line: this seems like a Trio's special-purpose feature, with
> good wishes of becoming the de facto standard.

The bottom line is that Trio nurseries were proven to be a very useful
and intuitive primitive. But the error handling API around them is
unintuitive and hard to use. Now that we want to add an equivalent of
nurseries to asyncio (we'll likely call them Task Groups) we need to
sort out the error handling mechanism, finally.

> From my PoV, a solution which doesn't add particular complex behavior
> into the language core, but allows to plug it in, and keep whole thing
> more explicit, is something that "works better".

I understand your PoV, but there's a point where building explicit
complex APIs becomes so detrimental to the overall usability that
there's a warrant for solving the problem in syntax and with builtin
types.

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

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

[Larry Hastings]

On 3/27/21 4:23 PM, Jelle Zijlstra wrote:
Now, PEP 649 doesn't actually fix this at the moment, since it still 
resolves all annotations in the global scope, but that's easily fixed 
by removing the special case in 
https://github.com/larryhastings/co_annotations/blob/co_annotations/Python/compile.c#L3815 
.



Maybe not "easily fixed", because in my experience dealing with the 
compiler and symtable modules in CPython, nothing is easy. That special 
case was instrumental in getting the first revision working.


Nevertheless, you're right in that it shouldn't be necessary, and "round 
2" of 649 will remove it.



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

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[Theallredman via Python-Dev]

Thank you.  I can't think of a compelling reason someone would want to choose 
SHA224 over SHA256 in the context of wheel generation.  It just that the PEPs 
are usually pretty explicit and SHA224 seemed to be implicitly excluded from 
RECORD files.  And I'm considering the details of making a pretty pedantic 
wheel generation PEP517 backend.

Eldon

‐‐‐ Original Message ‐‐‐
On Monday, March 29, 2021 2:16 PM, Paul Moore  wrote:

> On Mon, 29 Mar 2021 at 17:40, Theallredman via Python-Dev
> python-dev@python.org wrote:
>
> > So going back to my actual question SHA224 is disallowed in record files 
> > because it's bit length is less then 256?
>
> It doesn't look like it's ever been excluded. The only explicit
> exclusions are MD5 and SHA1 as you point out. Do you have a particular
> reason to want to use SHA224? Pretty much everyone is using SHA256, as
> far as I know.
>
> 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/NB6MLDDDJHRTRMOEWDFG5IYGZCP65K6V/
Code of Conduct: http://python.org/psf/codeofconduct/