[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Henk-Jaap Wagenaar]

On Sat, 21 Nov 2020 at 19:58, Glenn Linderman  wrote:

> Don't () already indicate an expression to be evaluated?
>

Does it?

[(a, b)] = [(0, 1)]
print(a)

gives 0 as output.
___
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/2HUHO5RB3UKNCHVVX6AAY6ZS25DSNCTL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Henk-Jaap Wagenaar]

On Wed, 24 Feb 2021 at 10:18, Antoine Pitrou  wrote:

> On Tue, 23 Feb 2021 20:29:52 -0500
> Jonathan Goble  wrote:
> >
> > I can't speak for distributors or maintainers [1], but I can speak for
> > myself as a user. I run Debian testing (currently bullseye as that is
> > preparing for release) as my daily OS on my personal laptop, used for
> > personal matters and school assignments (I'm a university computer
> > science student in my senior year).
> >
> > I don't use the system Python for anything of my own, whether it's a
> > school assignment or a personal project, precisely because I don't
> > want to risk screwing something up. Rather, I maintain a clone/fork of
> > the official CPython GitHub repo, and periodically build from source
> > and `make altinstall` into `~/.local/`.
>
> For the record, instead of building Python by hand, you could use a
> distribution such as Anaconda or the community-maintained conda-forge.
>
> Regards
>
> Antoine.
>
>
I've been using pyenv (on MacBooks to be fair, not Linux/Debian) and been
quite happy with that, and it basically does what Jonathan does manually:
clone the github repo and build python from scratch.
___
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/OZRHP3Q6EZNCPCTEEXLZGOCTGY6B7YFW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Mon, 10 May 2021 at 08:34, M.-A. Lemburg  wrote:

> [...]

PS: It looks like the discussion has wondered off to Discourse
> now. Should we continue there ?
>
> --
> Marc-Andre Lemburg
> eGenix.com
>

Pablo seems to want to redirect the discussion there yes, in particular to:

https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in-tracebacks/8629

On Sun, 9 May 2021 at 16:25, Pablo Galindo Salgado 
wrote:

> [...]
> The discussion is happening in the discourse server:
>
>
> https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in-tracebacks/8629
>
> To avoid splitting the discussion, *please redirect your comments there*
> instead of replying to this thread.
>
> Thanks!
>
> Regards from sunny London,
> Pablo Galindo Salgado
>
___
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/6JBZUB3ABNZYMSDKDED2V2SYFP73QZV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Henk-Jaap Wagenaar]

On Tue, 22 Jun 2021 at 10:06, Petr Viktorin  wrote:

> On 21. 06. 21 20:20, Guido van Rossum wrote:
> > Okay, I think your evidence can then be discounted. Really, any app that
> > relies on the publicly installed Python runs a serious risk of breaking
> > when that Python gets updated, regardless of whether the ABI changes or
> not.
>
> Unfortunately, this includes scripts for any extensible software
> (Mayavi, GIMP, etc) -- even if Python is bundled with that software,
> upgrading the software risks breaking the scripts.
>
>
I'm confused by what you mean by this, or why it is a problem?

If I upgrade GIMP (and it vendors some version/variant of Python), it is
not unreasonable that this would break a script that I have written in
GIMPython? (GIMP should probably mention that it has changed its Python and
how in the changelog/release notes)

If I upgrade my OS, and I use the system Python, scripts I have written
might break too.

(Of course, GIMP is a placeholder here, I do not actually know what it does
in terms of Python (vendoring), if at all.
___
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/FPTXDP3BLIPJH3WTFPTORTC5HDBJC2L5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to respond to repeated bad ideas

[Henk-Jaap Wagenaar]

On Tue, 3 Mar 2020 at 07:27, Serhiy Storchaka  wrote:

> 03.03.20 01:03, Skip Montanaro пише:
> >> Atm we don't have an index of ideas, apart from pep 3099, and I'm not
> sure we can make one (can we?), so I do not see a way to prevent this from
> happening.
> >
> > Maybe an informational PEP which briefly lists rejected ideas?
>
> There is a risk to accept this PEP as it happened to PEP 572 which was
> initially created with a similar purpose.
>

If after an idea is rejected it is later accepted (which would probably be
harder to have happen, as it has been rejected before), due to changing
circumstances or sentiment I would expect the acceptance to be a *good*
thing. Previous decisions should not bind future decisions?

I might have misunderstood your point.
___
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/UYABOIPHEBBSH42NGH4F4XPLYUGC52GT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: For-If syntax

[Henk-Jaap Wagenaar]

We seem to be, once again, rehashing about this.  For example, I proposed
this in 2017, which was not the first time:

https://mail.python.org/archives/list/python-id...@python.org/thread/GFZFJAI4WGFYFFVQTF7DORHMY7F45XZZ/

(Gary's suggestion, and (counter) counter points to it are in the linked
discussion)

Would it maybe be time for someone to write a PEP for this (if they can be
found), so it can then be rejected (or not)?

I think there is no bikeshedding to be done on the idea, though in terms of
parsing there might be (though as I mentioned in that thread, there should
be no difference to generator expression parsing).

On Fri, 1 May 2020 at 19:52, Gary Herron  wrote:

>
> On 5/1/20 9:19 AM, silverback...@gmail.com wrote:
>
> I hope this isn't too noobish, nothing on the list comes up in Google, but
> I'm curious why the construct
>
> for x in y if x.is_some_thing:
>   # do a thing
>
> But this is probably clearer (and has the same syntax):
>
> for x in y:
>   if x.is_some_thing:
> # do a thing
>
>
> Cramming two separate thoughts onto a single line is probably *not*
> clearer.
>
>
>
> isn't legal. That seems a very Pythonic symmetry with lambdas. The
> equivalent syntax required right now is,
>
> for x in [x for x in y if x.is_some_thing]:
>   # do a thing
>
> Of course there's more flexibility in the full syntax, but is there any
> interest in the simpler, more performant one-line syntax?
>
> Em
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VHFUQFEF3TCI6LHLBAUEKMFM2A6V3CQO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> Dr. Gary Herron
> Professor of Computer Science
> DigiPen Institute of Technology
> (425) 895-4418
>
> ___
> 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/T3VQGGAHYR4AOKMVPL5NDTAV2GB6BIAH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SBEKOAFBUNVFXR5UXCSFF6HPEE4GEE6O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 349 --- deferred but now obsolete?

[Henk-Jaap Wagenaar]

The following deferred PEP seems to have become obsolete due to time/Python
marching on:

PEP 349 - Allow str() to return unicode strings
https://www.python.org/dev/peps/pep-0349/

As there is now not non-unicode strings anymore (unless I am
misunderstanding the PEP).

What should the state of this PEP be updated to?

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

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Henk-Jaap Wagenaar]

I'll join in with the fun...

zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1

On Fri, 15 May 2020 at 19:12, Paul Moore  wrote:

> [Cut the previous votes because someone's quoting didn't survive my
> email client and I can't be bothered fixing it]
>
> If everyone else is doing it...
>
> itertools.zip_strict() +1
> zip(strict=True) -0
> zip.strict() -0.5
> zip(mode='strict') -1
>
> Paul
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4YDZH7E6IYDI4EQJPUREUZAYVQE5ITI6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LY6NYA4NQKE37XILEIQD3KZQ4FQ3BEN5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Henk-Jaap Wagenaar]

On Fri, 15 May 2020 at 21:50, Eric V. Smith  wrote:

> I fear that my comment on some text in the PEP was lost amidst the
> voting, so I'm repeating it here. This will probably screw up some
> threading, but this is the oldest message I have to reply to.
>
> 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?
>

It seems to me, looking at the Python implementation in the PEP (not the
current or C implementation) that the crux is here:

except StopIteration:
if not strict:
return
 if items:
i = len(items) + 1
raise ValueError(f"zip() argument {i} is too short")

So if it is not strict, it will return/stop consuming iterators. If it is
strict but it runs out *not* on the first iterator it will also not consume
from another iterator?


> And I'm not sure I'd say "normal zip usage", maybe "the existing builtin
> zip function".
>

Depends on where we end up I guess, if we go with what Brandt' PEP says
(makes sense to keep internally consistent) I'd say "zip without the
strict=True flag" or similar.

>
> Eric
> ___
> 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/ZEY2QHBSILZZHL7ISYZTHC4KHJ4JTBI7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ASL5UENQJVANGZQRQEFKRIC3RERPN6XZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Voting conventions [was: PEP 618: Add Optional Length-Checking To zip]

[Henk-Jaap Wagenaar]

I used the same convention as you, and my vote was thus as the record will
show (note the negatives):

zip(strict=True) +1
itertools.zip_strict() +0
zip(mode='strict') -1
zip.strict() -1

And I stand by that: I think Python would be better off without the 3rd and
4th option, even if no alternative was implemented. To go to one of the
examples (not exactly, you'll understand why...) was given in the other
thread: if we suggested

asdfasfa.kjllasdfa.asdf()

as the name(space) for the zip(strict=True) functionality, I would:

- vote -1 (or hyperbole -10^googol)
- still use the feature when I wanted to use 'zip(strict=True)'
- think Python would be a worse programming environment for allowing this
to be introduced

Obviously the 3rd and 4th option are not as insane/illogical as the above
example (apologies, I would attribute, but the nature of this example makes
it hard for me to search for it!) but I do not like functionality exposed
in this way and I think the lack of this functionality in the stdlib does
not weigh up against the precedent/bad example this would set.

You, and anyone else, can and some definitely will disagree with me but
it's my vote, and I don't think it matters that much anyway:

There has been a lot of discussion, and these straw polls, from my limited
understanding, are often taken to see whether there is a clear consensus to
short-circuit/end the discussion, I would say in this case it has shown
inconclusiveness, which is fine, the final decision on this PEP will
(fortunately) not be decided by our votes.

I understand your 'pain' Stephen: I still think it is weird that people on
these lists don't want "for x in some_iterable if x is not None:" as valid
syntax, but I have, almost, made my peace with it.

On Sun, 17 May 2020 at 18:42, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> These negative votes surprise me.
>
> Given that it's clear that a generic strict-mode zip is non-trivial to
> write, and that there is significant demand for it, are people saying
> "+0 Python would not be a better programming environment if
> itertools.zip_strict() were adopted," and "-1 Python would be a worse
> programming environment if zip.strict() were adopted"?
>
> I can see why folks would say the latter about zip.strict(), but even
> though I really dislike the mode switches, I'm still positive about
> adding them if one of them ranks highest among those who care.  I'm
> not going to give them negative votes, they don't make Python worse.
>
> I don't mind hyperbole ("I'm +1000 on this feature!" or "-10 on the
> worst proposal I've seen since  removed>!")  But I would like it if "0" meant "indifferent", "+1"
> meant "no-brainer, add it", and "-1" meant "no-brainer, just don't".
>
>
> FWIW,
>
> +1   itertools.zip_strict(*iterables)
> +0.5 zip(*iterables, mode)# mode is 3-way, default
> "shortest"
> +0.4 zip(*iterables, strict)  # strict is boolean, default
> False
> +0   zip.strict(*iterables)
> ___
> 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/DLHIE5DOI5G3IH7OEK7RDW2K37DEQ7VB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IXCPI6VHT3DLQKESDJ5KAV372J4PE7ZW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

To paraphrase the Bible: "For where two or three gather, there is politics
with them."

Changing the commit message, as it has been merged, is now practically hard
and highly unusual. If you use GitHub search, you can find other examples
of commit messages that would be rewritten if that was doable without cost:
https://github.com/python/cpython/search?q=fuck&type=Commits: such commits
would not be merged now I imagine *if it was caught before merging* (of
course, the repo was not even in git at the time, so there were no pull
requests et cetera at the time...) but would have to stay in if already
merged. In this case, as is common I think for most software developers or
anyone writing any text: I think the main reason all messages are
different: commit, email and PR is because they were written at different
times and the writer found better ways of distilling their thought process
and also got external input through the email thread. In particular, I
think it is common for commit messages to be different from the PR messages
(precisely because of this!) and as many has said, and as we should
remember, this commit (the actual change) was brought by a volunteer in
their own time, and had broad agreement (though not unanimous) on the
mailing list, yet now we have ended up having a massive mail thread
discussing their particular contribution and I am sure they feel obliged to
read all these messages. So let's compare the three:

*Commit*
"Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without upholding relics of white supremacy. Many native English speakers
do not use Standard English as their native dialect, so requiring
conformation to Standard English centers whiteness in an inappropriate and
unnecessary way, and can alienate and put up barriers for people of color
and those whose native dialect of English is not Standard English. This
change is a simple way to correct that while maintaining the original
intent of the requirement."

*Email*
"[...] Instead of requiring that comments be written in Strunk & White
Standard English, PEP-8 should require instead that English-language
comments be clear and easily understandable by other English speakers. This
accomplishes the same goal without alienating or putting up barriers for
people (especially people of color) whose native dialect of English is not
Standard English. This change is a simple way to correct that while
maintaining the original intent of the requirement."

*Pull Request*
"Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without alienating or putting up barriers for people (especially people of
color) whose native dialect of English is not Standard English. This change
is a simple way to correct that while maintaining the original intent of
the requirement. This change also makes the requirement more clear to
people who are not familiar with Strunk & White, since for programmers, the
main relevant aspect of that standard is "be clear and concise;" simply
saying that instead of referencing Strunk & White communicates this more
effectively."

Clearly, the last sentence (starting "This change also") was added after
the email thread, *however* note the commit (message) was written before
that discussion took place or the PR was made. I think all three texts
(barring the addition in the third one) have the same spirit because
- "a person of color" is anybody who is not Caucasian/white according to
the definition as I understand it and so does Wikipedia:
https://en.wikipedia.org/wiki/Person_of_color
- "white supremacy" has the academic definition similar to/being "white
privilege": https://en.wikipedia.org/wiki/White_supremacy and that's how I
read it here, not an ideology, especially given the context
and so I think working against alienation of "persons of colors" is
aligned/has a similar meaning to with reducing [the relics of] "white
privilege" [in not being alienated in terms of language expected in Python
comments] and are similarly "political" (I would say "inclusive" and
"uncontroversial", but to each their own). I think if you think any one of
these 3 is "political", they all are, so to fall over the commit message in
particular (because it says "white supremacy"?) seems inconsistent to me.

All 3 texts to me are not political, or at least not political beyond what
has already been decided: inclusivity in language is explicit in the CoC:
"Using welcoming and inclusive language. We're accepting of all who wish to
take part in our activities, fostering an environment where anyone can
participate and everyone can make a difference." You might disagree whether
that should be in the Code of Conduct or whe

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

[Henk-Jaap Wagenaar]

I agree with you it is over the top, but let's enjoy the popcorn together!

On Wed, 1 Jul 2020 at 01:35, Greg Ewing  wrote:

> Sorry for fanning the flames, but this whole thread is so over
> the top I'm finding it kind of entertaining.
>
> On 1/07/20 2:23 am, Piper Thunstrom wrote:
> > The grammarian movement, in general, was built on
> > elevating a very specific form of English over others. It specifically
> > was chosen to avoid "lower class" usages
>
> This argument seems to rest on the assumption that "lower
> class" equates to "non-white". This is an extremely US-centric
> idea. It could possibly even be described as exhibiting a
> "breathtaking level of ignorance"...
>
> > the
> > Elements of Style (And many works like it) are built on a system of
> > white supremacy.
>
> If that's true, then the entirety of Western culture is built
> on a system of white supremacy. That includes all our modern
> technology. It includes the Python programming language. We'd
> better stop recommending Python to people!
>

I kind of of agree with your (attempt) at reductio ad absurdum: Python and
Western culture is built on a system of white supremacy (read: white
privilege, academic definition of the word), and if we were not trying to
fix this (by changes like the one in this commit, or the PSFs stance on
inclusivity in the CoC and active work towards this) I would probably
actually recommend people to stop using Python: I have stopped watching
content because I do not agree with the stances taken by its creator, even
when it has not directly affected the content (insofar as I can tell). To
take your argument itself to the extreme and Godwin myself, if a neonazi
group developped an amazing programming language that had a swastika for
its symbol and was littered with references to the Nazis and their
ideology, would you recommend it?


>
> > Each individual who likes
> > Elements of Style is not wrong for liking the book, you can keep it on
> > your shelf and no one will be angry.
>
> Okay, I'm confused. S&W is a symbol of white supremacy that
> shall never be recommended or mentioned in polite company, but
> it's all right to have one on your shelf, as long as you keep it
> to yourself... or something?
>
> You can't have it both ways.
>

What I think was meant here: S&W is inappropriate to use as a community
guideline for a diverse community like Python because it is not inclusive
and forces (a particular version of) "Standard English" on others, however,
you using it for your own writing (while not imposing it on others) is not
an issue. As an analogy, in the US it is illegal (as determined by the
Supreme Court) for state officials to compose an official school prayer and
require its recitation in school, even when those who wish can excuse
themselves from reciting it, on the other hand, if a state official
composed an official before-school prayer but that was not required to be
recited in school, this would be legal and it would be fine for a parent to
frame it, display it and have their child pray it before leaving for
school: it would then even be ok for the kid to tell the others and their
teacher that that's what they do at home!


>
> --
> Greg
> ___
> 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/MQK33M4FPH2HGOSA6FO7SOI65C577WMH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FEV7GJCOMTUI53PE3OYXICYBJLZ4FB4F/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Tue, 30 Jun 2020 at 11:49, Ethan Furman  wrote:

> - it has been modernized as times have changed (the 2000 edition removed
> the advice
>to use masculine pronouns whenever possible, and warns that some will
> find unnecessary
>masculine usage offensive)
>

PEP-8 however does not mention a particular edition and the version that is
readily available (in the public domain) does contain this problematic
section "to use the masculine pronouns whenever possible" which is not
inclusive. Hence, I think we would be better off not mentioning it or
failing that, mentioning a particular edition. I think times/language norms
for inclusivity have changed a lot since 2000 (two decades), so another
style guide that was more recently updated might be better, if we think
there should be one mentioned at all.

This is the version I found on Gutenberg:
http://www.gutenberg.org/files/37134/37134-h/37134-h.htm and the particular
problematic section I mentioned is this:


> 'They. A common inaccuracy is the use of the plural pronoun when the
> antecedent is a distributive expression such as each, each one, everybody,
> every one, many a man, which, though implying more than one person,
> requires the pronoun to be in the singular. Similar to this, but with even
> less justification, is the use of the plural pronoun with the antecedent
> anybody, any one, somebody, some one, the intention being either to avoid
> the awkward “he or she,” or to avoid committing oneself to either. Some
> bashful speakers even say, “A friend of mine told me that they, etc.”



Use he with all the above words, unless the antecedent is or must be
> feminine.'
___
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/K5UISYDXKYKSGOVRDQEWUELCOM5GPJUL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Thu, 2 Jul 2020 at 14:52, Paul Moore  wrote:

> On Thu, 2 Jul 2020 at 14:34, Henk-Jaap Wagenaar
>  wrote:
>
> > PEP-8 however does not mention a particular edition and the version that
> is readily available (in the public domain) does contain this problematic
> section "to use the masculine pronouns whenever possible" which is not
> inclusive.
>
> (This is a genuine question, and I'm terrified of being yelled at for
> asking it, which gives an idea of the way this thread has gone - but I
> genuinely do want to know, to try to improve my own writing).
>
> 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
>

As others have said and more eloquently, I use and would suggest to use
(singular) "they" or rephrase it. Furthermore, I have seen no rationale
against "they" that I think holds any water (though of course, now one will
surface!) and I have not seen it criticized recently. It seems incredibly
common in circles I frequent that when an old document is reviewed every
occurence of "he" is simply replaced with "they".
___
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/VDOMLNPBJEK5YNV5FRCFK23C6QNTGKG6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Thu, 2 Jul 2020 at 16:16, Éric Araujo  wrote:

> Le 2020-07-02 à 09 h 52, Paul Moore a écrit :
> > 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?
>
> One technique is alternating genders for the imagined user or developer.
> Otherwise the singular they is the easiest way.
>

I do not think that technique is as inclusive as we should aim to be
(apologies if I get this wrong in terms of gender v.s. sex): there are
those who do not self-identify as either gender or prefer another pronoun
(I know some who prefer to be called "they" instead of he or she and do not
identify as male or female): hence using (singular) they is simply easiest
and unoffensive (in my view).
___
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/PUAZ7LHRVGYG5DS4TJTTQGUTOO4UZEH2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Thu, 2 Jul 2020 at 20:33, Chris Angelico  wrote:

> On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev
>  wrote:
> >
> > If you are talking about rewriting the PEP8 commit, it has proven to
> cause so much damage that this is warranted despite the inconveniences IMO.
> >
>
> I think I agree. The consequences would be notable, but not untenable.
>

I disagree that this should be done. When has this been done/requested
before for a commit message that is already merged?


> Formal proposal: Either request a new commit message from the original
> author, or have someone rewrite it, and we go ahead and make the
> change.
>

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

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

[Henk-Jaap Wagenaar]

On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

>
> Per
> https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/,
> we're talking about an infinitely
> less impactful peps repo (per
> https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/,
> only 6
> people in the entire world would be affected).
>
>
It will not affect only 6 people.

That is just the number of people who have forks that we know about and
even those who do not have forks but maintain a copy (for whatever reason)
of the main branch will be affected: they will have to reset their branch
or do some other malarkey to get this new "improved" history. This will be
a much bigger group of people and also potentially software solutions that
are mirroring the repo for one reason or another.

That's one of the prices you pay (or I would say benefit) for having a
decentralized version control system: it makes it hard to rewrite
(supposedly "improve") history.
___
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/ICEY5RDK7P7VWDXH7W6JI76SO57JZB4I/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Henk-Jaap Wagenaar]

On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev  wrote:

> So what?
>
Unnecessary

> They'll have to synchronise their history to ours to be able to make a PR.
> And if they don't, it doesn't matter for us what they do with the data
> anyway since they are responsible for maintaining it and keeping it
> relevant if they need to, not us
>
That is not a very collaborative mindset.

Can somebody give an example of when we force-pushed before? Surely there
should be a PEP outlining when we force push and how we communicate this to
our "consumers" before/when we do so?

> Plus, since it's the PEPs repo, it's tightly bould to the Python project
> -- the usefulness of a fork disconnected from it is pretty low.
>

It partially serves as documentation for the Python project, so mirroring
it and its documentation (in git form or in its presented form) can
definitely have a use, for example, if you are an environment that has no
internet access (common in secret government work, and I am sure their IT
team will be even less pleased that they have to do something by hand and
overwrite history!).

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

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

[Henk-Jaap Wagenaar]

On Fri, 3 Jul 2020 at 14:28, Chris Angelico  wrote:

> On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
>  wrote:
> >
> >
> > On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
> >
> > On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev  wrote:
> >>
> >> So what?
> >
> > Unnecessary
> >>
> >> They'll have to synchronise their history to ours to be able to make a
> PR. And if they don't, it doesn't matter for us what they do with the data
> anyway since they are responsible for maintaining it and keeping it
> relevant if they need to, not us
> >
> > That is not a very collaborative mindset.
> >
> >
> > I fail to see how. We provide all the tools to collaborate. If a person
> has a divergent history, they will see that when trying to collaborate
> (submit a PR or otherwise interact with our repo from theirs in any way)
> and will be able to fix that problem then and there.
> >
> >
> > Can somebody give an example of when we force-pushed before? Surely
> there should be a PEP outlining when we force push and how we communicate
> this to our "consumers" before/when we do so?
> >
>
> Even if someone isn't aware of the change, the PEPs repo *already*
> rewrites commits as they get merged,


That is not the right way of putting it in my opinion. What you describe
below is rewriting commits when merging/completing a pull request
(squashing is common). That is very different to going back to a commit
that is already in the same branch and rewriting that.


> so any discrepancies would be
> papered over cleanly. Consider:
>
> https://github.com/python/peps/pull/1488
> Two commits in the pull request
>
>
> https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2aa
> One commit in the final repo.
>
> If someone has the old version of the repo and creates a pull request,
> we'll just squash all the differences down and create a single commit
> that does the intent in a cleaner way. The only real effect will be a
> bit of noise during the PR process itself.
>
> There has ALREADY been far more hassle resulting from this commit
> message than there would be from a force-push.
>

Maybe, but rewriting it would (a) not make the "hassle" go away and (b)
would in my view create more "hassle".


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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Henk-Jaap Wagenaar]

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

>  I don't like the .name syntax (grit on Tim's monitor; does not
> suggest the meaning). [...] But I don't know what syntax (where necessary)
> to suggest.


+1(000)


>  I'm not keen on special treatment of the '_' variable, and would
> prefer to be able to use 'else:' after 'match'.
>

I used to be in this "camp", however, a (I think valid) point was raised
that "else:" is not a (full) alternative. Due to the restriction on
repeated names (e.g. Point(x, x) is illegal), if you want to "throw away"
intermediate matches, you will have to either have to come up with new
names (Point(unused_1, unused_2)) or use the "_" as currently instituted
(Point(_, _)) and "else:" does not cover that insofar as I can tell.

Would it be possible here to use a syntax/symbol that is illegal instead of
_? I think this has been mooted but my favourite (so far) would be "?" so
you have "case ?:" and "Point(?, ?)".

Would ?name then work instead of ".name" as well? Not sure that makes its
use more/less/equal consistent with the previous suggestion.

Apologies if this has been discussed, I have followed the thread(s) but I
might well have forgotten or missed something!
___
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/XRG7DTFZKBY6E373QKB3TBEBB7D6FWWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Henk-Jaap Wagenaar]

On Tue, 7 Jul 2020 at 17:09, Paul Moore  wrote:

> On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar
>  wrote:
> >
> > On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
> python-dev@python.org> wrote:
> >>
> >>  I don't like the .name syntax (grit on Tim's monitor; does not
> >> suggest the meaning). [...] But I don't know what syntax (where
> necessary) to suggest.
> >
> >
> > +1(000)
>
> There's been traffic on the PEP repository which suggests that there
> is a new version of the PEP incoming which responds to these types of
> concern. I'm not willing to read raw rst diffs, so I haven't checked
> any of the details.
>

"PEP 622: Ditch leading dots for name loads": this is now an ex-syntax, it
is bereft of life (for this, draft, of the PEP, might come back later!):
https://github.com/python/peps/commit/f1de4f169d762cbb46fbfe94d2c01839db9b2f07

In there, it makes a good point that namespaced constants are good,
especially for this kind of thing (you probably want to e.g. match over a
bunch of possible constants which you can then put in an enum or some other
namespace).
___
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/2AP7CECCWKAGXBL27T6MNTRKPS4PS2OH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why does _ need to be special ?

[Henk-Jaap Wagenaar]

On Wed, 8 Jul 2020 at 14:30, Paul Svensson  wrote:

> On Wed, 8 Jul 2020, Rhodri James wrote:
>
> > On 08/07/2020 11:05, Federico Salerno wrote:
> >> What I don't like is the use of _ as catch-all, which is different and
> not
> >> interdependent with its use as throwaway.
> >
> > Any name used as a pattern is a catch-all.  The only difference between
> "case
> > dummy:" and "case _:" is that "_" doesn't bind to the thing being
> matched, but
> > "dummy" does bind to it.
>
> Does "_" really deserve that special treatment ?
> If you don't want to bind to it, you can just use some other dummy,
> same way you don't use "case print:" if you don want to bind that.
>

The not binding is there only to allow the main way in which "_" is special
in match/case:

case [_, _]:

is legal

case [x, x]:

is illegal (under the last PEP I have seen) and you would instead use

case [x, y] if x == y:

See "Algebraic matching of repeated names":
https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names
See "Guards" https://www.python.org/dev/peps/pep-0622/#id6
___
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/RKE7AIR7MKVG2TLWCZZ57SX2BBJEZ3OB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Henk-Jaap Wagenaar]

On Wed, 1 Jul 2020 at 17:09, Guido van Rossum  wrote:

> If you are interested in learning more about how PEP 622 would work in
> practice, but don't feel like compiling a Python 3.10 fork from source,
> here's good news for you.
>
> In a hurry?
> https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb
>

I could not get this to work yesterday and today. It will eventually say:

"Your session is taking longer than usual to start! Check the log messages
below to see what is happening."

But the logs are empty. Is that just me or anybody else too?

I tried Chrome (Windows 10 & macOS) and Safari (macOS).


>
> This will open a Binder instance that runs a Jupyter kernel built from
> Brandt Bucher's fork of Python 3.10 that includes the match statement. This
> is a complete implementation of the PEP. (Note that we've already made some
> design changes in response to feedback, but the basic syntax is still the
> same. Expect a new draft within a week.)
>
> The code for the playground was contributed by Fernando Perez, Matthias
> Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams
> for Binder and Jupyter and all the infrastructure that made this playground
> possible, and we thank gesis.org for hosting.
>
> For details, see https://github.com/gvanrossum/patma/tree/master/binder
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/47YR2LUTLWA4SGDHE66AXERVHW5EDK6I/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4IUCFYIUFBOL6S4KLJVDPVWUV43EERSY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Henk-Jaap Wagenaar]

On Wed, 8 Jul 2020 at 21:44, Guido van Rossum  wrote:

> It works for me. Did you click on the box where the logs are supposed to
> appear? It will only show the logs when you click there.
>
>
I did click on that before, but I suddenly had a thought (I should have had
long ago): it seems my combination of Ghostery and uBlock on Chrome does
not play nicely with mybinder (which is why the logs were empty). Not sure
why Safari had the same/a different issue: I do not normally use it or have
anything installed on it.

Apologies for the noise.

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

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

[Henk-Jaap Wagenaar]

On Mon, 13 Jul 2020 at 09:30, Federico Salerno  wrote:

> On 13/07/2020 00:20, Guido van Rossum wrote:
>
> 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.
>
> Would it be impossible for the parser to interpret Point(x, y, y) as "the
> second and third arguments of Point must have the same value in order to
> match. Bind that value to y"? Since the value has to be the same, it
> doesn't matter whether y binds to the first or the second (or the nth)
> instance of it.
>
No, that would not be impossible but fraught with problems. This is
discussed in the PEP:
https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names
___
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/RQYFJ2TY3FLYLD233AH7VSQDOJRE7UQS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

[Henk-Jaap Wagenaar]

On Mon, 17 Aug 2020 at 11:30, Mark Shannon  wrote:

>
> I would also bring you attention to my rigorous analysis of the possible
> application to PEP 622 the entirety of CPython.
> If I have made any mistakes there, I'd be happy to correct them.
>
>
You say "I've elided a lot of complex logic int cases, as it is not
relevant." in the plistlib._BinaryPlistWriter._write_object example, this
seems to be a prime example where guards could be used to simplify/unnest
the logic? Even if you disagree, I think it is highly relevant and worth
commenting on, one way or another!
___
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/CJSF5EZ5EN54ZAGBBRNG3PPR6H4DPKDR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

[Henk-Jaap Wagenaar]

Thanks for having a look! The example now looks like (looking at int case
only, same applies to UID):

case int():
if value < 0:
try:
self._fp.write(struct.pack('>Bq', 0x13, value))
except struct.error:
raise OverflowError(value) from None
elif value < 1 << 8:
self._fp.write(struct.pack('>BB', 0x10, value))
...
elif value < 1 << 64:
self._fp.write(b'\x14' + value.to_bytes(16, 'big',
signed=True))
else:
raise OverflowError(value)

I was more thinking it would read/look something like:

case int() if value < 0:
try:
self._fp.write(struct.pack('>Bq', 0x13, value))
except struct.error:
raise OverflowError(value) from None
case int() if value < 1 << 8:
self._fp.write(struct.pack('>BB', 0x10, value))
...
case int() if value < 1 << 64:
self._fp.write(b'\x14' + value.to_bytes(16, 'big',
signed=True))
case int():
raise OverflowError(value)

Which I think works as expected under the current PEP622?

On Mon, 17 Aug 2020 at 14:16, Mark Shannon  wrote:

>
>
> On 17/08/2020 1:13 pm, Henk-Jaap Wagenaar wrote:
> > On Mon, 17 Aug 2020 at 11:30, Mark Shannon  > <mailto:m...@hotpy.org>> wrote:
> >
> >
> > I would also bring you attention to my rigorous analysis of the
> > possible
> > application to PEP 622 the entirety of CPython.
> > If I have made any mistakes there, I'd be happy to correct them.
> >
> >
> > You say "I've elided a lot of complex logic int cases, as it is not
> > relevant." in the plistlib._BinaryPlistWriter._write_object example,
> > this seems to be a prime example where guards could be used to
> > simplify/unnest the logic? Even if you disagree, I think it is highly
> > relevant and worth commenting on, one way or another!
>
> Thanks for the feedback.
>
> I've expanded the code in the `int` and `UID` cases, and made it clearer
> why the remaining code has been elided.
>
>
> Cheers,
> Mark.
>
___
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/PUENMFG7AFEGN446JHNBLSRUVCV52HHZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

[Henk-Jaap Wagenaar]

>
> That would work, but would be slower for the reference implementation
> due to the repeated `isinstance(value, int)` checks.
>

If you wanted to avoid that you could use match/case inside the "case
int()" instead, i.e.:

case int():
match value:
  case _ if value < 8:
// do things
  case _ if value < 1 << 8:
 // do things
  ...
  case _:
 // raise some kind of error

but that might be madness.


> I think the repeated `int()` cases do not help readability.
> Which form do you think is more readable?
>

I think the form I suggested is more readable and also I think it is more
PEP622-like and that it is easier to reason about/test/debug/maintain, but
that's just my opinion! Not sure how important the speed difference is to
this example.
___
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/VAKQAJ2BTATMXG2JUKKEO4BTMJDUWGQS/
Code of Conduct: http://python.org/psf/codeofconduct/