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

On Tue, 2021-02-23 at 19:45 -0500, Random832 wrote: > I was reading a discussion thread > about > various issues with the Debian packaged version of Python, and the following > statement stood out for me as shocking: > > Christian

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

FWIW, Distro repacks are advantageous in comparison to "statically-bundled" releases that for example bundle in an outdated version of OpenSSL, because when you `apt-get upgrade -y` that should upgrade the OpenSSL that all the other distro packages depend upon. Here's something that doesn't get ca

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

On 2/23/21, Random832 wrote: > I was reading a discussion thread > about > various issues with the Debian packaged version of Python, and the following > statement stood out for me as shocking: > > Christian Heimes wrote: >> Core dev

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

On Tue, Feb 23, 2021 at 8:00 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > >- In >https://www.python.org/dev/peps/pep-0654/#programming-without-except, >the natural way isn't shown: > > try: > > except (MultiError, ValueError) as e: > def _handle(e): >

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

On 2/23/21 7:56 PM, Guido van Rossum wrote: On Tue, Feb 23, 2021 at 7:37 PM Ethan Furman wrote: It sounds like the long-term goal is to move away from `except` and replace it with `except *` -- is that correct? I don't think so -- if we expected that to happen the extra '*' in the syntax wou

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

On Tue, Feb 23, 2021 at 2:27 PM Damian Shaw wrote: > A common example I see from the GitHub search is a catch all exception on > some third party API. If the user wants to catch all exceptions from > calling a third party API why would they want to let an ExceptionGroup go > unhandled in the futu

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

On Tue, Feb 23, 2021 at 7:37 PM Ethan Furman wrote: > On 2/22/21 4:24 PM, Irit Katriel via Python-Dev wrote: > > > We would like to request feedback on PEP 654 -- Exception Groups and > > except*. > > > > https://www.python.org/dev/peps/pep-0654/ > > > > It proposes language extensions that

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

On 2/22/21 4:24 PM, Irit Katriel via Python-Dev wrote: > We would like to request feedback on PEP 654 -- Exception Groups and > except*. > > https://www.python.org/dev/peps/pep-0654/ > > It proposes language extensions that allow programs to raise and > handle multiple unrelatedexceptions simulta

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

On Tue, Feb 23, 2021 at 4:51 PM Random832 wrote: > Why is it that this community is resigned to recommending a workaround > when distributions decide the site-packages directory belongs to their > package manager rather than pip, instead of bringing the same amount of > fiery condemnation of that

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

On Tue, Feb 23, 2021 at 7:48 PM Random832 wrote: > > I was reading a discussion thread > about > various issues with the Debian packaged version of Python, and the following > statement stood out for me as shocking: > > Christian

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

I think it's a classic case of dependency hell. OS packagers are rebundling Python packages as OS packages and expressing their own OS-package dependency graphs. Then, you sudo pip install something that has a conflicting dependency, it bypasses OS packaging, and *boom*. I find tools like pipx go

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

I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in

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

Hi Petr, Thank you for your careful reading and encouragement. > The `ExceptionGroup` class is final, i.e., it cannot be subclassed. > > What's the rationale for this? > ExceptionGroup.subgroup()/split() need to create new instances, and subclassing would make that complicated if we want the sp

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

Hi Caleb, On Tue, Feb 23, 2021 at 11:05 PM Caleb Donovick wrote: > What is the motivation for returning `None` on empty splits? I feel like > this creates an unnecessary asymmetry. I don't personally have a use > case for the this feature so I may be missing something but it seems like > it wo

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

In addition to the changes proposed here that go beyond PEP-634 (which other people discuss), I find that many of the definitions fail to capture some of the basic features of PEP-634, especially when nesting patterns. Take for example: "case [int(), str()]". According to https://www.python.org/de

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

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

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

What is the motivation for returning `None` on empty splits? I feel like this creates an unnecessary asymmetry. I don't personally have a use case for the this feature so I may be missing something but it seems like it would force an annoying pattern: ``` try: foo() except ExceptionGroup as

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

Hi Steve, Thank you for trying out the implementation. Please do let me know about bugs you find. This part of your code looks good: --- a/Lib/tempfile.py > +++ b/Lib/tempfile.py > @@ -819,8 +819,14 @@ def __repr__(self): > def __enter__(self): > return self.name > > -def __exi

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

Hi Irit, A common example I see from the GitHub search is a catch all exception on some third party API. If the user wants to catch all exceptions from calling a third party API why would they want to let an ExceptionGroup go unhandled in the future? Once ExceptionGroups are introduced then librar

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

On 2/23/21 1:24 AM, Irit Katriel via Python-Dev wrote: Hi all, We would like to request feedback on PEP 654 -- Exception Groups and except*. https://www.python.org/dev/peps/pep-0654/ Thank you for this PEP! Also, thank you Nathaniel (and possi

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

This pep sounded kinda scary to me, so I wanted to try it out. The reference implementation appears to have some bugs in it (around reraise star) , so it's not entirely clear what the expected behavior is supposed to be, but by checking out ffc493b5 I got some OK results. I had a look at the temp

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

Hi Damian, While I agree that there are a handful of use cases for catching all Exceptions, if you look at some of the 5 million hits you found in github, the vast majority are not such cases. They are mostly try/except blocks that wrap a particular operation (a dict access, a raw_input call, etc)

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

On Tue, Feb 23, 2021 at 3:49 PM Damian Shaw wrote: > > Firstly, if I have a library which supports multiple versions of Python > and I need to catch all standard exceptions, what is considered the best > practise after this PEP is introduced? > > Currently I might have code like this right now: >

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

Hi Irit, Catching exceptions like this is an extremely common pattern in the real world, e.g. this pattern has over 5 million GitHub matches: https://github.com/search?l=&q=%22except+Exception%22+language%3APython&type=code How common it is aside there are also many valid use cases for this patte

[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python

On 2/22/21, 4:06 PM, "Antoine Pitrou" wrote: On Mon, 22 Feb 2021 19:50:43 + Rob Boehne wrote: > > The other thing that crept into this thread was the mention of test that intermittently fail. > That's a huge problem because it suggests that applications will sometim

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

* In https://www.python.org/dev/peps/pep-0654/#programming-without-except, the natural way isn't shown: try:     except (MultiError, ValueError) as e:     def _handle(e):     if isinstance(e, ValueError):        return None     else:     return exc     MultiError.filter(_h

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

Apologies I'm not a core dev so this might be the wrong place to ask but I have 2 small clarifying questions about the PEP. Firstly, if I have a library which supports multiple versions of Python and I need to catch all standard exceptions, what is considered the best practise after this PEP is in