[Python-Dev] Re: Possible bug in `re` module in Python 3.11?

[MRAB]

On 2022-10-26 09:17, Piotr Waszkiewicz wrote:

Hi,
I would like to ask your guidance as I'm entirely sure whether the problem I'm 
experiencing should be posted in CPython's repo as a bug issue.
I've tried using newly released Python 3.11 interpreter in some of my projects and one of 
them failed to start with "RuntimeError: invalid SRE code" error.

Looking into implementation of one of the dependencies I've found out that the 
issue has been found out by a maintainer and fixed 
(https://github.com/pydicom/pydicom/issues/1658).
It looks like this particular regexp caused the `re.compile()` method to raise:

```
re.compile(
 r"(?P^([01][0-9]|2[0-3]))"
 r"((?P([0-5][0-9]))?"
 r"(?(5)(?P([0-5][0-9]|60))?)"
 r"(?(7)(\.(?P([0-9]{1,6})?))?))$"
 )
```

I've checked and this hasn't been an issue in all previous Python interpreter 
versions, starting from 3.6 (the oldest I've checked).
What's more the regex i correctly recognized and does not cause any issues in 
other regexp implementations, e.g. the online tool https://regex101.com/

Could somebody help me decide whether this is indeed a bug?


It's definitely a bug.

If it was complaining about the pattern then it might or might not be a 
bug, you'd need to check more closely, but "invalid SRE code" is 
definitely a bug.

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

[Python-Dev] Re: Adding new escapes to regex module

[MRAB]

On 2022-08-17 17:34, MRAB wrote:

On 2022-08-17 08:25, Serhiy Storchaka wrote:

16.08.22 23:24, MRAB пише:
Other regex implementations have escape sequences for horizontal 
whitespace (`\h` and `\H`) and vertical whitespace (`\v` and `\V`).


The regex module already supports `\h`, but I can't use `\v` because it 
represents `\0x0b', as it does in the re module.


Now that someone has asked for it, I'm trying to find a nice way of 
adding it, and I'm currently thinking that maybe I could use `\y` and 
`\Y` instead as they look a little like `\v` and `\V`, and, also, 
vertical whitespace is sort-of in the y-direction.


As far as I can tell, only ProgressSQL uses them, and, even then, it's 
for what everyone else writes as `\b` and `\B`.


I want the regex module to remain compatible with the re module, in case 
they get added there sometime in the future.


Opinions?


I do not like introducing escapes which are not supported in other RE
implementations. There is a chance of future conflicts.

Java broke compatibility in Java 8 by redefining \v from a single
vertical tab character to the vertical whitespace class. I am not sure
that it is a good example that we should follow, because different
semantic of \v in raw and non-raw strings is a potential source of bugs.
But with special flag which controls the meaning of \v it may be more safe.

Horizontal whitespace can be matched by [
\t\xA0\u1680\u180e\u2000-\u200a\u202f\u205f\u3000] in re or [\t\p{Zs}]
in regex. Vertical whitespace can be matched by
[\n\x0b\f\r\x85\u2028\u2029]. Note that there is a dedicated Unicode
category for horizontal whitespaces (excluding the tab itself), but not
for vertical whitespaces, it means that vertical whitespaces are less
important.

In any case it is simple to introduce special Unicode categories and use
\p{ht} and \p{vt} for horizontal and vertical whitespaces.

>
It's not just Java. Perl supports all 4 of \h, \H, \v and \V. That might 
be why Java 8 changed.
I've found that Perl has \p{HorizSpace} and \p{VertSpace}, so I'm going 

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

[Python-Dev] Re: Adding new escapes to regex module

[MRAB]

On 2022-08-17 08:25, Serhiy Storchaka wrote:

16.08.22 23:24, MRAB пише:
Other regex implementations have escape sequences for horizontal 
whitespace (`\h` and `\H`) and vertical whitespace (`\v` and `\V`).


The regex module already supports `\h`, but I can't use `\v` because it 
represents `\0x0b', as it does in the re module.


Now that someone has asked for it, I'm trying to find a nice way of 
adding it, and I'm currently thinking that maybe I could use `\y` and 
`\Y` instead as they look a little like `\v` and `\V`, and, also, 
vertical whitespace is sort-of in the y-direction.


As far as I can tell, only ProgressSQL uses them, and, even then, it's 
for what everyone else writes as `\b` and `\B`.


I want the regex module to remain compatible with the re module, in case 
they get added there sometime in the future.


Opinions?


I do not like introducing escapes which are not supported in other RE
implementations. There is a chance of future conflicts.

Java broke compatibility in Java 8 by redefining \v from a single
vertical tab character to the vertical whitespace class. I am not sure
that it is a good example that we should follow, because different
semantic of \v in raw and non-raw strings is a potential source of bugs.
But with special flag which controls the meaning of \v it may be more safe.

Horizontal whitespace can be matched by [
\t\xA0\u1680\u180e\u2000-\u200a\u202f\u205f\u3000] in re or [\t\p{Zs}]
in regex. Vertical whitespace can be matched by
[\n\x0b\f\r\x85\u2028\u2029]. Note that there is a dedicated Unicode
category for horizontal whitespaces (excluding the tab itself), but not
for vertical whitespaces, it means that vertical whitespaces are less
important.

In any case it is simple to introduce special Unicode categories and use
\p{ht} and \p{vt} for horizontal and vertical whitespaces.
It's not just Java. Perl supports all 4 of \h, \H, \v and \V. That might 

be why Java 8 changed.
___
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/UPDWUF3RDVKG7LNKSS4LHCSF7XA32H6W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Adding new escapes to regex module

[MRAB]

On 2022-08-16 22:14, Barry Scott wrote:

> On 16 Aug 2022, at 21:24, MRAB  wrote:
> 
> Other regex implementations have escape sequences for horizontal whitespace (`\h` and `\H`) and vertical whitespace (`\v` and `\V`).
> 
> The regex module already supports `\h`, but I can't use `\v` because it represents `\0x0b', as it does in the re module.


You seem to be mixing the use \ as the escape for strings and the \ that re 
uses.
Is it the behaviour that '\' becomes '\\' that means this is 
a breaking change?

Won't this work?
```
re.compile('\v:\\v')
# which is the same as
re.compile(r'\x0b:\v')
```

Some languages, e.g. Perl, have a dedicated syntax for writing regexes, 
and they take `\n` (a backslash followed by 'n') to mean "match a newline".


Other languages, including Python, use string literals and can contain 
an actual newline, but they also take `\n` (a backslash followed by 'n') 
to mean "match a newline".


Thus:

>>> print(re.match('\n', '\n')) # Literal newline.

>>> print(re.match('\\n', '\n')) # `\n` sequence.


On the other hand:

>>> print(re.match('\b', '\b')) # Literal backspace.

>>> print(re.match('\\b', '\b')) # `\b` sequence, which means a word 
boundary.

None
>>>

The problem is that the re and regex modules already have the `\v` (a 
backslash followed by 'v') sequence to mean "match the '\v' character", so:


re.compile('\v')

and:

re.compile('\\v')

mean exactly the same.


> Now that someone has asked for it, I'm trying to find a nice way of adding 
it, and I'm currently thinking that maybe I could use `\y` and `\Y` instead as 
they look a little like `\v` and `\V`, and, also, vertical whitespace is sort-of 
in the y-direction.
> 
> As far as I can tell, only ProgressSQL uses them, and, even then, it's for what everyone else writes as `\b` and `\B`.
> 
> I want the regex module to remain compatible with the re module, in case they get added there sometime in the future.
> 
> Opinions?

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

[Python-Dev] Adding new escapes to regex module

[MRAB]

Other regex implementations have escape sequences for horizontal 
whitespace (`\h` and `\H`) and vertical whitespace (`\v` and `\V`).


The regex module already supports `\h`, but I can't use `\v` because it 
represents `\0x0b', as it does in the re module.


Now that someone has asked for it, I'm trying to find a nice way of 
adding it, and I'm currently thinking that maybe I could use `\y` and 
`\Y` instead as they look a little like `\v` and `\V`, and, also, 
vertical whitespace is sort-of in the y-direction.


As far as I can tell, only ProgressSQL uses them, and, even then, it's 
for what everyone else writes as `\b` and `\B`.


I want the regex module to remain compatible with the re module, in case 
they get added there sometime in the future.


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

[Python-Dev] Re: Switching to Discourse

[MRAB]

On 21/07/2022 18:53, Mats Wichmann wrote:

On 7/21/22 11:11, Mariatta wrote:



On Thu, Jul 21, 2022 at 10:05 AM Skip Montanaro
mailto:skip.montan...@gmail.com>> wrote:

I have a perhaps stupid question. Is Discord the same as
discuss.python.org , just by another
name? I find the similarity in
names a bit confusing.

 
It's not the same. discuss.python.org  is an

instance of Discourse.

Discord is something completely something else.
 Indeed the similarity is confusing.



As the wag said,

"These are only two hard things in computer science, cache invalidation
and naming things".



Another wag said:

There are only two hard things in computer science: cache 
invalidation, naming things, and off-by-one errors.



Add in IP lawyers and I think naming may have advanced to being the hardest.


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

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

[MRAB]

On 13/07/2022 12:12, h.vetin...@gmx.com wrote:

Also the GH bot is using DD/MM/ date format :-( whyy?


Because github is international, and everyone but the US seems to agree that
```
/\
   /  \
  /\
 / day  \
/\
   /  \
  /month   \
 /__\
/\
   /   year   \
  /\
```
is preferable to
```
__
   /  \
  /month   \
 /__\
/\
   /  \
  /\
 / day  \
 ___/\___
/\
   /   year   \
  /\
```


I much prefer -MM-DD (or .MM.DD) because:

1. It's consistent with HH:MM:SS and other instances where there are 
multiple units (they go from largest to smallest).


2. It's easier to sort them.

3. It removes the confusion over whether it's DD/MM/ or MM/DD/.
___
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/QIEETJHYC5Z7AXXSE6NBKY3CJG7VN6SO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

[MRAB]

On 2022-05-28 16:03, MRAB wrote:

On 2022-05-28 13:17, Serhiy Storchaka wrote:

28.05.22 14:57, Damian Shaw пише:

That PR seems to make \' and \" not special in general right?

I think this is a more limited proposal, to only change the behavior 
when \ is at the end of a string, so the only behavior difference would 
never receiving the error "SyntaxError: EOL while scanning string literal"


In which case there should be no backwards compatibility issue.


How do you know that it is at the end of a string?


It would also affect triple-quoted strings.

Here's an idea: prefix rr ("really raw") that would treat all
backslashes literally.
Here's something I've just realised.


Names in Python are case-sensitive, yet the string prefixes are 
case-/insensitive/.


Why?
___
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/3FZJWRIZQQDNMJYJ2SOZFW3R7NVHKNC4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Raw strings ending with a backslash

[MRAB]

On 2022-05-28 13:17, Serhiy Storchaka wrote:

28.05.22 14:57, Damian Shaw пише:

That PR seems to make \' and \" not special in general right?

I think this is a more limited proposal, to only change the behavior 
when \ is at the end of a string, so the only behavior difference would 
never receiving the error "SyntaxError: EOL while scanning string literal"


In which case there should be no backwards compatibility issue.


How do you know that it is at the end of a string?


It would also affect triple-quoted strings.

Here's an idea: prefix rr ("really raw") that would treat all 
backslashes literally.

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

[Python-Dev] Re: [RELEASE] The first Python 3.11 beta (3.11.0b1) is available - Feature freeze is here

[MRAB]

On 2022-05-08 04:22, Pablo Galindo Salgado wrote:
We did it, team!! After quite a bumpy release process and a bunch of 
last-time fixes, we have reached **beta 1** and **feature freeze**. What 
a ride eh? You can get the shiny new release artefacts from here:


https://www.python.org/downloads/release/python-3110b1/

## This is a beta preview of Python  3.11

Python 3.11 is still in development. 3.11.0b1 is the first of four 
planned beta release previews. Beta release previews are intended to 
give the wider community the opportunity to test new features and bug 
fixes and to prepare their projects to support the new feature release.


We **strongly encourage** maintainers of third-party Python projects to 
**test with 3.11** during the beta phase and report issues found to [the 
Python bug tracker](https://bugs.python.org ) 
as soon as possible.  While the release is planned to be feature 
complete entering the beta phase, it is possible that features may be 
modified or, in rare cases, deleted up until the start of the release 
candidate phase (Monday, 2021-08-02).  Our goal is to have no ABI 
changes after beta 4 and as few code changes as possible after 
3.11.0rc1, the first release candidate.  To achieve that, it will be 
**extremely important** to get as much exposure for 3.11 as possible 
during the beta phase.


Please keep in mind that this is a preview release and its use is 
**not** recommended for production environments.


# Major new features of the 3.11 series, compared to 3.10

Python 3.11 is still in development.  This release, 3.11.0b1 is the 
**first** of four beta releases.
Beta release previews are intended to give the wider community the 
opportunity to test new features and bug fixes and to prepare their 
projects to support the new feature release.


Many new features for Python 3.11 are still being planned and written.  
Among the new major new features and changes so far:


* [PEP 657](https://www.python.org/dev/peps/pep-0657/ 
) -- Include Fine-Grained 
Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/ 
) -- Exception Groups and except*
* [PEP 673](https://www.python.org/dev/peps/pep-0673/ 
)  -- Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/) 
-- Variadic Generics
* [PEP 680](https://www.python.org/dev/peps/pep-0680/ 
)-- tomllib: Support for 
Parsing TOML in the Standard Library
* [PEP 675](https://www.python.org/dev/peps/pep-0675/) 
-- Arbitrary Literal String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/ 
)-- Marking individual 
TypedDict items as required or potentially-missing


FYI, 2 of these PEP links are missing/wrong:

https://www.python.org/dev/peps/pep-0646/ (Variadic Generics) is at 
https://peps.python.org/pep-0646/


https://www.python.org/dev/peps/pep-0675/ (Arbitrary Literal String 
Type) is at https://peps.python.org/pep-0675/

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

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

[MRAB]

On 2022-04-30 03:17, Greg Ewing wrote:

On 30/04/22 5:25 am, MRAB wrote:

I was going to suggest "metastable". Too late? :-)


What, the API is balanced on a knife edge and likely to collapse
into something else if you sneeze too hard?

There's a possibility that the universe might be metastable, so a 
metastable API might not be that big a deal.

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

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

[MRAB]

On 2022-04-29 18:02, Guido van Rossum wrote:
On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin > wrote:


On 29. 04. 22 16:32, Victor Stinner wrote:
 > Ok, let me start with the serious business: API name.
 >
 > I'm not comfortable with "semi-stable". Python already has a "limited
 > API" and a "stable ABI". Just by its name, it's unclear what
 > "semi-stable" means.
 >
 > Honestly, I would be more comfortable with the name: "unstable API".
 > It would be clear that the API *can* change often. People who want to
 > know exactly the backward compatibility warranties can dig into the
 > API documentation to learn more about it.
 >
 > "Unstable API" is also the name the Guido proposed for
PyCode_New() last year:
 >
 > * Proposal: declare "unstable APIs"
 >

https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/


 > * Making code object APIs unstable
 >

https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/


 >
 > Victor


Nick Coghlan argued against that term:

 > "unstable" is the wrong term. We already have an unstable API
tier: the
 > internal API, which can change even in maintenance releases. The
value of
 > the new tier is that it is "semi stable": stable in maintenance
releases,
 > unstable in feature releases.

—

https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/




But I also like “unstable” better than “semi-stable”. Splitting the
internals into “private”/“internal” and “unstable” seems reasonable.


I think picking "semi-stable" would be giving in to the OCD nerd in all 
of us. :-) While perhaps technically less precise, "unstable" is the 
catchy name with the right association. (And yes, we should keep it 
stable within bugfix releases, but the name doesn't need to reflect that 
detail.) The "internal API" isn't an API at all (except for CPython core 
developers and contributors). The "unstable API" would definitely be an 
*API* for users outside the core.


So let's please go with "unstable".


I was going to suggest "metastable". Too late? :-)
___
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/5B7ES3BZJTKORNCT6LWLRHM7UNSFCKYU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[MRAB]

On 2022-04-26 06:32, Larry Hastings wrote:


Sorry, folks, but I've been busy the last few days--the Language Summit 
is Wednesday, and I had to pack and get myself to SLC for PyCon,   
I'll circle back and read the messages on the existing threads 
tomorrow.  But for now I wanted to post "the wonderful third option" for 
forward class definitions we've been batting around for a couple of days.


The fundamental tension in the proposal: we want to /allocate/ the 
object at "forward class" time so that everyone can take a reference to 
it, but we don't want to /initialize/ the class (e.g. run the class 
body) until "continue class" time.  However, the class might have a 
metaclass with a custom __new__, which would be responsible for 
allocating the object, and that isn't run until after the "class body".  
How do we allocate the class object early while still supporting custom 
metaclass.__new__ calls?


So here's the wonderful third idea.  I'm going to change the syntax and 
semantics a little, again because we were batting them around quite a 
bit, so I'm going to just show you our current thinking.


The general shape of it is the same.  First, we have some sort of 
forward declaration of the class.  I'm going to spell it like this:


forward class C

just for clarity in the discussion.  Note that this spelling is also viable:

class C


I don't like that because it looks like you've just forgotten the colon.

Perhaps:

class C: ...

[snip]
___
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/IZAWCYPHGD2ZVB2U6TVIBM5XKGY5KQS6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[MRAB]

On 2022-04-18 01:23, Steven D'Aprano wrote:

On Sun, Apr 17, 2022 at 08:35:06PM +0100, MRAB wrote:

You could return only the current attributes by default, but the extra 
attributes on demand. (Slightly strange, but backwards-compatible.) 
Slicing could also return what was requested, e.g. t[ : 4] would return 
the first 4, t[ : 5] the first 5, t[ : ] all of them, etc. (Again, 
strange, but backwards-compatible.)


Having len(a) and len(a[:]) be different would not be "slightly
strange", it would go against 30+ years of the expectation that the
empty slice makes a shallow copy of tuples and other sequences.


But apart from that? :-)
___
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/7U7E7E5QOBOUVOC4HUQ525FWA4X3WFKM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[MRAB]

On 2022-04-17 18:20, Pablo Galindo Salgado wrote:

Hi,

We are currently debating in gh-88116 
(https://github.com/python/cpython/issues/88116 
)
what's the best way forward to update the APIs in the inspect module to 
include the new position information.


These APIs are inspect.getframeinfo, inspect.getouterframes, 
inspect.getinnerframes, inspect.stack and inspect.trace.


The problem is that these APIs return a named tuple that now needs to 
include several new attributes (or one 4 tuple for
the positions). Being named tuples, if we add a new attribute, existing 
unpackings of the tuple will now fail because there
are more elements or the elements are in different positions. Also, it 
will be quite weird to add the new attributes at the

end but leave the line number at the beginning.

What's the best way to proceed here? The suggested way is to create a 
namedtuple subclass that adds the extra attributes
but doesn't allow indexed access to it (there is a precedent to this in 
how we handled updating os.stat_result). I personally
find this quite confusing but it certainly works. There may be other 
options.


What do you think?


Why not allow indexed access to the extra attributes?

You could return only the current attributes by default, but the extra 
attributes on demand. (Slightly strange, but backwards-compatible.) 
Slicing could also return what was requested, e.g. t[ : 4] would return 
the first 4, t[ : 5] the first 5, t[ : ] all of them, etc. (Again, 
strange, but backwards-compatible.)

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

[Python-Dev] Re: walrus operator and expression

[MRAB]

On 2022-03-28 23:59, Chris Angelico wrote:

On Tue, 29 Mar 2022 at 09:53, Ethan Furman  wrote:


In the following bit of code:


 while s := input.read(MAXBINSIZE):
 while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
 s += ns
 line = binascii.b2a_base64(s)
 output.write(line)

I'm getting this error on the second line:

 cannot use assignment expressions with expression

Can somebody explain why that isn't working?



I'm getting a good hint from the exception in 3.11:


while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):

   File "", line 1
 while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
   ^^
SyntaxError: cannot use assignment expressions with expression

Looks like it's counting "len(s) < MAXBINSIZE and ns" as the
assignment target. Parens around the second half would solve that.

I think that's because assignment has low precedence, lower than that of 
the RHS, because the RHS needs to be evaluated before the assignment, 
but the consequence of that it that the preceding expression will also 
get evaluated first, consuming the identifier, leaving a trailing ':='. 
It's easier just to complain and require on parentheses than to back up 
while parsing.

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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[MRAB]

On 2022-03-27 19:52, Dan Stromberg wrote:


On Sat, Mar 26, 2022 at 5:58 PM Ethan Furman > wrote:


[apologies for the late post, just found this in my drafts folder]

On 2/7/22 12:49 AM, Stéfane Fermigier wrote:

 > 3. Overall, I think the days where "battery included" was a
positive argument are over

I strongly disagree.  Being able to download something and
immediately get something to work and see results is hugely
rewarding; on the other hand, having to research, find, compare &
contrast available third-party modules (especially for
new-comers) can be extremely discouraging.


It might make sense to have CPython's release cadence decoupled from the 
Standard Library's release cadence.  That is, maybe they should be 
separate downloads.


On the other hand, it's nice to get it all in one go. Perhaps the 
installer could gain controls to download optional parts of the standard 
library or update those parts that have been installed.

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

[Python-Dev] Re: I want to contribute to Python.

[MRAB]

On 2022-02-06 13:18, Ezekiel Adetoro wrote:

Hello,
My name is Ezekiel, and it is my desire to start contributing to Python, be 
part of the core development of Python. I have forked the CPython and cloned 
it. What is the next step I need to do?


Look on the issue tracker for a bug that you can fix.
___
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/HEA7LYZLM5Q6KSURG2PG7PBNKOR37RM7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[MRAB]

On 2022-01-18 21:58, Pablo Galindo Salgado wrote:
The code that computes the lines is already quite complex (to the point 
that has to do some AST analysis and post-parsing) so I am quite worried 
to introduce a lot of complexity in this area. I am fine doing something 
that we can easily check for (spawns all the line) but I would be 
against having to start doing even more analysis (especially for things 
that are not AST-based).


Take into account that code that displays exceptions need to be very 
resilient because it can be called in some tricky situations and 
validating that all the code works correctly is very hard, and complex 
to maintain.


As I said, I think I would be supportive of considering adding a check 
for the full line, but I think that adding more complexity here is quite 
dangerous.


It might be enough to check that there's only whitespace before the 
first ^ and only whitespace optionally followed by a comment (#) after 
the last ^ on that line.


On Tue, 18 Jan 2022 at 21:49, Patrick Reader <_...@pxeger.com 
> wrote:


On 18/01/2022 20:41, Pablo Galindo Salgado wrote:

We cannot base the computation on a % because is possible that the
location markers are relevant
but the variables, function names or constructs are just very
large. I think that the idea of "spawns
the whole line" is sensible, though.

On Tue, 18 Jan 2022 at 20:32, Steve Dower mailto:steve.do...@python.org>> wrote:


Omitting the line of ^ where over x% (75%? 90%?) of characters
on the
line would be marked would be fine by me.


It would also need to take into account cases where a line contains
an inline comment, which does not contribute to the code producing
the error, but where all of the rest of the line (the code) is the
source of the error and highlighting it is not useful

# test.py:

code_that_causes_an_error # a comment

$ python3.11 test.py

Traceback (most recent call last):
   File "test.py", line 1, in 
     code_that_causes_an_error # a comment
     ^
NameError: name 'code_that_causes_an_error' is not defined

(the traceback shown is from a current `main` build)


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

[Python-Dev] Re: Function Prototypes

[MRAB]

On 2021-12-23 19:04, asleep.c...@gmail.com wrote:

Hello and thank you for the much needed feedback.

One thing that you must consider is that function prototypes
have a few implications beyond typing but it seems like you're
only looking at it as a tool for type hinting. The interpreter will
create a function prototype object regardless of if you forget your
decorator, it needs to pass something to the decorator after all.

After reading through your reply, I am seeing that the main concern
is the bloat added by the lambda keyword. My decision to use lambda
instead of introducing a special syntax was one that required heavy
deliberation. I ultimately decided to stick with lambda because it was
consistent with the prototype statement form. The fact that lambda
is hard to type has been felt by almost everyone who has ever used
Python, this isn't just a problem that would be introduced by
function prototypes. PEP 677 has taken the lazy approach to solving
this issue and has prioritized type hinting over functionality. PEP 667
also suggests the usage of => for lambdas which would likely
never be accepted because of the confusion it would cause.
As someone who has used typing with Python, I do think that a new
callable syntax is needed, but I truly believe that PEP 677 is taking the
wrong approach.

So what if we broke every Python program in existence by creating a
new lambda syntax, how would it look? This question is particularly
hard to answer because the body and annotations both need to be
optional. Our best bet is an augmented form of the PEP 677 syntax
that allows you to add a body. Here is an example:

(a: int) -> int: a ** 2

But of course this causes ambiguity when the return annotation and
body are both omitted. One thing that I did consider is simply treating
it like a tuple if there is no return annotation AND there is no body, but
that might lead to confusion. Another thing that I considered is a different
prefix than lambda:

$(a: int) -> int: a ** 2


Usually the suggestion is to use 'def':

def (a: int) -> int: a ** 2
___
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/AKS4IHJJFDV24QZNMVMFZR72H5ORU3TB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.10 vs 3.8 performance degradation

[MRAB]

On 2021-12-19 20:06, Tigran Aivazian wrote:

So far I have narrowed it down to a block of code in solve.py doing a lot of multi-threaded FFT 
(i.e. with fft(..., threads=6) of pyFFTW), as well as numpy exp() and other functions and pure 
Python heavy list manipulation (yes, lists, not numpy arrays). All of this together (or some one 
part of it, yet to be discovered) is behaving as if there was some global lock taken behind the 
scene (i.e. inside Python interpreter), so that when multiple instances of the script (which I 
loosely called "threads" in previous posts, but here correct myself as the word 
"threads" is used more appropriately in the context of FFT in this message) are executed 
in parallel, they slow each other down in 3.10, but not so in 3.8.

So this is definitely a very interesting 3.10 degradation problem. I will try 
to investigate some more tomorrow...

"is behaving as if there was some global lock taken behind the scene 
(i.e. inside Python interpreter)"?


The Python interpreter does have the GIL (Global Interpreter Lock). It 
can't execute Python bytecodes in parallel, but timeshares between the 
threads.


The GIL is released during I/O and by some extensions while they're 
processing, but when they want to return, or if they want to use the 
Python API, they need to acquire the GIL again.


The only way to get true parallelism in CPython is to use 
multiprocessing, where it's running in multiple processes.

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

[Python-Dev] Re: Optimizing literal comparisons and contains

[MRAB]

On 2021-11-29 00:52, Christopher Barker wrote:
I will frequently do simple computation with literals to make my code 
more clear:


t = 2 * 3600  # 2 hours in seconds

But I see no need to optimize this kind of thing -- it would never be in 
a tight loop.


The suggestion was specifically about optimising comparison of literals 
such as 1 < 2, which is not done at present, and the objection is 
basically YAGNI - that kind of thing is just too rare to be worth it.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2VS4ZPFYAYVOG4BBHRWAFIEH7CU62X4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[MRAB]

On 2021-11-14 17:17, Christopher Barker wrote:
On Sat, Nov 13, 2021 at 2:03 PM > wrote:


def 횑퓮햑풍표():

__

     try:

픥e헅핝횘︴ = "Hello"

함픬r퓵ᵈ﹎ = "World"

     ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!")

     except 퓣핪ᵖｅ햤헿ᵣ햔횛 as ⅇ헑c:

풑rℹₙₜ("failed: {}".핗헼ʳᵐªｔ(ᵉ퐱퓬))


Wow. Just Wow.

So why does Python apply  NFKC normalization to variable names?? I can't 
for the life of me figure out why that would be helpful at all.


The string methods, sure, but names?

And, in fact, the normalization is not used for string comparisons or 
hashes as far as I can tell.



[snip]

It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL LETTER 
E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH ACUTE}", 
which are different ways of writing the same thing.


Unfortunately, it goes too far, because it's unlikely that we want "ᵖ" 
("\N{MODIFIER LETTER SMALL P}') to be equivalent to "P" ("\N{LATIN 
CAPITAL LETTER P}".

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

[Python-Dev] Re: containment and the empty container

[MRAB]

On 2021-11-09 00:27, Cameron Simpson wrote:

On 08Nov2021 23:32, MRAB  wrote:
>On 2021-11-08 22:10, Cameron Simpson wrote:
>>>{} in {1:'a', 'b':2]   <-- TypeError because of hashability
>>>set() in {1, 2, 'a', 'b'}  <-- ditto
>>>[] in ['a', 'b', 1, 2]  <-- False
>>
>>Right. Also, the members are not dicts or sets, respectively.
>>
>More precisely, none of the keys are an empty set.

Aye, for the examples. But I was highlighting that the set/lists members
are a different type from the left-hand thing (empty set/list). A
category error, to my mind.

>>>SomeFlag.nothing in SomeFlag.something  <--  ???
>>
>>I would expect "true", myself.
>>
>I'm not so sure.
>
>A flag could be a member, but could a set of flags?

Probably one flavour should raise a TypeError then with this comparison.
I wouldn't want "member flag present in SomeFlag.something" and
"set-of-members present in SomeFlag.something" to both be valid, there
is so much scope for ambiguity/accidents there. I would rather punt the
"set-of-members present" off to "<"/"<=" if we want to say either (which
of course we should be able to say).

So: To me "SomeFlag.nothing" is a set of flags, empty. _Not_ an
individual flag (a member).

Which means that _if_ we had a subset/strict-subset test, I'd want
"SomeFlag.nothing in" to raise a TypeError, since we should use the
subset/strict-subset operator for that flavour.

Which means I'm backtracking to TypeError, not 'true". _Provided" this
is a "member in set" comparison.

Of course, I think resently we don't distinguish a flag combination name
(".nothing", ".red_and_blue"==0b11) from single flags overtly. If there
are trite, _fast_, way to test count_of_flags(flag_value)==1 ? i.e. can
"members" be automatically distinguished from flag combinations
(obviously such a definition would exclude a
combination-of-just-1-flag).


Are you asking whether there's a quick way to check if only 1 bit is set?

If yes, then the answer is yes:

    bitflags != 0 and (bitflags & (bitflags - 1)) == 0

>>I was going to digress about "<" vs "in". For sets, "<" means subset 
>>and

>>"in" means "element in set". That isn't exactly parallel to flags. What
>>if "SomeFlag.nothing < SomeFlag.something" meant a subset test? Would we
>>need "in" at all? Or is "<" out of the picture because FLags, or at
>>least IntFlags, might do numeric-like stuff with "<"?
>>
>Actually, '<' means _proper_ subset (not ==), '<=' means subset 
>(possibly ==).


Point taken. I'll try to be more precise. Warning: I'll become more
wordy.

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

[Python-Dev] Re: containment and the empty container

[MRAB]

On 2021-11-08 22:10, Cameron Simpson wrote:

Note: I know you understand all this, I'm not "explaining" how things
work below, I'm explaining how/why I think about how these work.

On 08Nov2021 13:43, Ethan Furman  wrote:

When is an empty container contained by a non-empty container?

[...]

For example:

{} in {1:'a', 'b':2]   <-- TypeError because of hashability
set() in {1, 2, 'a', 'b'}  <-- ditto


Right. Also, the members are not dicts or sets, respectively.


More precisely, none of the keys are an empty set.


[] in ['a', 'b', 1, 2]  <-- False


The members are not lists.


'' in 'a1b2'  <-- True


This is because "in" isn't measuring a setlike membership (I mean here,
"subset"). It is looking for a substring. Compare:

 >>> 'abc' in 'abcdef'
 True
 >>> 'abc' in 'abxcdef'
 False

So str is not a set, because of its sequential nature.


SomeFlag.nothing in SomeFlag.something  <--  ???


I would expect "true", myself.


I'm not so sure.

A flag could be a member, but could a set of flags?

Personally, I have never had a use for '' in 'some string' being True, 

[...]
So, does Flag adhere to set theory, or is just happenstance that some 
operators work the same for both groups?


I would expect flags to be like sets. I've always thought of them that
way - independent presence/absence of things. They're not sequenced. (If
they're packed into ints there's some sequencing in the storage behind
the scenes, but that isn't part of my model the rest of the time.)

Can we have `SomeFlag.nothing in SomeFlag.something` be `False`, or 
would that be too surprising?


I'd be surprised by this. I would rather a clean "subset" notion here.

I was going to digress about "<" vs "in". For sets, "<" means subset and
"in" means "element in set". That isn't exactly parallel to flags. What
if "SomeFlag.nothing < SomeFlag.something" meant a subset test? Would we
need "in" at all? Or is "<" out of the picture because FLags, or at
least IntFlags, might do numeric-like stuff with "<"?

Actually, '<' means _proper_ subset (not ==), '<=' means subset 
(possibly ==).

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

[Python-Dev] Re: Documenting Python versioning and stability expectations

[MRAB]

On 2021-10-16 22:39, Oscar Benjamin wrote:

On Fri, 15 Oct 2021 at 14:12, Petr Viktorin  wrote:


Most of this is, hopefully, just capturing existing tribal knowledge, but:

[snip]


Micro Versions
--

A new micro version marks *bugfix* and *security* releases.
These releases are managed for stability; only fixes for known problems are
included in them, and Python's interfaces do not change in new micro
versions.

Generally, it is enough for third-party libraries to test with one
release of a minor version -- ideally the latest one.
For example, a library tested with Python 3.5.10 may reasonably claim to be
compatible with Python 3.5 in general.


I would just like to note that in SymPy we had problems a few times
because of changes made to typing in the 3.5.x series. The problem was
that CI tested the newest version of 3.5.x but many users were using
older versions and many features were added in micro releases e.g.
(random example from docs) typing.NoReturn has:

   New in version 3.5.4.
   New in version 3.6.2.

What that meant is that if a contributor had used NoReturn as a type
hint then because SymPy's CI only tested the most recent 3.5.x it
would not be noticed in PR review that SymPy had become unimportable
in 3.5.0.

This was not a major problem: where I saw complaints it seemed that
users were happy to upgrade to a newer Python 3.5.x. In general though
those changes do not match the explanation shown above. I welcome the
documentation around what kind of changes will be made in different
releases but just to be clear, should this preclude things like adding
typing.NoReturn in micro releases? (I hope so.)

Wasn't there a change in a micro version of Python 2? I can't remember 
the details, but from hindsight it was seen as a mistake that should not 
be repeated.

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

[Python-Dev] Re: Packing a long list of numbers into memory

[MRAB]

On 2021-10-10 19:20, Gregory P. Smith wrote:



On Sun, Oct 10, 2021 at 7:25 AM Facundo Batista 
mailto:facundobati...@gmail.com>> wrote:


Hello everyone!

I need to pack a long list of numbers into shared memory, so I thought
about using `struct.pack_into`.

Its signature is

     struct.pack_into(format, buffer, offset, v1, v2, ...)

I have a long list of nums (several millions), ended up doing the
following:

     struct.pack_into(f'{len(nums)}Q', buf, 0, *nums)

However, passing all nums as `*args` is very inefficient [0]. So I
started wondering why we don't have something like:

     struct.pack_into(format, buffer, offset, values=values)

which would receive the list of values directly.

Is that because my particular case is very uncommon? Or maybe we *do*
want this but we don't have it yet? Or do we already have a better way
of doing this?

Thanks!

[0] https://linkode.org/#95ZZtVCIVtBbx72dURK7a4



My first reaction on seeing things like this is "Why not use a numpy.array?"

Does what you have really need to be a long list?  If so, that's already 
a huge amount of Python object storage as it is. Is it possible for your 
application to have kept that in a numpy array for the entirety of the 
data lifetime? 
https://numpy.org/doc/stable/reference/routines.array-creation.html 



I'm not saying the stdlib shouldn't have a better way to do this by not 
abusing *args as an API, just that other libraries solve the larger 
problem of data-memory-inefficiency in their own way already.


/(neat tricks from others regarding stdlib array, shm, & memoryview even 
if... not ideal)/


Maybe what's needed is to add, say, '*' to the format string to indicate 
that multiple values should come from an iterable, e.g.:


struct.pack_into(f'{len(nums)}*Q', buf, 0, nums)

in this case len(nums) from the nums argument.
___
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/6ZJ6B7ILRWH5BU4UAMNGOEJ5AIWRNFEJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[MRAB]

On 2021-10-06 02:12, Barry Warsaw wrote:

What do the PEP authors think about `except group`?  Bikeshedding aside, that’s 
still the best alternative I’ve seen.  It’s unambiguous, self-descriptive, and 
can’t be confused with unpacking syntax.


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

[Python-Dev] Re: PEP 654 except* formatting

[MRAB]

On 2021-10-04 16:02, Jonathan Goble wrote:
On Mon, Oct 4, 2021 at 1:24 AM Guido van Rossum > wrote:


On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

Therefore my vote is for requiring `except* E` and keeping
`except *E` as a SyntaxError.


You can't do that with our current lexer+parser.


Then what is the purpose of this thread? I understood from the OP that 
the question was which to allow and which to prohibit. If it's 
impossible to require either or prohibit either because the lexer/parser 
can't tell the difference, then it's going to end up as a never-ending 
style argument just like C pointers, so what are we even discussing? 
(Other than an entirely different syntax, of course, which now seems 
like the logical way to go if we can't enforce a single way to do it 
with the original proposal.)
The key phrase is """in any case we need to settle on a convention that 

we use in documentation, etc.""".
___
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/RYJTNZVMNF54XVUIE4MMN6TXS2XRPTXO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[MRAB]

On 2021-10-04 07:12, Greg Ewing wrote:

On 4/10/21 6:23 pm, Guido van Rossum wrote:
On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote:


Therefore my vote is for requiring `except* E` and keeping `except
*E` as a SyntaxError.

You can't do that with our current lexer+parser.


I don't think it would be desirable in any case. The separation of
tokens into alphanumeric and non-alphanumeric is deeply embedded in
every Python programmer's brain by now, and we shouldn't mess with
it.


It's not just a Python thing.
___
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/NTAXBGISW5CGLR2CWQ7HN4CCMDNF6OPG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[MRAB]

On 2021-10-03 18:50, Brandt Bucher wrote:

Łukasz Langa wrote:

My idea is this:
try:
...
except group E as e:
...
except group E1, T2 as e:
...
Should be doable given the magical match-case contextual keywords precedent. 
This looks nice and is explicit, since you will always get an ExceptionGroup 
instance under `e`.


Heh, we crossed posts with the soft keywords. I like your idea (“except group”) 
better than mine (“except each”).
If we want to use an existing keyword instead of a soft keyword, how 

about "except in E as e:".

The disadvantage, as I see it, from a linguistic point of view, is that 
"except in" could be read as "excluding", but, then, so could "except 
each" ("excluding each of these") and "except group" ("excluding this 
group").

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

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[MRAB]

On 2021-09-26 00:14, jack.jan...@cwi.nl wrote:
I’m getting increasingly worried about the future of Python, and those 
worries have been exacerbated by the new yearly release rhythm, and the 
lack of a stable C-API that is full enough to entice extension writers 
to use it.


PyPI packages and wheels are targeted to specific Python versions, which 
means that any project that depends on some of the larger extension 
packages (of which there are many, and many of which are must-have for 
many projects) now start lagging Python versions by years, because 
somewhere deep down in the dependency graph there is something that is 
still stuck at Python 3.8 (for example). I fully understand that 3.8 is 
good enough for the developers of that package, and that they have more 
pressing things to do than porting to 3.9 or 3.10, but it now keeps any 
project or package that depends on their software on 3.8 as well.


And I also fully understand that some other developer who creates a new 
package that is essential to my application only targets the current 
Python release, or maybe one release back, but now if I need both the 
new package and and older one I’m up the well-known creek without a paddle.


Building packages from source has become pretty much impossible 
nowadays, especially if your project is multi-platform and needs to 
interface to specific hardware, and you want to do the right thing with 
CI/CD builds and all that. On Linux/MacOS you have a chance when you try 
to specify all the dependencies for third party libraries and what not, 
but on Windows you’re dead in the water. And that is assuming you have 
the time and are smart enough to back port the new package to the old 
Python release, or the old package to the new Python release (and for 
the latter there’s probably a good reason why the developers haven’t 
done so already). Before you know it you have to install a couple of 
graphics card APIs for some obscure AI feature used by something you’ve 
never heard of, Cython for something else, and obscure vendor libraries 
for something else again.


I think we really need to come up with some scheme whereby extension 
packages become more long-lived than a single Python release...


You mean, something like the Python ABI (PEP 384, Stable Application 
Binary Interface)?

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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[MRAB]

On 2021-09-09 00:29, Rob Cliffe via Python-Dev wrote:



On 08/09/2021 21:21, Christopher Barker wrote:


[snip]
NOTE: my objection to “bchr”, whether as a builtin or not is not the 
functionality, it’s the name.



[snip]

Why not byte() ?

I happened to need to convert an integer to a byte recently and I settled on
      bytes((i,))
I don't know if I missed a more elegant solution (suggestions welcome),
but if I could write
      byte(i)
that would feel more Pythonic to me.


Well, I tend to see a byte as a value like an int.

If you slice a bytestring, you'd expect to get a bytestring, and you do.

If you subscript a bytestring, you expect to get a byte. You get an int, 
and that suggests that a byte is an int. (In Python 2 you got a 
bytestring, in Python 3 you get an int.)


The name could be misleading as byte(i) would return a bytestring, not a 
byte/int.

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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[MRAB]

On 2021-09-08 13:37, Victor Stinner wrote:

On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano  wrote:

>>> bytes.from_int(121404708502361365413651784, 'little')
# should return b'Hello world'


Really? I don't know anyone serializing strings as a "bigint" number.
Did you already see such code pattern in the wild? Usually, bytes are
serialized as... bytes, no? Sometimes, bytes are serialized as base64
or hexadecimal to go through into an ASCII ("7-bit") bytestream. But I
don' recall any file format serializing bytes as a single large
decimal number.


Well, we already have int.from_bytes. What's that used for?

Adding the opposite conversion does make sense to me. If the number is 
0..255, and maybe the byteorder can be omitted in that case, then it 
seems like a reasonable solution to me.

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[MRAB]

On 2021-08-24 17:55, Patrick Reader wrote:

On 24/08/2021 06:27, Steven D'Aprano wrote:

Wouldn't that attempt to resolve global y, rather than local y? Unless
there is a change to the current behaviour of the compiler, I think you 
need to fool the compiler:


   if False: y = 0  # anywhere inside the function is okay

Time to add a `nonnonlocal` statement ;)


Or perhaps use "not nonlocal"? :-)
___
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/USZ5FOQ6WF365VC7C4ZH4K4TR5AW2X2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Problems with dict subclassing performance

[MRAB]

On 2021-08-15 22:50, Marco Sulla wrote:

On Sun, 15 Aug 2021 at 23:33, Tim Peters 
wrote:ople have said now, including me, they had no idea what

you meant.by "I pretend your immediate excuses". It's not a complaint
that it's expressed inelegantly, but that they can't make _any_ sense
of it. By my count, this is at least the second time you've declined
to explain what you meant, but instead implied the person who said
they couldn't understand it was being dishonest.


I repeat, even the worst AI will understand from the context what I
meant. But let me do a very rude example:


What if I said to Steven "I pretend immediate suck my $%#$"? Do you
think you and the others will not understand the sense? :D

C'Mon, you are offending my poor intelligence.

As I wanted to say, I pretend from Steven his excuses for his
insinuation, immediately. Is this clear now, or must I take an English
course at Cambridge?

I can figure it out, but I still find it very unclear and oddly phrased, 
and I'm a native English speaker of  years. And the sentence "I 
pretend from Steven his excuses for his insinuation, immediately" is 
just as odd.

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

[Python-Dev] Re: New __main__.rst

[MRAB]

On 2021-08-10 03:14, Jack DeVries wrote:

There have been a series of requests to enhance the current __main__.rst
document :

bpo-17359 
bpo-24632 
bpo-39452 

So, I rewrote it! I went ahead and hosted it on my website for you all to
easily take a look: https://jackdevries.com/pydoc__main__/library/__main__.html

Of course, you can go directly to the GitHub PR instead:
https://github.com/python/cpython/pull/26883

For reference, here is a link to the current document:
https://docs.python.org/3/library/__main__.html

This is a major change, so I'm thankful for anyone who can take the time to
review it. I am a new cpython contributor, so advice for how to push this ahead
is also welcome. For example, should I break this up into multiple PRs at this
point?

Point of grammar: "Each of these mechanisms are related" should be "Each 
of these mechanisms is related". You might think that it's "are" because 
it follows "mechanisms", but it's "Each (something) is".

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

[Python-Dev] Re: The repr of a sentinel

[MRAB]

On 2021-05-24 01:37, Luciano Ramalho wrote:

Sorry about my detour into the rejected idea of a factory function.

But how about this class-based API?

class NotGiven(Sentinel):
 pass


Now I can use NotGiven as the sentinel, and its default repr is .

The repr of other singletons are the names of those singletons, eg. 
"None", so why "" instead of "NotGiven"?



Behind the scenes we can have a SentinelMeta metaclass with all the
magic that could be required--including the default __repr__ method.


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

[Python-Dev] Re: GDB not breaking at the right place

[MRAB]

On 2021-05-23 14:56, Skip Montanaro wrote:

I strongly suggest to only build Python with -O0 when using gdb. -Og
enables too many optimizations which makes gdb less usable.


Thanks, Victor. It never made sense to me that you would want any
optimizations enabled when truly debugging code (as opposed to wanting
debug symbols and a sane traceback in production code).

I'm getting more convinced that the problem I'm seeing is a GCC/GDB
thing, particularly because I can move the erroneous stopping point by
changing the GCC optimization level. I'll probably open a bugzilla
report just so it's on that team's radar screen. In the meantime, to
get going again I wrote a crude script which maps the
file:function:label form to file:linenumber form. That way I can
save/restore breakpoints across GDB sessions and still avoid problems
when the offsets to specific instructions change.

When I want to step through the regex module, I turn off optimisation, 
because any optimisation could move things around or combine things, 
making single-stepping difficult, and this is with Microsoft Visual Studio.


Just turn off optimisation when you want to single-step.
___
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/EWHXLCO4DKWGM3CZPZC2YFTNZPUSUSIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[MRAB]

On 2021-05-08 01:43, Pablo Galindo Salgado wrote:
Some update on the numbers. We have made some draft implementation to 
corroborate the
numbers with some more realistic tests and seems that our original 
calculations were wrong.

The actual increase in size is quite bigger than previously advertised:

Using bytes object to encode the final object and marshalling that to 
disk (so using uint8_t) as the underlying

type:

BEFORE:

❯ ./python -m compileall -r 1000 Lib > /dev/null
❯ du -h Lib -c --max-depth=0
70M     Lib
70M     total

AFTER:
❯ ./python -m compileall -r 1000 Lib > /dev/null
❯ du -h Lib -c --max-depth=0
76M     Lib
76M     total

So that's an increase of 8.56 % over the original value. This is storing 
the start offset and end offset with no compression

whatsoever.


[snip]

I'm wondering if it's possible to compromise with one position that's 
not as complete but still gives a good hint:


For example:

  File "test.py", line 6, in lel
return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)
  ^

TypeError: 'NoneType' object is not subscriptable

That at least tells you which subscript raised the exception.


Another example:

  Traceback (most recent call last):
File "test.py", line 4, in 
  print(1 / x + 1 / y)
  ^
  ZeroDivisionError: division by zero

as distinct from:

  Traceback (most recent call last):
File "test.py", line 4, in 
  print(1 / x + 1 / y)
  ^
  ZeroDivisionError: division by zero
___
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/4RGQALI6T6HBNRDUUEYX4FA2YKTZDBNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[MRAB]

On 2021-05-07 22:56, Larry Hastings wrote:

On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
Given that column numbers are not very big compared with line numbers, 
we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library 
and we found that the overhead of all pyc files is:


* If we use shorts, the total overhead is ~3% (total size 28MB and the 
extra size is 0.88 MB).
* If we use chars. the total overhead is ~1.5% (total size 28 MB and 
the extra size is 0.44MB).


One of the disadvantages of using chars is that we can only report 
columns from 1 to 255 so if an error happens in a column
bigger than that then we would have to exclude it (and not show the 
highlighting) for that frame. Unsigned short will allow

the values to go from 0 to 65535.


Are lnotab entries required to be a fixed size?  If not:

if column < 255:
     lnotab.write_one_byte(column)
else:
     lnotab.write_one_byte(255)
     lnotab.write_two_bytes(column)


I might even write four bytes instead of two in the latter case,


A slight improvement would be:

if column < 255:
 lnotab.write_one_byte(column)
else:
 lnotab.write_one_byte(255)
 lnotab.write_two_bytes(column - 255)
___
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/UJYYDMXCM5TM7GOSIPMK7GOWNC25GL7W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[MRAB]

On 2021-05-07 22:45, Pablo Galindo Salgado wrote:

Hi there,

We are preparing a PEP and we would like to start some early discussion 
about one of the main aspects of the PEP.


The work we are preparing is to allow the interpreter to produce more 
fine-grained error messages, pointing to

the source associated to the instructions that are failing. For example:

Traceback (most recent call last):

   File "test.py", line 14, in 

 lel3(x)

 ^^^

   File "test.py", line 12, in lel3

 return lel2(x) / 23

    ^^^

   File "test.py", line 9, in lel2

 return 25 + lel(x) + lel(x)

 ^^

   File "test.py", line 6, in lel

 return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)

  ^

TypeError: 'NoneType' object is not subscriptable


The cost of this is having the start column number and end column number 
information for every bytecode instruction
and this is what we want to discuss (there is also some stack cost to 
re-raise exceptions but that's not a big problem in
any case). Given that column numbers are not very big compared with line 
numbers, we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library 
and we found that the overhead of all pyc files is:


* If we use shorts, the total overhead is ~3% (total size 28MB and the 
extra size is 0.88 MB).
* If we use chars. the total overhead is ~1.5% (total size 28 MB and the 
extra size is 0.44MB).


One of the disadvantages of using chars is that we can only report 
columns from 1 to 255 so if an error happens in a column
bigger than that then we would have to exclude it (and not show the 
highlighting) for that frame. Unsigned short will allow

the values to go from 0 to 65535.


[snip]How common are lines are longer than 255 characters, anyway?

One thought: could the stored column position not include the 
indentation? Would that help?

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

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[MRAB]

On 2021-04-29 18:56, Ethan Furman wrote:

On 4/29/21 10:52 AM, Antoine Pitrou wrote:
  > On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
  >> On 2021-04-29 18:19, Ethan Furman wrote:

  >>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
  >>>
  >>> GvR:
  >>> 
  >>>> One thing I discovered when developing this example: there doesn't 
seem to be a flag to
  >>>> represent 0 (zero), i.e. "no flags".  And foo(0) is a type error 
(even though it works
  >>>> fine at runtime).
  >>>
  >>> Which raises the question:  Do we want to have a standard name for stdlib 
Flags when no flags are set?
  >>>
  >>> What should we call it?
  >>>
  >>> - NONE
  >>>
  >>> - ZERO
  >>>
  >>> - EMPTY
  >>>
  >>> - ???
  >>>
  >> Definitely NONE. At some point I might even add it to the regex module! :-)
  >
  > Not to confuse with None, which will not be equal to NONE.  Hmm...
  >
  > Perhaps NONE_SET or ALL_UNSET?
  >
  > (also, why the ALL_CAPS?)

Since Enum members are constants, ALL_CAPS is recommended for their naming 
scheme.


And the flags of the re module have always been ALL_CAPS.
___
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/DCKIHYXVZIRABF43M3NX75RZAXIQ3AOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[MRAB]

On 2021-04-29 18:19, Ethan Furman wrote:

An excerpt from bpo-31369: re.RegexFlag and `__all__`

GvR:

  > One thing I discovered when developing this example: there doesn't seem to 
be a flag to
  > represent 0 (zero), i.e. "no flags".  And foo(0) is a type error (even 
though it works
  > fine at runtime).

Which raises the question:  Do we want to have a standard name for stdlib Flags 
when no flags are set?

What should we call it?

- NONE

- ZERO

- EMPTY

- ???


Definitely NONE. At some point I might even add it to the regex module! :-)
___
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/RBZ7ILB64FBFEHFQNHKGHJLYNUU3DMET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: str() vs format(): trivia question

[MRAB]

On 2021-04-20 20:42, Ethan Furman wrote:

On 4/20/21 12:01 PM, Guido van Rossum wrote:
  > On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:

  >> Moving forward, I'm not sure having format() and str() ever be different
  >> is a good idea, especially since users who need, for example, Color.RED
  >> to be '1' can simply add a `__str__ = int.__str__` to their own custom
  >> base IntEnum class and be good to go.  If we deprecate the current behavior
  >> now we could change it in 3.12.
  >>
  >> Thoughts?

  > So to be clear, that one user wants f"{Color.RED}" to return "1" and not
  > " Color.RED" (or  something like that). And you want f"{Color.RED}" and
  > str(Color.RED) to return the same value. Then together that means that
  > str(Color.RED) must also return "1".
  >
  > Did I get that right? And are you happy with that outcome?

Almost right. They should both return `Color.RED`.  Any users who want 
something different will need to do some work on
their end:

  class MyIntEnum(IntEnum):
  def __format__ = int.__format__

  class Color(MyIntEnum):
  RED = 1

  format(Color.RED)
  # '1'

The deprecation period will give that user, and others like them, time to add 
their own Enum base classes with the
`__format__` method they desire.


Couldn't the format accept 'd' if they want an int, i.e. f"{Color.RED:d}"?
___
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/IZH66WUEQJVEFBFBCOXXY3TMHJVLOEBF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2021-03-27 01:54, Theallredman via Python-Dev wrote:
Forgive me if this isn't the correct venue for this question and I ask 
your help directing me to the correct place if it is not.


In PEP-376 it states with respect to the valid hashes in a Wheel RECORD 
file:


"The hash is either the empty string or the hash algorithm as named in 
hashlib.algorithms_guaranteed, followed by the equals character =, 
followed by the urlsafe-base64-nopad encoding of the digest 
(base64.urlsafe_b64encode(digest) with trailing = removed)."


In PEP-427 it further restricts the valid hashes to omit md5 and sha1 
and says:


"The hash algorithm must be sha256 or better; specifically, md5 and sha1 
are not permitted."


No where does it define what on what dimension of a hash "better" should 
consider.  From the context talking about the security of the algorithm 
I'd infer that "better" is with respect to collision resistance.  If so 
does that mean sha224 should also be excluded from wheel RECORD file hashes?


The "256" part refers to it generating a 256-bit signature, so a 
"better" one is one that generates a signature that's longer, e.g. 
"sha384" and "sha512".

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

[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

[MRAB]

On 2021-03-17 22:10, Skip Montanaro wrote:

Consider this little session from the tip of the spear:

 >>> sys.version
'3.10.0a6+ (heads/master:0ab152c6b5, Mar 15 2021, 17:24:38) [GCC 10.2.0]'
 >>> def while2(a):
...     while a >= 0:
...         a -= 1
...     return a
...
 >>> dis.dis(while2)
   2           0 LOAD_FAST                0 (a)
               2 LOAD_CONST               1 (0)
               4 COMPARE_OP               5 (>=)
               6 POP_JUMP_IF_FALSE       24

   3     >>    8 LOAD_FAST                0 (a)
              10 LOAD_CONST               2 (1)
              12 INPLACE_SUBTRACT
              14 STORE_FAST               0 (a)

   2          16 LOAD_FAST                0 (a)
              18 LOAD_CONST               1 (0)
              20 COMPARE_OP               5 (>=)
              22 POP_JUMP_IF_TRUE         8

   4     >>   24 LOAD_FAST                0 (a)
              26 RETURN_VALUE
 >>> list(dis.findlinestarts(while2.__code__))
[(0, 2), (8, 3), (16, 2), (24, 4)]

I get that somewhere along the way the compiler has been optimized to 
duplicate the loop's testso as to eliminate some jumps (perhaps). It's 
not clear to me that the line number should be "2" in the duplicated 
test though.Shouldn't it be "3"?


The condition is on line 2. The fact that it has been duplicated n the 
bytecode is irrelevant; it's still on line 2 in the source.


Line 3 has the decrement and line 4 has the return.

I stumbled on this while trying to generate a line number table in my 
side project register VM. As I understand it, the line number delta in 
the output table is supposed to always be >= 0. In my code I'm using 
dis.findlinestarts() to determine the line numbers for each block. 
Perhaps I should be modifying its results. OTOH, maybe it's a bug. (If 
that's the consensus, I will create an issue.)



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

[Python-Dev] Re: Steering Council update for February

[MRAB]

On 2021-03-10 15:17, Antoine Pitrou wrote:

On Wed, 10 Mar 2021 14:23:33 +
David Mertz  wrote:


Renaming main branches as 'main' is currently predominant practice on
GitHub (and more broadly in Free Software communities).  Python doesn't
need to cling to an old name based on a tired argument that political
sensitivity is a creeping plot to destroy old "fun" prejudices and
injustices.


Uh... Since you're putting "fun" in quotes, I assume this is quoting
someone else? (who?)

It's not a quote, it's Irony punctuation (in this case, used to indicate 
sarcasm):


https://en.wikipedia.org/wiki/Irony_punctuation
___
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/RJUCHSTSFC6IJPILRPYFQYY437NEOQ4G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[MRAB]

On 2021-02-23 23:05, Caleb Donovick wrote:
What is the motivation for returning `None` on empty splits?  I feel 
like this creates an unnecessary asymmetry.  I don't personally have a 
use case for the this feature so I may be missing something but it seems 
like it would force an annoying pattern:


```
try:
     foo()
except ExceptionGroup as eg:
     g1, g2 = eg.split(predicate)
     for e in g1:
         handle_true(e)
     for e in g2:
         handle_false(e)
```
Would need to be written:
```
try:
     foo()
except ExceptionGroup as eg:
     g1, g2 = eg.split(predicate)
     if g1 is not None:
         for e in g1:
             handle_true(e)
     if g2 is not None:
         for e in g2:
             handle_false(e)
```

Also this creates an subtle difference with subgroup:

```
g1, g2 = eg.split(predicate)
h1, h2  = eg.subgroup(predicate), eg.subgroup(lambda e: not predicate(e))
assert g1 == h1 and g2 == h2 # only true if `None not in {g1, g2}`
```


.subgroup returns an ExceptionGroup and .split returns 2 of them.

ExceptionGroup isn't iterable (it's mentioned in the "Rejected Ideas" 
section), so your code wouldn't work anyway.


On Mon, Feb 22, 2021 at 4:47 PM Irit Katriel via Python-Dev 
mailto:python-dev@python.org>> wrote:



Hi all,

We would like to request feedback on PEP 654 -- Exception Groups and
except*.

https://www.python.org/dev/peps/pep-0654/


It proposes language extensions that allow programs to raise and
handle multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and
other concurrency libraries,
but with other use cases as well.

* A new standard exception type, ExceptionGroup, to represent
multiple exceptions with
   shared traceback.
* Updates to the traceback printing code to display (possibly
nested) ExceptionGroups.
* A new syntax except* for handling ExceptionGroups.

A reference implementation (unreviewed) can be found at:
https://github.com/iritkatriel/cpython/pull/10


Thank you for your help


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

[Python-Dev] Re: Why aren't we allowing the use of C11?

[MRAB]

On 2021-01-28 19:20, Terry Reedy wrote:


On 1/28/2021 11:26 AM, Mark Shannon wrote:


PEP 7 says that C code should conform to C89 with a subset of C99 allowed.


As I remember, when the Python C dialect was discussed about 4 years
ago, no one seriously proposed moving beyond a subset of C99 addition,
because of the state of MSVC.

It's 2021 and all the major compilers support C11 (ignoring the optional 
parts).


C11 has support for thread locals, static asserts, and anonymous structs 
and unions. All useful features.


Is there a good reason not to start using C11 now?


Inertia is *a* reason.  C11 would require (and allow!) most (nearly
all?) people compiling CPython on Windows to upgrade their VS-VC setup.
   Maybe including some buildbot machines.

Judging from the post for
https://bugs.python.org/issue42380
this requires VS 16.8 with MSVC 14.28, released last November.  Prior
distributions of VS 2019 had earlier versions.  Last I knew, regular
people without a dev license cannot get just MSVC.  So we cannot require
a compiler most people cannot get.  This post otherwise gives additional
reasons why upgrading would be good.


[snip]

I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free) 
and it supports C11 and C17.

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

[Python-Dev] Re: Enhancement request for PyUnicode proxies

[MRAB]

On 2020-12-27 19:15, Guido van Rossum wrote:
On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren > wrote:





On 26 Dec 2020, at 18:43, Guido van Rossum mailto:gu...@python.org>> wrote:

On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
mailto:python-dev@python.org>> wrote:

It's worth comparing the situation with byte arrays. There is
no problem
of translating different representations of an element, but
there is
still the issue of who owns the memory. The Python buffer
protocol
usually solves this problem, so something similar for unicode
"arrays"
might suffice.


Exactly my thought on the matter. I have no doubt that between all
of us we could design a decent protocol.

The practical problem would be to convince enough people that this
is worth doing to actually get the code changed (str being one of
the most popular data types traveling across C API boundaries), in
the CPython core (which surely has a lot of places to modify) as
well as in the vast collection of affected 3rd party modules. Like
many migrations it's an endless slog for the developers involved,
and in open source it's hard to assign resources for such a project.


That’s a problem indeed.  An 80% solution could be reached by
teaching PyArg_Parse* about the new protocol, it already uses the
buffer protocol for bytes-like objects and could be thought about a
variant of the protocol for strings.  That would require that the
implementation of that new variant returns a pointer in the Py_view
that can used after the view is released, but that’s already a
restriction for the use of new style buffers in the PyArg_Parse* APIs.

That wouldn’t be a solution for code using the PyUnicode_* APIs of
course, nor Python code explicitly checking for the str type.

In the end a new string “kind” (next to the 1, 2 and 4 byte
variants) where callbacks are used to provide data might be the most
pragmatic.  That will still break code peaking directly in the the
PyUnicodeObject struct, but anyone doing that should know that that
is not a stable API.


That's an attractive idea. I've personally never had to peek inside the 
implementation, and I suspect there's not that much code that does so 
(even in the CPython code base itself, outside the PyUnicode 
implementation of course).



The re module does it extensively for speed reasons.
___
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/4LUBFUFQL6TNIX6CGTTF3O5M6IFXOME3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advice / RTFM needed for tool setup to participate in python development from a Windows host

[MRAB]

On 2020-12-16 19:19, Paul Moore wrote:

Personally, I just have Visual Studio and VS Code as my text editor. I
rarely use Visual Studio directly, though, I mostly use the
`build.bat` and similar scripts in the `PCBuild` directory.

Having said that, I'm not doing anything like debugging problems with
DLLs, for which I imagine a decent C development environment is
needed. You don't have much choice other than Visual Studio there (no
other compiler is supported on Windows), though, so you'll probably
need to learn that.

Paul


FWIW, I debug the regex module in Visual Studio 2019 Community.

I compile a release build with optimisations turned off when I'm going 
to be single-stepping through the code, otherwise it's very confusing 
with it jumping around all over the place due to the optimisations it's 
done.



On Wed, 16 Dec 2020 at 18:28,  wrote:


Hello,

I hope this is the correct place to ask this question.  I have a desire to
participate in python development in a particular area from my Windows host
machine, but I am not finding any concise listing of the tool setup needed
to fully participate, nor any detailed guidance on how to proceed when
underlying code debugging is necessary.

I do know that some version of the MS VS20xx suite is necessary to begin.
My initial attempts using the VS2019 Community Edition have been less than
successful when it comes to debugging an underlying C library component when
the starting program is python because I have not figured out how to use the
VS2019 environment to do that.

So I would appreciate any RTFM / URL that can guide me in starting to
participate, especially for guidance on debugging procedures for underlying
C components when the initial program is a python script.

I have read most of the "Python Developers Guide" material, but there is not
any Window-specific tooling information that I have seen there yet.  What
other tooling do I need besides a VS20xx environment?

I do have good experience in C programming, but not much in using VS20xx
IDE's.

TIA for your gentle guidance in curing my ignorance.

Peter


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

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

[MRAB]

On 2020-11-18 03:36, Larry Hastings wrote:



[snip]
But then we get to generator expressions and list/dict/set 
comprehensions.  I think of those as doing an "assignment", but I have 
to remember the assignment "doesn't leak":


x = 3
y = list(x**2 for x in range(5))
print(f"{x=}")

This code prints "x=3".

Why this exception to the rule?  IIRC from the discussions back when 
they were added, this one of those "it just seemed best at the time" 
things.  "for" was added to the language long before I got there, but it 
"leaking" its assignment was judged useful; if you broke out of the 
loop, you could continue to examine the last value from the loop.  But, 
the thinking went, you'd never want to examine the last value from a 
list generator, so it was more convenient if it behaved as if it had its 
own scope.



[snip]
I think the reason that generator expressions don't leak is that 
experience of list comprehensions, which did leak, showed that it was a 
bad idea. List comprehensions were "fixed" in Python 3.

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[MRAB]

On 2020-11-16 08:54, Glenn Linderman wrote:

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote:

Jim J. Jewett writes:

  > What advantage can there be in re-using syntax to mean something
  > opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x".  That doesn't
mean "bind c to the value f(x)", it means exactly the opposite.  No
problem here, I suppose.  So

 match p:
 case Point(x=a, y=b):

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem
in principle.  It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)".  This is
especially true when a or b is already bound.

Indeed. Mathematics never came up with separate symbols for equality and
assignment. Neither did early programming languages. That was a source
of confusion for many programmers.


[snip]

Fortran (1954) used '=' for assignment and '.EQ.' for equality.

Algol (1958) used ':=' for assignment and '=' for equality.
___
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/TGONBSN7ZEVNNGMC5HZMK3BASLGHVILX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[MRAB]

On 2020-11-15 09:48, Paul Sokolovsky wrote:

Hello,

As was mentioned many times on the list, PEP634-PEP636 are thoroughly
prepared and good materials, many thanks to their authors. PEP635
"Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/)
stands out among the 3 however: while reading it, chances that you'll
get a feeling of "residue", accumulating a section over section. By the
end of reading, you may get a well-formed feeling that you've read a
half-technical, half-marketing material, which is intended to "sell" a
particular idea among many other very viable ideas, by shoehorning some
concepts, downplaying other ideas, and at the same time, light-heartedly
presenting drawbacks of its subject one.

Just to give one example, literally at the very beginning, at the
"Pattern Matching and OO" section (3rd heading) it says:


Pattern matching is complimentary to the object-oriented paradigm.



That looks like a mistake to me; it should be "complementary".

[snip]
___
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/FL5VVQGGF4KQ6VCMGVFF6BM4BGCDGFKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[MRAB]

On 2020-11-12 19:21, Paul Sokolovsky wrote:

Hello,

[Re-routed back to python-dev.]

On Thu, 12 Nov 2020 20:04:57 +0100
Piotr Duda  wrote:

[]


> match foo:
> case ("foo", >val1):
> ...
> case ("bar", >val2):
> ...
>  


I agree with that, though I would prefer using other symbol than > (?
or $), one of reasons would by it would look better as "match all"
target, other one that in future. it would allow extending syntax for
simple guards like ?x < 100.


Question of "what to mark with sigils - terms-used-as-values or
terms-used-for-capturing" is orthogonal to the question of "what to use
as match-all symbol", though I understand the desire to repurpose the
same symbol for both.

For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or
can be proposed. The benefit of "->", ">", ">>" is that they're very
intuitive. I'd also have preference for shorter one, because 2-chars
are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity
unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice
IMHO, because intuitively (based on other languages - shell, etc.) it
says "use the value of variable".

I'd still want to list "as" as another possibility, the advantage being 
that it's already used for binding elsewhere.



That said, those are 2nd-level choices. The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" (3rd choices - "use adhoc interpretation
of non-orthogonal syntactic conventions" - being the worst). But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


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

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[MRAB]

On 2020-10-22 17:48, Guido van Rossum wrote:
After the pattern matching discussion died out, we discussed it with the 
Steering Council. Our discussion ended fairly positive, but there were a 
lot of problems with the text. We decided to abandon the old PEP 622 and 
break it up into three parts:


- PEP 634: Specification
- PEP 635: Motivation and Rationale
- PEP 636: Tutorial

This turned out to be more work than I had expected (basically we wrote 
all new material) but we've finally made it to a point where we can 
request feedback and submit the new version to the SC for approval.


While the text of the proposal is completely different, there aren't 
that many substantial changes:


- We changed walrus patterns ('v := p') to AS patterns ('p as v').
- We changed the method of comparison for literals None, False, True to 
use 'is' instead of '=='.

- SyntaxError if an irrefutable case[1] is followed by another case block.
- SyntaxError if an irrefutable pattern[1] occurs on the left of '|', 
e.g. 'x | [x]'.


Is "syntax error" that the right term for it? Maybe it should be 
something different, a subclass of SyntaxError perhaps.


[snip]
___
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/JHX6WDK3GMJD6ALXWEJ3K45WOXQUKZQW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-08-03 05:21, Guido van Rossum wrote:
Your point about wanting a way to use an unqualified name as a value 
pattern is not unreasonable, and as you may recall we had an elegant 
solution in version 1 of the PEP: a leading dot. However that was booed 
away by the critics, and there has been no consensus (not even close) on 
what to do instead.


Any solution that involves special markup (like bringing back the 
leading dot, or backticks, or a question mark, or any other sigil) can 
easily be added in a future version of Python.


There is one solution that I personally find acceptable but which found 
little support from the other PEP authors. It is a rule also adopted by 
Scala. This is to make it so that any identifier starting with a capital 
letter (possibly preceded by one or more underscores) is a value 
pattern. I note that in Scala, too, this is different in patterns than 
elsewhere in the language: Scala, like Python, allows identifiers 
starting with a capital letter to be assigned in other contexts -- just 
not in patterns. It also uses roughly the same *conventions* for naming 
things as PEP 8 (classes Capitalized, constants UPPERCASE, variables and 
methods lowercase). I also note that Scala allows backticks as another 
way to force interpretation as a value pattern (though apparently it's 
not used much for this purpose).



[snip]
A thought occurred to me. By default, the current rules of the PEP could 
apply, but why not allow prefixing with "as" for a capture and "is" for 
a value?


Yes, I know, comparison of the values is not by identity, but "is" is a 
short keyword that already exists and matches up with "as".



(After looking back through the thread it looks like Rob Cliffe has 
already had the same idea.)

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

[Python-Dev] Re: How to customize CPython to a minimal set

[MRAB]

On 2020-07-21 06:33, Huang, Yang wrote:

Hi, Guido

Yes. Micropyhton is also in consideration.

But sqlite3 is the first usage. There should be some additional features 
like numpy, scipy... Not sure if micropython supports well?


Or is there a feasible way to strip CPython ?

Thanks.


You want a minimal Python, yet with numpy, scipy, ...? Those sound like 
contradictory goals to me!




*From:* Guido van Rossum 
*Sent:* Monday, July 20, 2020 10:45 PM
*To:* Huang, Yang 
*Cc:* python-dev@python.org
*Subject:* Re: [Python-Dev] How to customize CPython to a minimal set

Have you considered starting with micropython? It’s made for embedded 
systems and fully supports Python 3 syntax. Adding sqlite3 support to it 
will be less work than stripping all the I/O from CPython.


—Guido

On Mon, Jul 20, 2020 at 06:48 Huang, Yang > wrote:



Hi, all

There is a request to run python in a Linux-based embedded resource
constrained system with sqlite3 support.

So many features are not required, like posixmodule, signalmodule,
hashtable ...
But seems there are some dependencies among the
Modules/Parser/Python/Objects/Programs...

Is there a way to tailor CPython 3 to a minimal set with sqlite3
(the less syscalls the better) ?
Is it possible to do that?

Thank you.


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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-16 19:05, Richard Damon wrote:

On Jul 16, 2020, at 1:36 PM, Chris Angelico  wrote:

On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno  wrote:

Tools should adapt to the language, not the other way around. If things had to 
be done the way they had always been done, without any change, for fear of 
people not being used to it, we wouldn't even have Python at all. People learn 
and adapt. It seems like a small price to pay in exchange for consistency and 
removal of ambiguity, considering people will still have to learn the new 
feature one way or another.



But consistency is exactly what you'd be destroying here. Python is
extremely consistent in that you ALWAYS indent after a line ends with
a colon, and what comes after it is logically contained within that
statement. It's about whether *people* can handle it, more than
whether tools can, and the consistency helps a lot with that.

ChrisA


One question that comes to mind, does match NEED a colon at the end of it? If 
it didn’t have the colon, it wouldn’t need the indent for the following lines.


All of the others have the colon.
___
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/Z63GPE46RPULXJRIFVOBF4DDM3BCKD5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-16 17:37, Steve Holden wrote:
While I understand the point of view that says that match ... : 
should encapsulate a sequence of indented suites, it seems to me that 
match/case/case/.../else has a natural affinity with 
try/except/except/.../finally/else, and nobody seems to think that the 
excepts should be indented. Or the finally. And naturally the match/else 
case are at the same indentation level, just as for/else, while/else and 
try/finally. So why, exactly, should case be indented?


My apologies for being a Bear of Very Little Brain.


[snip]
For all other statement structures (if, while, try, etc.), the first 
line ends with a colon and the second line is indented (and is a 
statement). Therefore the cases should be indented.


However, for all other statement structures (if, while, try, etc.), the 
other parts of the structure itself (elif, else, except, etc.) aren't 
indented. Therefore the cases shouldn't be indented.


Either way, it's inelegant.
___
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/4W2J5SLLOTLPMMFIZ4KTAC4THJMDCWBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-12 23:20, Guido van Rossum wrote:
[snip]
The need for a wildcard pattern has already been explained -- we really 
want to disallow `Point(x, y, y)` but we really need to allow `Point(z, 
_, _)`. Generating code to assign the value to `_` seems odd given the 
clear intent to *ignore* the value.


Using `?` as the wildcard has mostly disadvantages: it requires changes 
to the tokenizer, it could conflict with other future uses of `?` (it's 
been proposed for type annotations as a shorter version of Optional, and 
there's PEP 505, which I think isn't quite dead yet), and Python users 
have no pre-existing intuition for its meaning.


FWIW, I don't think this use of '?' would conflict with the other 
suggested uses because this use would be initial in an expression, 
whereas the other uses would be non-initial.


[snip]
___
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/D33YT2KBNVZS27JJIYA5BDWPIP5IWB7M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-12 01:32, Chris Angelico wrote:

On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing  wrote:


Just had another thought about marking assignment targets.

The PEP currently forbids repeating bound names in a pattern
to avoid raising expectations that

 case Point(x, x):

would match only if the two arguments were equal.

But if assignment targets were marked, we could write this as

 case Point(?x, x):

and it would work as expected.



Hang on. Matching happens before assignment, so this should use the
previous value of x for the matching. At least, that's my
understanding. If you do something like:

case Point(x, 2):

it won't assign x unless the second coordinate is 2, right?

Presumably the assumption is that it would use a local dict for binding, 
faling back to the actual dict if necessary for lookup, and then update 
the actual dict if the match is successful. That way, unsuccessful 
matches won't pollute the actual dict.

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[MRAB]

On 2020-07-11 20:56, Steve Holden wrote:
Given that case will be a keyword, what's the case (pun unintentional) 
for indenting the case clauses? What's wrong with 'case' and 'else' both 
indented the same as match? Without the keyword there'd be a case for 
indenting, but with it I don't see the necessity.


Kind regards,
Steve


The issue is as follows.

In Python, the style is that multi-line statements start with a keyword 
and that logical line ends with a colon. The next line is a statement, 
which is indented. The other parts of the statement structure are 
indented the same amount as its first line:


if ...:
...
elif ...:
...
else:
...

The 'match' statement (or a 'switch' statement), however, can't follow 
the existing style.


It's either:

match ...:
case ...:
case ...:

where the second line isn't indented (unlike all other structures), or:

match ...:
case ...:
case ...:

where the other parts of the structure (the cases) aren't indented the 
same as the first line.


Another possibility is:

match:
...
case ...:
case ...:

but the second line is an expression, not a statement (unlike all other 
structures).


An alternative is:

match ...
case ...:
case ...:

no colon ending the first line, and no indenting of the second line, but 
that's unlike  all other structures too.


None of the possibilities are formatted like the existing style.

So it's a case of picking the least inelegant one.



On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing > wrote:


A thought about the indentation level of a speculated "else" clause...

Some people have argued that "else" should be at the outer level,
because that's the way it is in all the existing compound statements.

However, in those statements, all the actual code belonging to the
statement is indented to the same level:

      if a:
          
      elif b:
          
      else:
          

          ^
          |
          Code all indented to this level

But if we were to indent "else" to the same level as "match",
the code under it would be at a different level from the rest.

      match a:
          case 1:
              
          case 2:
              
      else:
          
          ^   ^
          |   |
          Code indented to two different levels

This doesn't seem right to me, because all of the cases, including
the else, are on the same footing semantically, just as they are in
an "if" statement.


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[MRAB]

On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:

Why not use '=' to distinguish binding from equality testing:
      case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.

This would allow a future (or present!) extension to other relative
operators:
      case Point(x, >y):
(although the syntax doesn't AFAICS naturally extend to specifying a
range, i.e. an upper and lower bound, which might be a desirable thing
to do.
Perhaps someone can think of a way of doing it).

Whether
      case =42:
      case 42:
would both be allowed would be one issue to be decided.

In Python, '=' is assignment and '==' is equality. Using '=' for 
equality could lead to confusion.

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

[Python-Dev] Re: PEP 622 railroaded through?

[MRAB]

On 2020-07-08 02:20, Greg Ewing wrote:

On 8/07/20 12:48 pm, Chris Angelico wrote:

"for x[0] in iter:" uses
x[0] as an assignment target,


You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import", etc.)

But in match statements, they can be arbitrarily
intermingled with other expression-like stuff.


You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.


It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.

Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.

Prefixing values with "==" might be the clearest, an idea that, I think, 
Ethan came up with. It might not look elegant, but...

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

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[MRAB]

On 2020-07-04 21:07, Martin Dengler wrote:

On Sat, Jul 04, 2020 at 05:51:04PM +0100, MRAB wrote:
>I'd also add: Try to avoid regionalisms; aim for a 
>broadly "international" form of the language. Some 


How do you spell "regionalism"?

Martin

PS: Irony intended


As far as I'm aware, there's only one way to spell it, but I'm sure 
someone can phrase it better.


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

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-04 19:23, Paul Moore wrote:

On Sat, 4 Jul 2020 at 17:48, MRAB  wrote:
>
> On 2020-07-04 05:51, Greg Ewing wrote:
> > On 4/07/20 4:33 am, Jim J. Jewett wrote:
> >> If Bob and Alice seem neutral to you, would you do a double-take on 
Kehinde or Oladotun?
> >
> > Maybe we should use randomly generated names for hypothetical persons?
> >
> Ideally they should be short names, one or two syllables.

Surely the obvious thing to do would be to use Monty Python characters?

True, but if they were all called Eric it could be confusing.
___
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/ZYK5PHZUYA2PUVWJSZUS52R6AOJLPS7L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[MRAB]

On 2020-07-04 16:23, Stephen J. Turnbull wrote:

@Inada-sama: For RFC conformance to S, see footnote [3] at the end.

MRAB writes:

  > If you believe you have something important to say, then at least
  > say it clearly.

Indeed -- that commit log is an example of the kind of writing the
reference to Strunk & White was intended to reduce; repetitive,
jargon-filled, and mostly unnecessary to make the point.[1]  Ironic,
but not the only irony to be found in this commit.

Because I have seen the deterrent effect in action -- *it is real* --
I'd be sympathetic to this change if I hadn't directly experienced the
value of a rule set like that in Strunk & White in teaching non-native
speakers about writing English for technical purposes.  Since I
believe an admonition to "write clear and easily understandable
English" is a deterrent too, especially for non-natives, I would
prefer deleting the whole thing to this change, though.

The claim is that requiring Strunk & White deters PoC.  I believe it.
But by discarding all rules, this change "centers" English-speakers at
the expense of the needs of large populations of *non-native-speaking*
PoC.  Many non-natives would benefit from adopting some of the advice
in Strunk & White for *writing* clearly, and if others follow that
advice, it would easier for them to *read*.[2]  Don't take my word for
it: Naoki Inada testifies to both issues in his post about "RFC
English".[3]

It has also been claimed that many neuro-atypical folks find detailed
rules comforting, as opposed to broad admonitions of that kind.  Seems
plausible, but I can't speak to it from personal experience or
testimony of acquaintances.  But if so, removing all reference to
concrete rules for clear writing harms and deters them, too.

But "practice what you preach" is a fallacy, I guess.  "Do what I say,
not what I do" is the way of the world.  Given human fallibility,
maybe this is a not-bad thing, to focus on the merits of folks' speech
rather than the demerits of their actions *shrug*

As I see it, in order of importance, we could say the following about
comments in Python:

1.  Comments should not say anything that a programmer with some
 experience can read directly from the code, taken out of the
 larger context.  That eliminates a lot of problematic text right
 off the bat! :-)

2.  Write comments in English.  It is the lingua franca [sic!] of
 programming, for better or worse, and Python development is an
 international community of programmers.  (The language may change,
 see "sic!" above.  Boy, would I enjoy watching some folks struggle
 with Hindi or Chinese.)

3.  Write in a comfortable dialect[4].  (Exceptions: legalese and
 The Academic Register are strictly forbidden, even if you're
 native in one of those. :-)
I'd also add: Try to avoid regionalisms; aim for a broadly 
"international" form of the language. Some words and phrases might be 
specific to a certain region, or have different, possibly conflicting, 
meanings elsewhere.

4.  Write clear and easily understandable comments, remembering that
 many potential readers are not native speakers, let alone native
 in "Standard" English.

5.  For advice on writing clearly, Zinsser is a good textbook on
 writing to communicate.  Strunk & White is a concise collection of
 concrete rules with examples of usage that help many to write more
 clearly, and its table of contents serves as a somewhat Petersian
 "Zen of Technical Writing".  (There may be better alternatives to
 both for those purposes, but I don't know of any.)

[snip]

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

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-04 05:51, Greg Ewing wrote:

On 4/07/20 4:33 am, Jim J. Jewett wrote:

If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or 
Oladotun?


Maybe we should use randomly generated names for hypothetical persons?


Ideally they should be short names, one or two syllables.
___
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/HTCYNHWLGHPLN6L45VUQKNCYJT4GCW3Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[MRAB]

On 2020-07-03 17:52, Jim J. Jewett wrote:

Specifying British English (as opposed to just British spelling) would probably 
tempt people to use more Brit-only idioms, in the same way that Monty Python 
tempts people to make Flying Circus references.

I don't love the idea of talking more about how many zeroes in a billion, or whether 
"table it" is an extra-fun reference *because* of the ambiguity.


The UK officially switched to the "short" billion (9 zeros) in 1974.

See: https://en.wikipedia.org/wiki/Billion
___
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/PEFPBAMWAFW4VVZAKSD2O2PDJ6OEZH7B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[MRAB]

On 2020-07-02 22:17, Jeff Allen wrote:

On 01/07/2020 21:01, Ethan Furman wrote:

A not-great article, White Fears of Dispossession: Dreyer's English, 
The Elements of Style,and the Racial Mapping of English Discourse, here:


http://radicalteacher.library.pitt.edu/ojs/radicalteacher/issue/view/19/25 



Thanks for posting this. (What a lot of work you must've done to find 
it.) As a result I feel I have a much better understanding of the 
environment in which these thought processes (those displayed in the 
commit message) would be considered rational, even admirable. Food for 
thought.


I found the language difficult to understand. For example, "in the midst 
and post the election" instead of "during and after the election". And 
multiply-stacked nouns. And nouns used as verbs. Much like 
"management-speak". If you believe you have something important to say, 
then at least say it clearly.


E. B. White was born in New York -- I believe that's in the northern 
part of the United States, otherwise known as "The North" or the side 
that fought to end slavery.


E. B. White was educated at Cornell.

We should acknowledge that he famously showed an interest in web 
development and invented a sort of mouse. ;-)



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

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 18:19, David Mertz wrote:
On Thu, Jul 2, 2020 at 12:58 PM Piper Thunstrom > wrote:


> TL;DR: It's not a recent usage; it was OK in 1375.

Forgive me for not giving a detailed play by play of 15 years of
experience specifically as a writer and editor.
Over the last handful of decades, singular "they" has been explicitly
taught as inappropriate. My own college writing classes (only 10 years
ago now) included this specific piece of advice.


My college writing class in 1985 or so DID NOT eschew singular they.  
I've been a professional writer for about 30 years now.  I am happy to 
stipulate that your class in 2010 at some particular college included 
an instructor saying "don't use singular they" ... but that was not 
uniform across universities in 2010, probably not even across the 
entire faculty at your particular school.


I'm 55 yo, and I remember 50 years ago hearing the nonsense claim that 
"singular they" is "bad feminists trying to corrupt the English 
language."  I probably didn't know the 14th century origin of the use 
until a decade or two later than that, but this identical discussion 
was already extremely old by the time you were born.


In terms of modern English vernacular, singular "they" has been
continuously and rigorously treated as inappropriate.


This is absolutely and categorically false.  There have been SOME 
PEOPLE who didn't like the singular they, starting about 1820.  The 
idea never occurred to anyone during the first 450 years of its use.  
It has also never been uniform opinion at any point in the last 200 
years.  But as I say, some text books, and quite possibly your 
particular instructor at some particular school, was of that opinion.


Strunk and White, in current editions, does not hold that position.

Those who prefer singular "they", myself included, point to references

very much like yours as evidence that it has a long history of usage.
But until only the last few years, the popular style guides explicitly
forbade it.


Again... SOME guides.  Except the ones that didn't do this.`

And if you don't like singular "they", an alternative that I forgot 
about is "yon", as in this/that/yon (this near me; that near you; yon 
over there by him/her/it). English had 3 demonstratives, as did Latin, 
as does Spanish.


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

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 17:47, Piper Thunstrom wrote:

On Thu, Jul 2, 2020 at 12:16 PM MRAB  wrote:
> Here's an article on singular 'they':
>
> https://public.oed.com/blog/a-brief-history-of-singular-they/
>
> TL;DR: It's not a recent usage; it was OK in 1375.

Forgive me for not giving a detailed play by play of 15 years of
experience specifically as a writer and editor.

Over the last handful of decades, singular "they" has been explicitly
taught as inappropriate. My own college writing classes (only 10 years
ago now) included this specific piece of advice.

In terms of modern English vernacular, singular "they" has been
continuously and rigorously treated as inappropriate.

Those who prefer singular "they", myself included, point to references
very much like yours as evidence that it has a long history of usage.
But until only the last few years, the popular style guides explicitly
forbade it.

I hope that helps you understand.


It's also like saying that you shouldn't split infinitives ("to boldly 
go") because Latin doesn't (and can't), or that the copula "be" should 
be followed the nominative case ("It is I", not "It is me") because 
that's what Latin does (on the other hand, French says "C'est moi", not 
"C'est je").


English isn't Latin.
___
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/6YZVBQBU3XI72F4LFU4IRRBHWVYKA5XM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 17:14, Paul Moore wrote:

On Thu, 2 Jul 2020 at 16:53, David Mertz  wrote:


On Thu, Jul 2, 2020, 11:08 AM Piper Thunstrom


Paul, this is actually a good question to ask. In general, singular "they" is 
becoming more popular. It's already used frequently for the singular indeterminate 
pronoun:


The first attested use of singular they in English was in 1375 CE. I'm not sure what time 
frame Piper uses as the increment for "becoming more popular", but its use has 
waxed and waned for 650 years.


I was aware of "they" as an option, so I agree it seems like a
reasonable approach.


The usage has never been rare during those 650 years, but neither has it ever 
been predominant. It is a completely reasonable approach, and I would not 
object to encouraging it in Python documentation.


Nor would I.


Earlier in my life (30-40 years ago) I tended to use s/he or similar forms. I 
think that 'they' is more inclusive of gender non-binary people, as well as 
being much more historically established.


I tend to use "they" relatively often, but I have found in the past
that it leads me into certain types of awkward sentences (no, I can't
think of an example right now) where using "they" doesn't seem right.
Maybe that's because I use "he" myself, and feel fairly uncomfortable
when I'm referred to as "they", so that colours my impression - even
though I'm writing for (generic) other people, I do tend to think in
terms of how my words read if I view then as addressed to me. This is
where I feel that "language hasn't caught up".

My understanding is that technically "he" takes a dual role in
English, as both masculine (technical linguistics gender) 3rd person
singular and "indeterminate" 3rd person singular (because English
doesn't have an "indeterminate-but-not-neuter" gender - do any other
languages?). But technical usage is irrelevant here, as people's
feelings and identity are involved and language has to reflect that,
not the other way round. Maybe sometime in the future, "they" will be
the norm and "he and "she" will sound as archaic as "thou" does today.
But until then, I feel that we should all tend to assume that everyone
is *trying* to be inclusive, and shape our words as best we can to
express and include ideas that maybe we don't personally have the
experience to really feel as deeply as others do - that's not so much
"privilege" in my view as "limited experience" and I hope people would
assume I'd like to understand better and mean no harm, rather than
that I'm smugly asserting my own world view as the only one that
matters (sadly, I appreciate that some people *do* do that, but I
doubt that applies to anyone in the Python community...)

Anyway, sermon over - thanks for the information and references everyone.

Indo-European languages tend to have grammatical gender 
(masculine/feminine/neuter or masculine/feminine), but it's not 
necessarily related to physical gender.


Other languages families might have many categories or 'genders', or 
just distinguish between animate and inanimate (and those might not 
necessarily be related to whether something is really animate or inanimate).


Having only one 3rd-person singular pronoun is by no means unusual.
___
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/N4KCCO4FCANKMBRVA6VQZR6QSKJGTWYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[MRAB]

On 2020-07-02 15:48, Jim J. Jewett wrote:

Guido van Rossum wrote:

On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> The key thing I'm hoping for in PEP 622 itself is
> that "Syntactic compatibility with a possible future
> enhancement to assignment statements" be considered
> as a constraint on the syntax for case patterns.



That would certainly rule out ideas like writing stores as $x or x? or 
etc., since it would be syntactically incompatible with current
assignment statements.


No; it would be unfortunate that it creates a second way to
do things, but it wouldn't rule them out.  The problem Nick
pointed out is for syntax that is already meaningful, but
means something different.

 self.y = 15

already has a meaning, but that meaning is NOT "don't really
assign to X, I am using it as a constant defined elsewhere."

 ?x = 14
 ?self.y = 15

do not yet mean anything, and if they end up being a more
explicit (but also more verbose) variant of

 x = 14
 self.y = 15

that is probably sub-optimal, but it isn't any worse than :=

The slight variation triggered by the "?" of ?var would be
shorthand for "and if you can't make the entire assignment
work, pretend I never even asked", so that

 ?x, 0 = (4,5)

would not lose or shadow a previous binding of x.
  
IMHO, the assignment statement should remain as it is, not sometimes 
assign and sometimes not.


There could be another form that does matching:

try ?x, 0 = (4,5)

or:

?x, 0 ?= (4,5)

Perhaps it could also be used as an expression, having the value True if 
it matches and False if it doesn't.

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

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 15:19, Piper Thunstrom wrote:

On Thu, Jul 2, 2020 at 10:01 AM Paul Moore  wrote:

What *is* the correct inclusive way to refer to an unidentified person
in a technical document, without sacrificing clarity by using
convoluted circumlocutions like "he/her/they" or over-use of the
passive voice? My impression is that commonly accepted language rules
and usage are lagging behind, and there's no good answer to this
question yet :-(

Paul


Paul, this is actually a good question to ask. In general, singular
"they" is becoming more popular. It's already used frequently for the
singular indeterminate pronoun:

"Someone wants to talk to you."
"What do they want?"

Those who favor prescriptivism will tell you this is improper usage
(especially when it goes from an unknown someone to a known someone)
but it avoids the strange construction of "he or she" and is more
inclusive of diverse genders and is historically how the word was
used. (For a fun counter example, the word "you" used to be a plural
second person pronoun, but no one today would argue that it makes no
sense to use it for an individual.)


Here's an article on singular 'they':

https://public.oed.com/blog/a-brief-history-of-singular-they/

TL;DR: It's not a recent usage; it was OK in 1375.
___
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/MIW6WHPO7NZ5UNVPFOIGWH2CI6Y3B5JN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 12:32, Greg Ewing wrote:

On 2/07/20 10:53 pm, MRAB wrote:

Alternatively, it could be an auxiliary language like Esperanto.


Maybe Esperanto in particular wouldn't be the best choice --
I gather it's rather European-oriented.

Maybe we should standardise on Klingon? Humans of all cultures
would find it equally difficult.

There are quite a few other constructed languages that you could use, 
but Esperanto is by far the most successful of them, which is why I 
mentioned it.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A7V3LK44XW7WFB67S7UTT7ZU7HLEFKME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[MRAB]

On 2020-07-02 10:38, Chris Angelico wrote:

On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou  wrote:

Otherwise why stop at English? I could just as well write my comments
in French if it's all about individual freedom.  Requiring English is
not inclusive, it forced people like me to painfully adapt to a
language I wasn't used to.  And that has nothing to do with "white
supremacy".


True, but "inclusive" isn't just about the people *writing*. If you
write your comments in French, and someone else uses Turkish, another
uses Japanese, and still another opts for Hebrew, it becomes nearly
impossible for anyone to *read* those comments. Standardizing on a
single language ensures that everyone can read the comments in a
single, consistent language.

If we want to be completely fair to everyone, we could insist that
comments be written in Latin. That way, nobody gets a "home turf"
advantage, and we're all going to the effort of translation... but I'm
sure you agree that this wouldn't be an improvement to Python :)

So if there's going to be one language chosen, logically it should be
a language that is familiar to many people. That means that Mandarin
Chinese, Spanish, and English, I believe, would be the most favoured
choices. Chinese has the toughest demands on input methods, and
between Spanish and English, I'd need to hear from someone whose first
language is Spanish as to how viable it would be. But it's still
necessary to standardize on just one.


Alternatively, it could be an auxiliary language like Esperanto.
___
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/2S4TQASCPZKPHYXMCC43ZNKRLWBZN2BW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-25 08:50, Anders Munch wrote:

Eric Nieuwland :

I have some doubt about the keyword

Guido van Rossum [mailto:gu...@python.org]:

Many people have tried to come up with a different keyword here, but nothing
has been found that comes even close to the simplicity of match. Plus, several
other languages (Scala, Rust) use it too (which is further evidence that it's
a natural fit).
  
I was thinking that 'match' and 'case' are reversed: The top line presents the

_case_ to be studied.  The patterns that follow try to _match_ the presented 
case.

Trying it out on PEP example:

case input:
 match x if x > MAX_INT:
 print("Got a large number")

I think it reads well, in particular when like here there's a condition
attached.  The second line is almost English: "match x if x greater than max
int".

Pascal is a precedent for this placement of 'case', although of course Niklaus
Wirth is not a native English speaker either.

Some languages use 'case' at the start of the construct; other languages 
use 'case' for the individual values. There are precedents for both 
placements.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-25 04:54, Greg Ewing wrote:

I had another thought about a way to make the bound names explicit.

 # Keyword
 case Point(x -> px, y -> py):

 # Positional
 case Point(-> x, -> y):

 # Sub-pattern, positional
 case Line(Point() -> p1, Point() -> p2):

 # Sub-pattern, keyword
 case Line(start: Point() -> p1, end: Point() -> p2):

How do you indicate that you want it to match anything and don't care 
about the value?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-24 23:14, Ethan Furman wrote:

On 06/24/2020 01:49 PM, Tim Peters wrote:


I too thought "why not else:?" at first. But "case _:" covers it in
the one obvious way after grasping how general wildcard matches are.


"case _:" is easy to miss -- I missed it several times reading through the PEP.


Introducing "else:" too would be adding a wart (redundancy) just to
stop shallow-first-impression whining.


Huh.  I would consider "case _:" to be the wart, especially since "case default:" or "case 
anything:" or "case i_dont_care:" all do basically the same thing (although they bind to the given name, 
while _ does not bind to anything, but of what practical importance is that?) .[snip]


The point of '_' is that it can be used any number of times in a pattern:

case (_, _):

This is not allowed:

case (x, x):

When a pattern matches, binding occurs, and why bind to a name when you 
don't need/want the value?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-24 13:37, Antoine Pitrou wrote:

On Wed, 24 Jun 2020 21:54:24 +1200
Greg Ewing  wrote:

On 24/06/20 5:20 am, Antoine Pitrou wrote:
> suddently `Point(x, 0)` means something entirely
> different (it doesn't call Point.__new__, it doesn't lookup `x` in the
> locals or globals...).  


This is one reason I would rather see something explicitly marking
names to be bound, rather than making the binding case the default.
E.g.

case Point(?x, 0):

This would also eliminate the need for the awkward leading-dot
workaround for names to be looked up rather than bound.


That looks quite a bit better indeed, because it strongly suggests
that something unusual is happening from the language's POV. Thank you
for suggesting this.


Could the name be omitted when you're not interested in the value?

case Point(?, 0):


One other thing that the PEP doesn't make clear -- is it possible
to combine '=' and ':=' to match a keyword argument with a sub
pattern and capture the result? I.e. can you write

case Spam(foo = foo_value := Blarg()):


Yuck :-S


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-24 01:09, Guido van Rossum wrote:
On Tue, Jun 23, 2020 at 4:41 PM MRAB <mailto:pyt...@mrabarnett.plus.com>> wrote:

[snip]


However, what if you wanted to match Ellipsis?

This could lead to bugs:

 >>> ...
Ellipsis
 >>> Ellipsis = 0
 >>> Ellipsis
0
 >>> ...
Ellipsis


Now you're just being silly. If you want to use Ellipsis as a variable 
you can't also use it to refer to the "..." token.

[snip]

The point here is that printing ... shows "Ellipsis" (not "..."), 
printing None shows "None", etc.


Printing Ellipsis also shows "Ellipsis", but you can bind to it. You 
can't bind to None, etc.


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-23 22:50, Barry Warsaw wrote:

On Jun 23, 2020, at 14:31, Chris Angelico  wrote:


I can't find it among the rejected alternatives, but was it considered
to use "..." as the wildcard, rather than "_"? It carries similar
meaning but its special case of "this will never be bound" is simply
preventing an error, rather than making one otherwise-valid name
special.


I thought of that too as I was reading the PEP, but forgot to add it to my 
notes.  I do like ellipsis more than underscore here.


+1

However, what if you wanted to match Ellipsis?

This could lead to bugs:

>>> ...
Ellipsis
>>> Ellipsis = 0
>>> Ellipsis
0
>>> ...
Ellipsis

If you can have "case False:" and "case True:", should 'Ellipsis' become 
a keyword so that you could have "case Ellipsis:"? Or do they have to be 
"case .False:", "case .True:", in which case it could remain "case 
.Ellipsis:"?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-23 22:53, Emily Bowman wrote:
On Tue, Jun 23, 2020 at 2:10 PM MRAB <mailto:pyt...@mrabarnett.plus.com>> wrote:


I think that's done for consistency. '_' is a wildcard and you can
have:

     case (_, _):

to match any 2-tuple, so:

     case _:

would match any value, and can thus already serve as the default.

I wouldn't object to 'else', though.


Can you have case (x,x): ? I haven't tried the implementation, but 
it's not addressed in the PEP that I see, and if that's legal, then _ 
is effectively just a style choice, rather than a functional one, and 
there's no reason it shouldn't also be a named match.



You cannot bind to the same name twice, so "case (x,x):"is an error.
+1 for including "else:" for consistency even if that's just a shim 
for "case _:"

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-23 18:20, Antoine Pitrou wrote:


Some comments:

* What you call "Constant Value Patterns" can really refer to any local
   or non-local name, regardless of how complex the referred object is,
   right?  Also, __eq__ is called in that case, not __match__?

* If I understand correctly, these:

 case b"":
 print("it's an empty bytes object")

and

 case bytes():
 print("it's a bytes object")

have entirely different meanings.  Am I right?  This sounds like I have
to switch contexts when reading code, based on whether I am reading
regular code or a match clause, given that semantics are quite
different.

Instead, it seems like the latter would be more explicitly spelled out
as, e.g.:

 case instanceof(bytes):
 print("it's a bytes object")

* The acronym "ADT" is never defined.

* """If there are more positional items than the length of
   __match_args__, an ImpossibleMatchError is raised."""

What if there are less positional items than ``len(__match_args__)``?
Can the match succeed rather than raise ImpossibleMatchError?  This
seems potentially error-prone.


Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.

It may be useful to think about different notations for these new
things, rather than re-use the object construction notation.

For example:

 case Point with (x, y):
  print(f"Got a point with x={x}, y={y}")

or:

 case Point @ (x, y):
  print(f"Got a point with x={x}, y={y}")

(yes, "@" is the matrix multiplication operator... but it's probably
much less likely to appear in common code and especially with a class
object at the left)


Or:

case Point as (x, y):
print(f"Got a point with x={x}, y={y}")

perhaps as 'as' is already used for binding.

The disadvantage there is with nested patterns:

case Coordinate(Point(x1, y1), Point(x2, y2)):

where you're matching a coordinate and binding to x1, y1, x2 and y2.
___
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/IMKBETFAH3CS6TLBT3JNQX2ULQ4QKQLK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-23 20:27, Rob Cliffe via Python-Dev wrote:



On 23/06/2020 17:01, Guido van Rossum wrote:


You can combine several literals in a single pattern using `|` ("or"):

```py
        case 401|403|404:
            return "Not allowed"
The PEP is great, but this strikes me as horribly confusing, given that 
401|403|404 is already legal syntax.
IIUC any legal expression can come between `case` and `:`, but 
expressions that contain `|` at their outermost level are *interpreted 
differently* than from in other contexts.


The grammar shows that 'case' is followed by a series of alternatives, 
separated by '|', but the alternatives aren't expressions, basically 
only literals and instances of a given class. You can't say "case 1 + 
2:", for example.



Presumably adding parentheses:
     case (401|403|404):
would make it equivalent to
     case 407:


I'm not sure whether that's legal, but it's not equivalent.

Is a separator (other than whitespace) actually needed?  Can the parser 
cope with

     case 401 403 404:

Failing that IMO preferable, albeit not ideal, possibilities would be
   1) Use colon as the separator.
   2) Use comma as the separator - this is already legal syntax too, but 
IMO it reads more naturally.
   (And IIRC there are already contexts where brackets are necessary 
to indicate a tuple.)

Perhaps someone can think of something better.

I also (with others) prefer `else:` or perhaps `case else:` to using 
the`_` variable.
The latter is obscure, and woudn't sit well with code that already uses 
that variable for its own purposes.



I think that's done for consistency. '_' is a wildcard and you can have:

case (_, _):

to match any 2-tuple, so:

case _:

would match any value, and can thus already serve as the default.

I wouldn't object to 'else', though.
___
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/SACSWYRDR5Q6LUPAMJCX455RKZ6ZFSY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-23 17:01, Guido van Rossum wrote:
I'm happy to present a new PEP for the python-dev community to review. 
This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and 
Talin.


Many people have thought about extending Python with a form of pattern 
matching similar to that found in Scala, Rust, F#, Haskell and other 
languages with a functional flavor. The topic has come up regularly on 
python-ideas (most recently yesterday :-).


I'll mostly let the PEP speak for itself:
- Published: https://www.python.org/dev/peps/pep-0622/ (*)
- Source: https://github.com/python/peps/blob/master/pep-0622.rst

(*) The published version will hopefully be available soon.

I want to clarify that the design space for such a match statement is 
enormous. For many key decisions the authors have clashed, in some cases 
we have gone back and forth several times, and a few uncomfortable 
compromises were struck. It is quite possible that some major design 
decisions will have to be revisited before this PEP can be accepted. 
Nevertheless, we're happy with the current proposal, and we have 
provided ample discussion in the PEP under the headings of Rejected 
Ideas and Deferred Ideas. Please read those before proposing changes!


I'd like to end with the contents of the README of the repo where we've 
worked on the draft, which is shorter and gives a gentler introduction 
than the PEP itself:



# Pattern Matching

This repo contains a draft PEP proposing a `match` statement.

Origins
---

The work has several origins:

- Many statically compiled languages (especially functional ones) have
   a `match` expression, for example
   
[Scala](http://www.scala-lang.org/files/archive/spec/2.11/08-pattern-matching.html),

   [Rust](https://doc.rust-lang.org/reference/expressions/match-expr.html),
   
[F#](https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching);

- Several extensive discussions on python-ideas, culminating in a
   summarizing
   [blog 
post](https://tobiaskohn.ch/index.php/2018/09/18/pattern-matching-syntax-in-python/)

   by Tobias Kohn;
- An independently developed [draft
   
PEP](https://github.com/ilevkivskyi/peps/blob/pattern-matching/pep-.rst)

   by Ivan Levkivskyi.

Implementation
--

A full reference implementation written by Brandt Bucher is available
as a [fork]((https://github.com/brandtbucher/cpython/tree/patma)) of
the CPython repo.  This is readily converted to a [pull
request](https://github.com/brandtbucher/cpython/pull/2)).

Examples


Some [example 
code](https://github.com/gvanrossum/patma/tree/master/examples/) is 
available from this repo.


Tutorial


A `match` statement takes an expression and compares it to successive
patterns given as one or more `case` blocks.  This is superficially
similar to a `switch` statement in C, Java or JavaScript (an many
other languages), but much more powerful.

The simplest form compares a target value against one or more literals:

```py
def http_error(status):
     match status:
         case 400:
             return "Bad request"
         case 401:
             return "Unauthorized"
         case 403:
             return "Forbidden"
         case 404:
             return "Not found"
         case 418:
             return "I'm a teapot"
         case _:
             return "Something else"
```

Note the last block: the "variable name" `_` acts as a *wildcard* and
never fails to match.

You can combine several literals in a single pattern using `|` ("or"):

```py
         case 401|403|404:
             return "Not allowed"
```

Patterns can look like unpacking assignments, and can be used to bind
variables:

```py
# The target is an (x, y) tuple
match point:
     case (0, 0):
         print("Origin")
     case (0, y):
         print(f"Y={y}")
     case (x, 0):
         print(f"X={x}")
     case (x, y):
         print(f"X={x}, Y={y}")
     case _:
         raise ValueError("Not a point")
```

Study that one carefully!  The first pattern has two literals, and can
be thought of as an extension of the literal pattern shown above.  But
the next two patterns combine a literal and a variable, and the
variable is *extracted* from the target value (`point`).  The fourth
pattern is a double extraction, which makes it conceptually similar to
the unpacking assignment `(x, y) = point`.

If you are using classes to structure your data (e.g. data classes)
you can use the class name followed by an argument list resembling a
constructor, but with the ability to extract variables:

```py
from dataclasses import dataclass

@dataclass
class Point:
     x: int
     y: int

def whereis(point):
     match point:
         case Point(0, 0):
             print("Origin")
         case Point(0, y):
             print(f"Y={y}")
         case Point(x, 0):
             print(f"X={x}")
         case Point():
             print("Somewhere else")
         case _:
             print("Not a point")
```

We can use 

[Python-Dev] Re: When can we remove wchar_t* cache from string?

[MRAB]

On 2020-06-12 09:32, Inada Naoki wrote:

Hi, all.

Py_UNICODE has been deprecated since PEP 393 (Flexible string representation).

wchar_t* cache in the string object is used only in deprecated APIs.
It waste 1 word (8 bytes on 64bit machine) per string instance.

The deprecated APIs are documented as "Deprecated since version 3.3,
will be removed in version 4.0."
See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis

But when PEP 393 is implemented, no one expects 3.10 will be released.
Can we reschedule the removal?

My proposal is, schedule the removal on Python 3.11.  But we will postpone
the removal if we can not remove its usage until it.

I grepped the use of the deprecated APIs from top 4000 PyPI packages.

result: 
https://github.com/methane/notes/blob/master/2020/wchar-cache/deprecated-use
step: https://github.com/methane/notes/blob/master/2020/wchar-cache/README.md

I noticed:

* Most of them are generated by Cython.
   * I reported it to Cython so Cython 0.29.21 will fix them.  I expect
more than 1 year
 between Cython 0.29.21 and Python 3.11rc1.
* Most of them are `PyUnicode_FromUnicode(NULL, 0);`
   * We may be able to keep PyUnicode_FromUnicode, but raise error when 
length>0.

I think it would be strange to keep PyUnicode_FromUnicode but complain 
unless length == 0. If it's going to be removed, then remove it and 
suggest a replacement for that use-case, such as PyUnicode_FromString 
with a NULL argument. (I'm not sure if PyUnicode_FromString will accept 
NULL, but if it currently doesn't, then maybe it should in future be 
treated as being equivalent to PyUnicode_FromString("").)

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

[Python-Dev] Re: Repr: where to place the address and additional info?

[MRAB]

On 2020-05-29 21:02, Serhiy Storchaka wrote:

The default repr of Python object is formatted using the following pattern:

  <{typename} object at {address:#x}>

And many custom reprs use similar patterns, but add some additional type
specific information. The type name first, followed by details and
address. All is surrounded by angle quotes. The question is in what
order to show address and other details? Should the address be at rear
or in the middle?

  <{typename} {details} at {address:#x}>
  <{typename} at {address:#x} {details}>

There are examples of both ways in the stdlib. I am going to add new
custom reprs [1] and need to know what pattern looks better.

Also, is "object" mandatory after the type name?

  <{typename} object {details} at {address:#x}>
  <{typename} object at {address:#x} {details}>

[1] https://bugs.python.org/issue24391

FWIW, my preference is for the address at the end for reasons already 
stated in the issue.

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

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[MRAB]

On 2020-05-21 00:29, Emily Bowman wrote:
Python has always preferred full-word over old-school C/Perl/PHP-style 
abbreviated names. Clarity is paramount. (Or this whole discussion 
wouldn't even be happening.)



[snip]
... apart from len, def, int, float, str, etc.
___
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/CXRBJETQJNBE27K3ASEB4H47BD4NYHE7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[MRAB]

On 2020-05-15 20:36, David Mertz wrote:
On Fri, May 15, 2020 at 12:55 PM Eric V. Smith > wrote:


Also: The PEP says "At most one additional item may be consumed from
one of the iterators when compared to normal zip usage." I think
this should be prefaced with "If ValueError is raised ...". Also,
why does it say "at most one additional item". How could it ever be
less than one?


This struck me as strange also.  I mean, the wording can be improved to 
clarify "if error."


But more significantly, it seems like it cannot conceivably be true.  If 
might be "At most one additional item from EACH of the iterators."


If I do zip_strict(a, b, c, d, e) and "e" is the one that is shorter, 
how could any algorithm ever avoid consuming one extra item of a, b, c, 
and d each?!



Well, it does say "when compared to normal zip usage".

The normal zip would consume an item of a, b, c, and d. If e is 
exhausted, then zip would just stop, but zip_strict would raise 
ValueError. There would be no difference in the number of items consumed 
but not used.

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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[MRAB]

On 2020-03-22 05:00, Dennis Sweeney wrote:

I like "removeprefix" and "removesuffix". My only concern before had been length, but 
three more characters than "cut***fix" is a small price to pay for clarity.


How about "dropprefix" and "dropsuffix"?
___
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/UL3SAVB3RGFTRFERG3J3VQNPQBXWTV7G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[MRAB]

On 2020-03-20 21:49, Dennis Sweeney wrote:

For clarity, I'll change

  If ``s`` does not have ``pre`` as a prefix, an unchanged copy of ``s`` is 
returned.

to

 If ``s`` does not have ``pre`` as a prefix, then ``s.cutprefix(pre)`` 
returns ``s`` or an unchanged copy of ``s``.

For consistency with the Specification section, I'll also change

 s[len(pre):] if s.startswith(pre) else s

to

 s[len(pre):] if s.startswith(pre) else s[:]

and similarly change the ``cutsuffix`` snippet.


If ``s`` is immutable, why return a copy when the original will do?

s[len(pre) : ] if pre and s.startswith(pre) else s

s[ : -len(suf)] if suf and s.endswith(suf) else s
___
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/AP6L5H4H3E3RP6FZD4NS6NTLNV4KCQMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[MRAB]

On 2020-01-31 19:58, Ethan Furman wrote:

On 01/31/2020 10:47 AM, Mike Miller wrote:

On 2020-01-23 07:20, Victor Stinner wrote:



Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.

Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?


I've gotta say, I like that plan.  Instead of going to x.10, go to x+1.0.  
Every ten years we bump the major version and get rid of all the deprecations.


It has a certain appeal for me too.
___
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/Q24LBBZ4P2PAUBU5B2K7HNXP3HJXFBEP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.8 error?

[MRAB]

On 2019-12-09 18:22, Christian Tismer wrote:

On 08.12.19 09:49, Nick Coghlan wrote:

On Fri., 6 Dec. 2019, 3:31 am Christian Tismer, mailto:tis...@stackless.com>> wrote:

Hi guys,

during the last few weeks I have been struggling quite much
in order to make PySide run with Python 3.8 at all.

The expected problems were refcounting leaks due to changed
handling of heaptypes. But in fact, the runtime behavior was
much worse, because I always got negative refcounts!

After exhaustive searching through the different 3.8 commits, I could
isolate the three problems with logarithmic search.

The hard problem was this:
Whenever PySide creates a new type, it crashes in PyType_Ready.
The reason is the existence of the Py_TPFLAGS_METHOD_DESCRIPTOR
flag.
During the PyType_Ready call, the function mro() is called.
This mro() call results in a negative refcount, because something
behaves differently since this flag is set by default in mro().

When I patched this flag away during the type_new call, everything
worked ok. I don't understand why this problem affects PySide
at all. Here is the code that would normally be only the newType line:


    // PYSIDE-939: This is a temporary patch that circumvents the
problem
    // with Py_TPFLAGS_METHOD_DESCRIPTOR until this is finally solved.
    PyObject *ob_PyType_Type = reinterpret_cast(_Type);
    PyObject *mro = PyObject_GetAttr(ob_PyType_Type,
Shiboken::PyName::mro());
    auto hold = Py_TYPE(mro)->tp_flags;
    Py_TYPE(mro)->tp_flags &= ~Py_TPFLAGS_METHOD_DESCRIPTOR;
    auto *newType = reinterpret_cast(type_new(metatype,
args, kwds));
    Py_TYPE(mro)->tp_flags = hold;


Isn't this manipulating the flags in the tuple type, rather than
anything on a custom object? Or is "mro" a custom object rather than an
MRO tuple?

If anything, given the combination of factors required to reproduce the
problem, I would guess that there might be a ref counting problem in the
__set_owner__ invocations when called on a new type rather than a
regular instance, and that was somehow affected by the change to
increment the type refcount in PyObject_Init rather than
PyType_GenericAlloc.



Hi Nick,

after staring long at the code, I fount something funny in
typeobject.c #286 ff:


static void
type_mro_modified(PyTypeObject *type, PyObject *bases) {
 /*
Check that all base classes or elements of the MRO of type are
able to be cached.  This function is called after the base
classes or mro of the type are altered.

Unset HAVE_VERSION_TAG and VALID_VERSION_TAG if the type
has a custom MRO that includes a type which is not officially
super type, or if the type implements its own mro() method.

Called from mro_internal, which will subsequently be called on
each subclass when their mro is recursively updated.
  */
 Py_ssize_t i, n;
 int custom = (Py_TYPE(type) != _Type);
 int unbound;
 PyObject *mro_meth = NULL;
 PyObject *type_mro_meth = NULL;

 if (!PyType_HasFeature(type, Py_TPFLAGS_HAVE_VERSION_TAG))
 return;

 if (custom) {
 _Py_IDENTIFIER(mro);
 mro_meth = lookup_maybe_method(
 (PyObject *)type, _mro, );
 if (mro_meth == NULL)
 goto clear;
 type_mro_meth = lookup_maybe_method(
 (PyObject *)_Type, _mro, );
 if (type_mro_meth == NULL)
 goto clear;
 if (mro_meth != type_mro_meth)
 goto clear;
 Py_XDECREF(mro_meth);
 Py_XDECREF(type_mro_meth);
 }


Look at the "if (custom)" clause.
"mro_meth = lookup_maybe_method(" uses lookup_maybe_method which
gives a borrowed reference. The same holds for "type_mro_meth".

But then both are decreffed, which IMHO is not correct.


Look at what happens at the label "clear": it DECREFs them.

If mro_meth != NULL or mro_meth != type_mro_meth, they'll get DECREFed 
at "clear".

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

[Python-Dev] Re: Implementation of PEP-0604

[MRAB]

On 2019-11-17 20:09, Ivan Levkivskyi wrote:
To add some more input about forward references, here are couple of 
thoughts:


1. I think ideally we should support forward references to the same 
extent they are currently supported:
i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and 
Union["ForwardRef", "OtherForwardRef"]
should all be supported. The last one looks the hardest, in the sense 
that it looks like we will need

to add `str.__or__()` to support these forms.

I'm not sure I like the thought of adding `str.__or__()` because it 
would mean that "Foo" | "Bar" becomes valid and returns a type, which is 
unexpected.


Perhaps an alternative would be to add 'Forward' to make it explicit:

Forward("ForwardRef") | Forward("OtherForwardRef")

or just:

Forward("ForwardRef") | "OtherForwardRef"

2. Forward references to type variables were never supported and we 
shouldn't start supporting this
(even if it accidentally worked in some situations). Type variables 
should always be defined before use.

So I think we should not worry about point 3 in Richard's e-mail.

Philippe, I think it makes sense to reflect these points to the PEP draft.


[snip]


On Thu, 14 Nov 2019 at 02:23, Richard Eames > wrote:


Thanks for the encouragement!

I've been working some more on it since I had some more free cycles
in the last few days and I think I've got to the limit of my
capabilities. I think I've got it to a point where it needs more
eyes because my experience level writing code in the python
interpreter is pretty low, so I know that I have holes in there,
especially around using INCREF/DECREF.
I'm currently stuck on 3 things:

1. repr( pickle.loads( pickle.dumps(int | str) ) ) causes an
infinite recursion that I can't figure out. I might end up
re-specializing `repr()` again since it isn't defined in the PEP.

2.
- `None | "forwardref"` and `None | None`
- `"forwardref" | None` and `"forwardRefA" | "forwardRefB"`
I've had a go at adding a `type.__ror__` as suggested by GvR, but I
think I'm missing something.

3. type parameters
- I'm not sure how to handle this:
```
MaybeT = None | "T" # creates shadow union
T = TypeVar('T')
maybe_int = MaybeT[int] # should this stay in shadow land, or go
back to typing.py
isinstance(1, maybe_int)
isinstance(1, MaybeT[int])
```
I have a couple options for this:
- implement the type substitution in c; which can be done, but feels
like overkill?
- store the type parameters on the shadow object and vivify when
needed (which will end up being in the isinstance call)
- implement the __getitem__ as a call into the typing.py library and
promote as it's requested. This is how I've currently implemented it.

I'm happy to keep going on this if/when needed,


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

[Python-Dev] Re: [RELEASE] Python 3.8.0 is now available

[MRAB]

On 2019-10-15 19:03, MRAB wrote:

On 2019-10-14 21:23, Łukasz Langa wrote:
On behalf of the Python development community and the Python 3.8 release 
team, I’m pleased to announce *the availability of Python 3.8.0*.



[snip]
I've installed pywin32 on Python 3.8, but when I try to import
win32clipboard it says it can't find it:

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
  >>> import win32
  >>> import win32clipboard
Traceback (most recent call last):
File "", line 1, in 
ImportError: DLL load failed while importing win32clipboard: The
specified module could not be found.
  >>>

Does anyone else have this problem?

I found the solution: copy pywintypes38.dll and pythoncom38.dll from 
site-packages/pywin32_system32 into site-packages/win32.

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

[Python-Dev] Re: [RELEASE] Python 3.8.0 is now available

[MRAB]

On 2019-10-14 21:23, Łukasz Langa wrote:
On behalf of the Python development community and the Python 3.8 release 
team, I’m pleased to announce *the availability of Python 3.8.0*.



[snip]
I've installed pywin32 on Python 3.8, but when I try to import 
win32clipboard it says it can't find it:


Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 
bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import win32
>>> import win32clipboard
Traceback (most recent call last):
  File "", line 1, in 
ImportError: DLL load failed while importing win32clipboard: The 
specified module could not be found.

>>>

Does anyone else have this problem?
___
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/MHSHP3Z5TN4SDSG6G3MLAV6H56C36DHP/
Code of Conduct: http://python.org/psf/codeofconduct/