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

[Nathaniel Smith]

On Fri, Apr 23, 2021 at 4:08 AM Irit Katriel  wrote:
>
> On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith  wrote:
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land.
>
> I'm very glad to hear that. It's been hard to know where you stand, because 
> you didn't even decline our invitation in October to work together on this, 
> and several later invitations to look at the implementation and try it with 
> Trio -- you just didn't reply.   The only responses I saw were public, on 
> this list, taking us right back to the drawing board (for example - the 
> suggestion you mention in the previous paragraph as 
> not-sufficiently-explored, actually appears in the rejected ideas section of 
> the PEP, and the reason for rejection is not that it's incompatible with 
> nesting). So thank you for clarifying that you are, ultimately, supportive of 
> our efforts.

Yes, I apologize again for the radio silence there -- I had real world
stuff that left me with no cope for open-source. I, uh, was feeling
guilty about not getting back to you the whole time, if that helps?
Probably that doesn't help.

My memory is that in our initial discussions, I suggested having each
'except Blah as exc' clause be executed once, receiving an
ExceptionGroup containing all the Blah exceptions. Guido pointed out
that this broke typing -- 'exc' would not longer have type 'Blah' --
and I was like... okay yeah that's a fatal flaw, never mind. And I
never seriously raised the 'execute a single clause multiple times'
option, because of the issue where in the nested design, taking
individual exceptions out of an ExceptionGroup breaks tracebacks.

Looking at the relevant section of the PEP again [1], it notes the
same fatal flaw with my first suggestion, and then says that the
multiple-except-executions option should be rejected because users
have written code like 'except SomeError: ...' with the expectation
that the 'except' clause would run exactly once. That's definitely
true, and it's a downside of the multiple-except-executions approach,
but I don't think it's convincing enough to rule this out on its own.
The problem is, *all* our options for how 'except' should interact
with ExceptionGroups will somehow break previous expectations.

Concretely: imagine you have a pre-existing 'except SomeError', and
some new code inside the 'try' block raises some number of
'SomeError's wrapped in an ExceptionGroup. There are three options:

- Execute the 'except' block multiple times. This breaks the
expectation that it should be executed at most once.
- Execute the 'except' block exactly once. But if there are multiple
SomeError's, this require they be grouped and delivered as a single
exception, which breaks typing.
- Execute the 'except' block zero times. This is what the current PEP
chooses, and breaks the expectation that 'except SomeError' should
catch 'SomeError'.

So we have to pick our poison.

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

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

Oh, that didn't bother me at all, but thanks :-). And I'm sorry if I
was denying you credit for things that you had actually independently
re-invented.

> I'm confused about the flattening suggestion - above you talk about "flat 
> EG", but below about tracebacks. It's not clear to me whether you want EG to 
> be flat (ie no nesting of EGs) or just the traceback to be flat (but you can 
> still have a nested EG).

Hmm, I was thinking about making both of them flat, so no nested EGs.
In all my designs, the only reason I ever had nesting was because I
couldn't figure out any other way to make the tracebacks work. Do you
have some other motivation for wanting nesting? If so that would be
interesting, because it might point to why we're talking past each
other and help us understand the problem better...

> I also don't know what problem you are trying to solve with this.

I'm not saying that there's some fatal problem with the current PEP.
(In my first message I explicitly said that it would be an improvement
over the status quo :-).) But I think that nesting will be really
counterintuitive/confusing for users in some ways. And concurrency
APIs will be offputting if they force you to use a different special
form of 'except' all the time. Basically the 'flat' version might be a
lot more ergonomic, and that's important for a language like Python.

-n

--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D6G7Z4QVC5H6UMHOFR33FMVCRV4HL6SM/
Code of Conduct: 

[Python-Dev] Re: expanduser('~other') reliability and future

[Terry Reedy]

On 4/28/2021 1:05 PM, Guido van Rossum wrote:
On UNIX-oid platforms (e.g. BSD, Linux, Mac), ~user/ should be 
reasonably reliable, after all the shell does it. On Windows, only ~/ 
can be relied upon -- the rest is "best effort". I'd be okay with 
deprecating ~user/ on Windows, but on UNIX-oid it should not be 
deprecated IMO.
On all systems, IDLE uses expanduser('~') and expanduser(path).  On Mac, 
it uses
expanduser('~/Library/Preferences/.GlobalPreferences.plist').  So I 
presume deprecating ~something only on Windows should not affect IDLE.


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

[Python-Dev] Re: expanduser('~other') reliability and future

[Antoine Pitrou]

On Wed, 28 Apr 2021 10:05:32 -0700
Guido van Rossum  wrote:
> On UNIX-oid platforms (e.g. BSD, Linux, Mac), ~user/ should be reasonably
> reliable, after all the shell does it. On Windows, only ~/ can be relied
> upon -- the rest is "best effort". I'd be okay with deprecating ~user/ on
> Windows, but on UNIX-oid it should not be deprecated IMO.
> 
> (Spoken as an old UNIX nerd who's currently using Windows 10.)

Agreed with Guido.

Best regards

Antoine.


> 
> On Wed, Apr 28, 2021 at 9:57 AM Senthil Kumaran  wrote:
> 
> > On Wed, Apr 28, 2021 at 05:44:06PM +0100, Barney Gale wrote:  
> > > From a bit of googling, Python seems to be an outlier in having a  
> > function to  
> > > retrieve another user’s home directory.  
> >  
> > > Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If  
> > not,  
> > > should we deprecate this functionality? Or something else?  
> >
> > +1 to deprecate this functionality. This does not seem to be common
> > usecase to
> > be present in stdlib, and reliablity across platform seems difficult.
> >
> > --
> > Senthil
> >
> > ___
> > 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/CGVRT4A7XUOEVWHZY3ZX32CABD7OKR2A/
> > 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/CVPSAHX2XJDX27I2PSASOTQF4MD6PX22/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: expanduser('~other') reliability and future

[Guido van Rossum]

On UNIX-oid platforms (e.g. BSD, Linux, Mac), ~user/ should be reasonably
reliable, after all the shell does it. On Windows, only ~/ can be relied
upon -- the rest is "best effort". I'd be okay with deprecating ~user/ on
Windows, but on UNIX-oid it should not be deprecated IMO.

(Spoken as an old UNIX nerd who's currently using Windows 10.)

On Wed, Apr 28, 2021 at 9:57 AM Senthil Kumaran  wrote:

> On Wed, Apr 28, 2021 at 05:44:06PM +0100, Barney Gale wrote:
> > From a bit of googling, Python seems to be an outlier in having a
> function to
> > retrieve another user’s home directory.
>
> > Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If
> not,
> > should we deprecate this functionality? Or something else?
>
> +1 to deprecate this functionality. This does not seem to be common
> usecase to
> be present in stdlib, and reliablity across platform seems difficult.
>
> --
> Senthil
>
> ___
> 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/CGVRT4A7XUOEVWHZY3ZX32CABD7OKR2A/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-Dev] Re: expanduser('~other') reliability and future

[Senthil Kumaran]

On Wed, Apr 28, 2021 at 05:44:06PM +0100, Barney Gale wrote:
> From a bit of googling, Python seems to be an outlier in having a function to
> retrieve another user’s home directory.

> Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If not,
> should we deprecate this functionality? Or something else?

+1 to deprecate this functionality. This does not seem to be common usecase to
be present in stdlib, and reliablity across platform seems difficult.

--
Senthil

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

[Python-Dev] expanduser('~other') reliability and future

[Barney Gale]

There’s been a bit of discussion on the reliability of getting other users'
home directories via os.path.expanduser(), mostly on issue42998
.

In msg390503 , Serhiy
Storchaka pointed out that ntpath only makes an educated guess of other
user’s home directories.

In msg390535 , Eryk Sun
supplied an improved ntpath implementation that makes use of winreg and
ctypes.

In msg391970 , Steve Dower
pointed out that, if retrieving another user’s home directory on Windows is
unlikely to be made reliable, we should look at deprecating this
functionality in expanduser()

>From a bit of googling, Python seems to be an outlier in having a function
to retrieve another user’s home directory. I am encouraged by Eryk’s patch,
but a little out of my depth with Windows stuff.

Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If
not, should we deprecate this functionality? Or something else?

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