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

[Steven D'Aprano]

On Mon, Oct 04, 2021 at 07:31:10PM +0100, Steve Dower wrote:
> To me, the "*name" looks most similar to how we write "*args" in a 
> function definition, so I'd go for that.

That's exactly why we *shouldn't* go for that option. That is going to 
confuse a lot of people that it is sequence unpacking.

See for example Jonathon Goble's experience here:

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


> We don't currently modify[1] keywords with punctuation, 

Star imports are a possible exception. But there we have no way of 
confusing the meaning.


> and that's what 
> "except*" looks like, and "except * E" looks like a binary operator 
> and/or grit on the screen.

When I saw the `except*` syntax first suggested, I was a little 
surprised because it did seem rather unusual for Python. But I grew up 
with FORTH where function names contain punctuation all the time, so I 
didn't think too much of it. I expected that the keyword literally would 
be `except*` and nothing but `except*`.

If I had realised that the star would be free to wander around and that 
the syntax actually was r"except[ \t]*\*[ \t]*", I would have said 
something much earlier :-(

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

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

[Terry Reedy]

On 10/4/2021 9:57 AM, Ammar Askar wrote:

Throwing in another +1 for `except group`.

It's explicit, doesn't introduce new punctuation and avoids confusion 
with unpacking.


I agree for same reasons.  And avoids more bikeshedding.

I checked and if 'except group' is added to keyword.kwlist *before* 
'except', the pair is recognized as a keyword phrase by IDLE's syntax 
highlighter without any change.  ('except\s*group' would take care of 
variable spacing)



--
Terry Jan Reedy

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

[Python-Dev] [RELEASE] Python 3.10.0 is available

[Pablo Galindo Salgado]

On behalf of the Python development community and the Python 3.10 release
team, I’m pleased to announce the availability of Python 3.10.0.
Python 3.10.0 is the newest major release of the Python programming
language, and it contains many new features and optimizations.

https://www.python.org/downloads/release/python-3100/

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

Among the new major new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and
prepare for the removal of the wstr member in PyUnicodeObject.
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
Specification Variables
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
distutils module.
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
Aliases
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL
1.1.1 or newer
* [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove
Py_UNICODE encoder APIs
* [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional
EncodingWarning

[bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to
be on this list
in previous pre-releases but it has been postponed to Python 3.11 due to
some compatibility concerns. You can read the Steering Council
communication about it [here](
https://mail.python.org/archives/list/python-dev@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/)
to learn more.

# More resources

* [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog
)
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release
Schedule
* Report bugs at [https://bugs.python.org](https://bugs.python.org).
* [Help fund Python and its community](/psf/donations/).

# And now for something completely different

For a Schwarzschild black hole (a black hole with no rotation or
electromagnetic charge), given a free fall particle starting at the event
horizon, the maximum propper time it will experience to fall into (which
happens when it falls without angular velocity) the singularity is `π*M`
(in [natural units](https://en.wikipedia.org/wiki/Natural_units)), where M
is the mass of the black hole. For Sagittarius A* (the black hole at the
center of the milky way) this time is approximately 1 minute.

Schwarzschild black holes are also unique because they have a space-like
singularity at their core, which means that the singularity doesn't happen
at a specific point in *space* but happens at a specific point in *time*
(the future). This means once you are inside the event horizon you cannot
point with your finger towards the direction the singularity is located
because the singularity happens in your future: no matter where you move,
you will "fall" into it.

# We hope you enjoy the new releases!

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

https://www.python.org/psf/

# More resources

Online Documentation https://docs.python.org/3.10/
PEP 619 https://www.python.org/dev/peps/pep-0619/, 3.10 Release Schedule
Report bugs at https://bugs.python.org https://bugs.python.org/.
Help fund Python and its community https://www.python.org/psf/donations/.

Your friendly release team,
Ned Deily @nad https://discuss.python.org/u/nad
Steve Dower @steve.dower https://discuss.python.org/u/steve.dower
Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
___
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/OQWNWZWDPASOUOAT6VPUXIXBH2THYREC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rob Cliffe via Python-Dev]

On 04/10/2021 00:57, Barry Warsaw wrote:

On Oct 3, 2021, at 10:42, Łukasz Langa  wrote:


Speaking just for myself, the `except *` syntax always bothered me, but I 
couldn’t come up with anything better and it wasn’t enough for me to vote 
against PEP 654.  `except group` is nicer though, and I would be in favor of 
that, or something like it.

Or perhaps `except for` ?


We could of course bike shed on the syntax forever.  The PSC did vote to accept 
the PEP but we left room for changes while during the 3.11 cycle.

-Barry



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

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

[Steve Dower]

On 10/4/2021 5:47 PM, Antoine Pitrou wrote:

On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman  wrote:

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum  wrote:


The question was about which style to *recommend* (a la PEP-8).
  


I think the very fact that it can't (or is difficult) be enforced,


How so?  If style checkers are already able to check whitespace around
operators, they should be to check whitespace in this instance as well.

Do you suggest that PEP 8 violations should be detected by the Python
parser itself?


No, but if it isn't decided by *us*, it'll be decided by whoever 
contributes it to Black first.


To me, the "*name" looks most similar to how we write "*args" in a 
function definition, so I'd go for that.


We don't currently modify[1] keywords with punctuation, and that's what 
"except*" looks like, and "except * E" looks like a binary operator 
and/or grit on the screen.


Cheers,
Steve

[1]: Meaning to "give it a different meaning in particular context", not 
_literally_ modify in any permanent sense.


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

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

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:48 PM Antoine Pitrou  wrote:

> On Mon, 4 Oct 2021 12:18:35 -0400
> Calvin Spealman  wrote:
> > On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum 
> wrote:
> >
> > > The question was about which style to *recommend* (a la PEP-8).
> > >
> >
> > I think the very fact that it can't (or is difficult) be enforced,
>
> How so?  If style checkers are already able to check whitespace around
> operators, they should be to check whitespace in this instance as well.
>
> Do you suggest that PEP 8 violations should be detected by the Python
> parser itself?
>

1) I was basing the "can't enforce" on Guido's " You can't do that with our
current lexer+parser."

2) Of course PEP 8 violations shouldn't be checked by the parser. That's
why they're PEP 8 and not syntax rules.
However, this doesn't look like style. This syntax is modifying either the
`except` keyword for the exception type
associated with it.
Which does it modify? That the asterisk can be on either side of the
whitespace feels very odd, in general but
especially for Python syntax. That's why I'd opt for a variation that is
either unambiguously attached to the left or right,
or which is not connected to either, like the very clear `except group E`
proposal.

___

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

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
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/MGGIWJ7YJVGCHYHLQTYQILFGDWL4UMR5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Glenn Linderman]

On 10/3/2021 10: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.


Seems like a good reason to promote   "except group E"  instead of 
"except * E", as others have suggested.___
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/RHUNTWTPDJS5M4KPGHCRV4H34BD26BFO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Mon, Oct 04, 2021 at 09:03:54AM -0700, Guido van Rossum wrote:
>  The question was about which style to *recommend* (a la PEP-8).

Quote:

"At the moment * is a separate token so both are allowed, but we could
change that (e.g., make except* a token)"

If that is mistaken, that's fine, no harm done, but those of us who 
thought that enforcing one or the other form was on the table didn't 
imagine it :-)


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

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

[Antoine Pitrou]

On Mon, 4 Oct 2021 12:18:35 -0400
Calvin Spealman  wrote:
> On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum  wrote:
> 
> > The question was about which style to *recommend* (a la PEP-8).
> >  
> 
> I think the very fact that it can't (or is difficult) be enforced,

How so?  If style checkers are already able to check whitespace around
operators, they should be to check whitespace in this instance as well.

Do you suggest that PEP 8 violations should be detected by the Python
parser itself?


___
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/ZLU5NYXVRCUM7AEEN55ITUQO43VDY6RE/
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

[Calvin Spealman]

On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum  wrote:

> The question was about which style to *recommend* (a la PEP-8).
>

I think the very fact that it can't (or is difficult) be enforced, and so
in the wild we'll likely see variations that could lead to confusion, is
enough reason to find an alternative syntax.


> On Mon, Oct 4, 2021 at 8:03 AM 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 
>>> 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.)
>>
>
>
> --
> --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/DASEBDJ6CK6U4YHRKPJ7CNQQHVWEWOLQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
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/ZUUNY3BOXC3JV7GXBDXY54AEHMV334IV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

 The question was about which style to *recommend* (a la PEP-8).

On Mon, Oct 4, 2021 at 8:03 AM 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  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.)
>


-- 
--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/DASEBDJ6CK6U4YHRKPJ7CNQQHVWEWOLQ/
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

[Jonathan Goble]

On Mon, Oct 4, 2021 at 1:24 AM 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.
>

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

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

[Mark Shannon]

Another +1 for `except group` from me.

On 04/10/2021 2:57 pm, Ammar Askar wrote:

Throwing in another +1 for `except group`.

It's explicit, doesn't introduce new punctuation and avoids confusion 
with unpacking.


Regards,
Ammar

On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou > wrote:


On Sun, 3 Oct 2021 19:42:29 +0200
Łukasz Langa mailto:luk...@langa.pl>> wrote:
 >
 > -1
 >
 > If I could read the vertical line as a pipe character, the
expression would read "except or E as e".
 > But I can't read it that way anyway. Instead, all I see is a
lowercase EXCEPTL.
 >
 > 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`.

+1.  This is much more helpful to the reader than the cryptic
asterisk.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org

To unsubscribe send an email to python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at

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


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

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

[Victor Stinner]

To stay consistent with PEP 8, exception groups should use 4 spaces.

Victor

On Sun, Oct 3, 2021 at 5:54 PM Irit Katriel via Python-Dev
 wrote:
>
>
> We wonder if people have a view on which of the following is clearer/better:
>
> 1. except *E as e:  //  except *(E1, E2) as e:
> 2. except* E as e:  //  except* (E1, E2) as e:
>
> (The difference is in the whitespace around the *).
>
> At the moment * is a separate token so both are allowed, but we could change 
> that (e.g., make except* a token), and in any case we need to settle on a 
> convention that we use in documentation, etc.
>
> It is also not too late to opt for a completely different syntax if a better 
> one is suggested.
>
>
> ___
> 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/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/A2REM55FHTETDZUPRVDWTVSXC273GHZW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Łukasz Langa]

> On 4 Oct 2021, at 15:00, Calvin Spealman  wrote:
> 
> It is difficult to understand why any special syntax is needed at all. 
> ExceptionGroup is still an exception class like any other, isn't it? Why 
> wouldn't the existing syntax suffice?

This is covered at length in the PEP. Those sections specifically address this:

https://www.python.org/dev/peps/pep-0654/#extend-except-to-handle-exception-groups
 

https://www.python.org/dev/peps/pep-0654/#programming-without-except 


- Ł



signature.asc
Description: Message signed with OpenPGP
___
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/FHEWFNSDNZRHADGD3I2VVW66Y7DSNEI7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ammar Askar]

Throwing in another +1 for `except group`.

It's explicit, doesn't introduce new punctuation and avoids confusion with
unpacking.

Regards,
Ammar

On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou  wrote:

> On Sun, 3 Oct 2021 19:42:29 +0200
> Łukasz Langa  wrote:
> >
> > -1
> >
> > If I could read the vertical line as a pipe character, the expression
> would read "except or E as e".
> > But I can't read it that way anyway. Instead, all I see is a lowercase
> EXCEPTL.
> >
> > 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`.
>
> +1.  This is much more helpful to the reader than the cryptic
> asterisk.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/INK6TSOGGODA4NZ3CI5MOXIAI4Z4CZ53/
> 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/4ZUBUDQ4CGXYJAIYKMJMJBGUGGTODECF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

On Sun, Oct 3, 2021 at 11:48 AM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

>
> We wonder if people have a view on which of the following is
> clearer/better:
>
> 1. except *E as e:  //  except *(E1, E2) as e:
> 2. except* E as e:  //  except* (E1, E2) as e:
>
> (The difference is in the whitespace around the *).
>
> At the moment * is a separate token so both are allowed, but we could
> change that (e.g., make except* a token), and in any case we need to settle
> on a convention that we use in documentation, etc.
>
> It is also not too late to opt for a completely different syntax if a
> better one is suggested.
>

It is difficult to understand why any special syntax is needed at all.
ExceptionGroup is still an exception class like any other, isn't it? Why
wouldn't the existing syntax suffice?


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


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
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/XF2OZLWDMSL3LIRVU3VG6YZP47YXUCZO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Damian Shaw]

I'm confused, if you can't do that then what is Irit asking? I thought that:

> At the moment * is a separate token so both are allowed, but we could
change that (e.g., make except* a token), and in any case we need to settle
on a convention that we use in documentation, etc.

Meant exactly that was the question being asked.

Damian (he/him)

On Mon, Oct 4, 2021 at 1:30 AM 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.
>
> --
> --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/F2JUI7SWTQE6RJ4YYKQHJ233BERZHYWR/
> 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/RC267HMZNQ5GPMQXIC5TQBSYQIXHBG34/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

[Paul Moore]

On Mon, 4 Oct 2021 at 08:21, Antoine Pitrou  wrote:
>
> On Sat, 2 Oct 2021 13:27:03 +0100
> Paul Moore  wrote:
> > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger  wrote:
> > >
> > > I raised an issue about this: https://github.com/pypa/pip/issues/10530
> >
> > I agree with the comment made on that issue - this isn't the right way
> > to handle the problem. We need to encourage projects to opt into the
> > new approach and remove the legacy path once it's no longer needed. We
> > should *not* maintain the "old style" approach indefinitely, hiding
> > the fact that it's no longer the correct approach by having some sort
> > of "auto convert" logic in the tools.
>
> Can you explain what the "old style" approach is here?  I would hope
> for the "old style" approach to be deprecated (with a *visible*
> warning message) for at least 2 years before it is removed.

I'm talking about projects adopting a `pyproject.toml` configuration
file that specifies the build backend to use (in this case
setuptools). The `pyproject.toml` style was standardised in PEP 517
about 4 years ago now, and projects have been gradually adopting it.
As you say, there's a long tail of projects who have no immediate need
to switch, but we're working on smoothing that transition as much as
we can.

Deprecation is a complex process, and not really a python-dev
question, but for the record, pip (and PEP 517) have a mechanism for
using the new-style hooks even for older projects that haven't adopted
it. That, plus a "build isolation" mechanism, allows pip to work even
if setuptools is not present. We're transitioning to making that the
default behaviour, but that process isn't yet complete. Although even
when it *is* complete, we may have options allowing use of the old
behaviour (`--no-build-isolation, --no-use-pep517) for some time after
that.

Regarding warning when the old `setup.py` mechanism is used instead of
the new PEP 517 hooks, that's a matter for setuptools to decide, and I
can't speak for them. It's also not relevant to when ensurepip drops
inclusion of setuptools, as the ensurepip requirement is only that
*pip* no longer needs setuptools, and as I said, we're hoping to make
that mostly transparent. We *might* also be able to add a warning in
pip, to catch the case where setuptools *doesn't* have the warning,
but honestly we will probably be mostly OK from our side of things
with just advising the user to install setuptools manually in the
(increasingly rare) cases where we can't work out to install it
automatically.

> It is nice that well-maintained packages with lots of contributors get
> frequent releases and keep up with the pace of changes in the packaging
> ecosystem, but please don't forget that there's a long tail of packages
> that are updated infrequently and but still work properly and perform
> an important function for some parts of the user base.

We (the packaging community) are *extremely* aware of this, yes. If
you're interested in helping out, then these sorts of discussions
happen on the packaging area in Discourse, and (for project-specific
items) on the pip and setuptools trackers. We'd love more help there -
packaging for Python is critically under-resourced! - so please feel
welcome to come along and join in the work :-)

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

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

[Antoine Pitrou]

On Sun, 3 Oct 2021 19:42:29 +0200
Łukasz Langa  wrote:
> 
> -1
> 
> If I could read the vertical line as a pipe character, the expression would 
> read "except or E as e".
> But I can't read it that way anyway. Instead, all I see is a lowercase 
> EXCEPTL.
> 
> 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`. 

+1.  This is much more helpful to the reader than the cryptic
asterisk.

Regards

Antoine.


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

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

[Antoine Pitrou]

On Sat, 2 Oct 2021 13:27:03 +0100
Paul Moore  wrote:
> On Sat, 2 Oct 2021 at 12:20, Thomas Grainger  wrote:
> >
> > I raised an issue about this: https://github.com/pypa/pip/issues/10530  
> 
> I agree with the comment made on that issue - this isn't the right way
> to handle the problem. We need to encourage projects to opt into the
> new approach and remove the legacy path once it's no longer needed. We
> should *not* maintain the "old style" approach indefinitely, hiding
> the fact that it's no longer the correct approach by having some sort
> of "auto convert" logic in the tools.

Can you explain what the "old style" approach is here?  I would hope
for the "old style" approach to be deprecated (with a *visible*
warning message) for at least 2 years before it is removed.

It is nice that well-maintained packages with lots of contributors get
frequent releases and keep up with the pace of changes in the packaging
ecosystem, but please don't forget that there's a long tail of packages
that are updated infrequently and but still work properly and perform
an important function for some parts of the user base.

Regards

Antoine.


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

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

[Paul Moore]

On Mon, 4 Oct 2021 at 07:16, 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.

Agreed. Having "except*" be a single token, distinguished from the
pair of tokens "except" "*" only by the presence of whitespace, would
be extremely confusing.

And yes, I am aware that 3.as_integer_ratio() and 3.
as_integer_ratio() are syntax errors, whereas 3 .as_integer_ratio()
and 3 . as_integer_ratio() are valid. IMO, that's *also* very
confusing, and serves as a warning to not do that again, and not as an
example of how it's OK and we can do more of that...

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

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

[Greg Ewing]

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.

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