, 2021 at 6:36 PM Ethan Furman wrote:
> On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
> > On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>
> >> In Math / CompSci there is a definition that almost exactly matches
> this: Exact Cover -
> >> https
On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy wrote:
>
> With 2.x gone and a backport flow, essentially all issues are for main,
> so leave version tags off the issue (and eliminate the need to update
> them!).
For enhancement requests I agree we probably don't need to keep updating
the version
The asynchat [1] and asyncore [2] libraries have been deprecated since 3.6
in favor of asyncio [3]. In addition, smtpd [4], which depends on asynchat
and asyncore, is deprecated in favor of aiosmtpd [5].
The documentation for each of these libraries mentions that it is
deprecated and refers to
If we drop the requirement for pickle round-tripping then I would add a
requirement that sentinel is unpicklable, to prevent accidents.
Irit
On Fri, May 14, 2021 at 8:38 PM Tal Einat wrote:
>
> I'll try to organize my thoughts a bit here. This is a bit long,
> welcome to skip to the final
Another alternative is instead of
File blah.py line 3:
return x/0
^^^
to have
File blah.py line 3 cols 12-14:
x/0
On Mon, May 10, 2021 at 11:12 AM Steven D'Aprano
wrote:
> On Mon, May 10, 2021 at 05:34:12AM -0400, Terry Reedy wrote:
> > On 5/10/2021 3:28 AM,
Hi Nathaniel,
Philosophy of Science 101: nobody knows what TheBestSolution is and nobody
ever will.
That said, when we decided to submit PEP 654, that was a point in time when
we came to believe that we found the right solution. We made significant
changes later following feedback we agreed
On Fri, May 7, 2021 at 10:52 PM Pablo Galindo Salgado
wrote:
>
> The cost of this is having the start column number and end column number
> information for every bytecode instruction
>
Is it really every instruction? Or only those that can raise exceptions?
Following a recent change, we now have in traceback.py:
_sentinel = object()
def print_exception(exc, /, value=_sentinel, tb=_sentinel, limit=None,
file=None, chain=True):
So now:
>>> import traceback
>>> help(traceback.print_exception)
Help on function print_exception in
On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou wrote:
>
> I agree that is a reasonable spelling.
>
>
I initially suggested , but now I'm not sure because it doesn't
indicate what happens when you don't provide it (as in, what is the default
value). So now I'm with or .
The arg is only
> On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>
>
> In Math / CompSci there is a definition that almost exactly matches this:
> Exact Cover - https://en.wikipedia.org/wiki/Exact_cover
>
> The difference is that, IIRC, solving the problem is finding and removing all
> subsets that are
Maybe ‘version-dependent’ api? It indicates why the api is unstable (as
opposed to something like test.support where the docs say ‘this is for us,
we’re not bothered about keeping it stable’).
In some contexts ‘unstable’ means buggy/unreliable.
> On 4 Jun 2021, at 00:20, Glenn Linderman
Re https://bugs.python.org/issue40608.
I think it will be an act of kindness to
deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10 and tell people to use
Py_TRASHCAN_BEGIN/END
instead.
TL;DR: There was a change in 3.8 that introduced the latter while leaving
the former for backwards compatibility, but
This is just what I needed, thanks!
I’m in the process of preparing a presentation for my team at Bank of America
about how the dev lifecycle of our system (Quartz risk platform) interplays
with the dev lifecycle of Python (and how we can do better). I will use this.
> On 2 May 2021, at
On Wed, Apr 21, 2021 at 11:22 PM Nathaniel Smith wrote:
>
>
> Saying that you have to make a new API every time you start using
> concurrency inside a function is extremely restrictive.
You don't need a new API when you start using concurrency inside a
function. You need a new API when you
Hi Paul,
IIUC, you are saying that exception group should not be a builtin type
because it is (1) complex (2) special-purposed. Instead, you propose that
we make exception handling pluggable.
(1) I agree, it is somewhat complex - it took us several iterations to get
from the idea of "a
One of the motivations for introducing ExceptionGroup as a builtin is so
that we won't have a different custom version in each library that needs
it. So if you are writing a library the needs to raise multiple exceptions,
and then you decide to call Trio, you don't need to translate Trio's
Hi Greg,
If all you want is to catch an exception group and process it, then except*
does look like overkill.
It gets more interesting if you want to handle only some of the exceptions
and reraise the rest (without adding the current frame to the traceback),
or when the exception handler
Hi Nathaniel,
Thank you for your feedback. See a few comment below.
On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
> OK, better late than never... here's a much-delayed review of the PEP.
> Thank you Irit and Guido for carrying this forward while I've been AWOL!
> It's fantastic to
Hi Paul,
On Sat, Mar 27, 2021 at 6:00 PM Paul Sokolovsky wrote:
>
> It definitely feels like a lot of effort went into devising and
> polishing ExceptionGroup's and except*, thanks. But I'm not sure if you
> gentlemen come up with the "ultimate" way to deal with multiple errors,
>
I've been
We believe that we have found a simple way to make it possible to subclass
exception groups, with fully functioning split() and subgroup().
See this section in the PEP:
https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups
It was also added to the reference implementation.
This
We would like to present for feedback a new version of PEP 654, which
incorporates the feedback we received in the discussions so far:
https://www.python.org/dev/peps/pep-0654/
The reference implementation has also been updated along with the PEP.
The changes we made since the first post are:
1.
On Wed, Mar 3, 2021 at 6:57 PM Paul Moore wrote:
> Sorry, I keep thinking I've finished and you keep making interesting
> points :-)
>
> On Wed, 3 Mar 2021 at 17:01, Irit Katriel
> wrote:
>
> > Raising an ExceptionGroup is an API change. If you call APIs that say
> they will raise
On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing
wrote:
> On 4/03/21 5:37 am, Paul Moore wrote:
> > frameworks and libraries typically have to interact with other users'
> > code, and there the contract has changed from "do what you like in
> > your code and I'll cope" to "do what you like in your
Hi Sven,
This is all about the popularity of "except Exception".
Look at the hierarchy of builtin exceptions:
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
Most exceptions are subclasses of Exception. There are a few which are not,
because they typically mean "this
On Thu, Feb 25, 2021 at 5:19 AM Guido van Rossum wrote:
> [Subthread: handling individual errors]
>
> > Rather than iterator, I think we should add a visitor that calls a
> function for each leaf exception,
>
> I agree that we shouldn't add an `__iter__` method. But what if we added a
> separate
On Thu, Feb 25, 2021 at 5:59 AM Guido van Rossum wrote:
>
> Here's a potentially alternative plan, which is also complex, but doesn't
> require asyncio or other use cases to define special classes. Let's define
> two exceptions, BaseExceptionGroup which wraps BaseException instances, and
>
On Sat, Feb 27, 2021 at 12:47 AM Jim J. Jewett wrote:
>
> > Is this not allowed?
>
> >try:
> >try:
> >obj.func()# function that raises ExceptionGroups
> >except AttributeError:
> >logger.info("obj doesn't have a func")
> >except *(AttributeError, SyntaxError):
> >
On Fri, Feb 26, 2021 at 11:43 PM Guido van Rossum wrote:
> On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla
> wrote:
>
>> Excuse me if I post here. Maybe is a stupid question: why, instead of
>> introducing except*, Python can't extend the functionality of except,
>> so it can do what except* would
On Sat, Feb 27, 2021 at 12:35 AM Greg Ewing
wrote:
> While I don't particularly mind if we get ExceptionGroup, giving
> it special magical semantics, and especially new syntax, seems like
> bringing a massively overpowered weapon to bear on something that
> will only be used rarely.
>
> Handling
On Sun, Feb 28, 2021 at 6:17 PM Guido van Rossum wrote:
> On Sun, Feb 28, 2021 at 2:40 AM Irit Katriel
> wrote:
>
>>
>> In earlier versions of the PEP ExceptionGroup was not immutable and split
>> actually removed matching exceptions from it.
>> It was also iterable so you could get a flat list
On Wed, Feb 24, 2021 at 4:39 AM Guido van Rossum wrote:
>
> OTOH we might reconsider deriving ExceptionGroup from BaseException --
> maybe it's better to inherit from Exception? I don't think the PEP
> currently has a clear reason why it must derive from BaseException. I
> believe it has to do
On Wed, Feb 24, 2021 at 4:55 AM Guido van Rossum wrote:
However there may be an omission in the PEP -- what if we want to do
> something special for each suberror? If we just iterate over `eg.errors` we
> would have to do something recursive for exceptions wrapped inside multiple
> nested
We don't call it out but we talked about this at the sprint. I think the
reason we didn't come up with this solution then is that at the time
ExceptionGroups in our plans were not immutable, so this would not have
been possible (you don't know at construction time what it is going to
contain).
On Thu, Feb 25, 2021 at 9:06 PM Guido van Rossum wrote:
>
> Hm, a different idea: maybe it's simple enough that we can just add an
> example showing how to do this? Then people can tailor that e.g. to use
> various traversal orders. (We could just link to the code in traceback.py,
> but it
On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote:
> Then we should get some more opinions on this. I think it's the best idea
> so far for kindness towards code using `except Exception:`.
>
I agree that it's the best idea so far.
If someone says 'except Exception' they better mean it
Hi Jim,
On Wed, Feb 24, 2021 at 2:16 PM Jim J. Jewett wrote:
> Petr: What about except *(TypeError, ExceptionGroup):?
>
> Irit: Good question. We should block that as well.
>
> But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility
> seems to explicitly recommend the very
Hi Sven,
On Mon, Mar 1, 2021 at 8:59 PM Sven R. Kunze wrote:
> Hey Irit,
>
> cool proposal.
>
Thank you.
> I just have two questions regarding "except Exception" or "except
> BaseException" as it is used e.g. by concurrent.futures.process (def
> _process_worker) from the stdlib.
>
> Almost
Hi Barry,
On Mon, Mar 1, 2021 at 6:12 PM Barry Scott wrote:
>
> Have you considered alternative syntax to the "except*"?
> I feel that expect* is too easy to confuse with plain except.
>
We briefly considered things like "except Group[ValueError, TypeError]".
Do you (or anyone else) have any
Hi Sven,
I like your formatting suggestion, thanks. I will do something like that.
I'm not sure I understand your question. ExceptionGroup is a subclass of
Exception (which is a subclass of BaseException). So ExceptionGroup is
caught by "except Exception" or "except BaseException".
ause you are using
a new API incorrectly. But you won't have bugs where you swallow an
exception that you didn't swallow before.
Irit
On Wed, Mar 3, 2021 at 8:30 AM Paul Moore wrote:
> On Tue, 2 Mar 2021 at 21:46, Irit Katriel via Python-Dev
> wrote:
> > As an aside - I found it
On Thu, Mar 4, 2021 at 1:38 AM Glenn Linderman
wrote:
> On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote:
>
> That's an interesting idea.
>
> Do you mean that one exception gets handled and the rest of the group is
> reraised? Or discarded?
>
> The value of s
Hi Paul,
On Wed, Mar 3, 2021 at 2:20 PM Paul Moore wrote:
>
> 1. Having now read the PEP, I don't actually see a use case for
> grouping BaseExceptions. Why would anyone catch KeyboardInterrupt or
> SystemExit and wrap them in a BaseExceptionGroup anyway? It seems to
> me that the right thing
On Wed, Mar 3, 2021 at 4:37 PM Paul Moore wrote:
>
> Similar to the argument for "except Exception". Applications that trap
> KeyboardInterrupt so that they can exit cleanly without an ugly
> traceback will no longer trap *all* keyboard interrupts, as they could
> miss grouped ones.
>
See
Hi Cameron,
If you go long, I go longer :)
On Sun, Feb 28, 2021 at 10:51 PM Cameron Simpson wrote:
> On 28Feb2021 10:40, Irit Katriel wrote:
> >split() and subgroup() take care to preserve the correct metadata on
> >all
> >the internal nodes, and if you just use them you only make safe
>
Hi all,
We would like to request feedback on PEP 654 -- Exception Groups and
except*.
https://www.python.org/dev/peps/pep-0654/
It proposes language extensions that allow programs to raise and handle
multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and other
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,
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
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
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
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:
Whether you have "as" or not, the value of sys.exc_info() (which is what
would be attached as the context to anything you raise in the except block)
is the same. So these are not two different cases -- the only difference is
whether or not you have a local variable set to sys.exc_info().
On Thu,
On Thu, Mar 4, 2021 at 8:48 PM Sven R. Kunze wrote:
> Hi Irit,
>
> makes sense. So, in case of a *mixed-type ExceptionGroup,* SystemExit
> wins and forces the program to exit.
>
>
> Could you add your reasoning to the PEP?
>
Good idea, I'll add "ExceptionGroup(BaseException)" as a rejected idea
On Thu, Mar 4, 2021 at 11:15 PM Glenn Linderman
wrote:
> I like explicit, and avoiding magic.
>
> And this gives a compatibility story for outer loops that except:
> Exception, and even for others cases that are not recoded for
> ExceptionGroup handling.
>
It could help during the
FTR: nobody on this long thread so far has suggested that there are no
valid use cases for `except Exception`.
Thank you for turning to what happens with 'except ValueError' when an
ExceptionGroup[ValueError] is raised, this is important.
I'm not sure it's safe to assume that it is necessarily a
On Fri, Feb 26, 2021 at 2:42 PM Nathaniel Smith wrote:
> On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel
> wrote:
> > I'm not sure it's safe to assume that it is necessarily a programming
> error, and that the interpreter can essentially break the program in this
> case.
> > Is this not allowed?
>
In earlier versions of the PEP ExceptionGroup was not immutable and split
actually removed matching exceptions from it.
It was also iterable so you could get a flat list of all the contained leaf
exceptions. Then we changed it.
ExceptionGroup is a tree of exceptions, and the internal nodes of the
On Mon, Apr 5, 2021 at 2:59 PM Chris Jerdonek
wrote:
> This point reminded me again of this issue in the tracker ("Problems with
> recursive automatic exception chaining" from 2013):
> https://bugs.python.org/issue18861
> I'm not sure if it's exactly the same, but you can see that a couple of
>
Thomas and the rest of the SC,
Thank you for updating us and for your kind words about the PEP.
We agree that it is safer to include this in 3.11 and not rush it into
3.10. As you say, having time to develop the integration with asyncio
before finalizing the API will give us more confidence in
On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
>
> The problem is that most of the time, even if you're using concurrency
> internally so multiple things *could* go wrong at once, only one thing
> actually *does* go wrong. So it's unfortunate if some existing code is
> prepared for a
Hi Sven,
I don’t follow. What would the value of __group__ be and how would it work?
Irit
> On 20 Apr 2021, at 20:44, srku...@mail.de wrote:
>
>
> Hi Irit,
>
> reading this subthread specifically, I just got a wild idea and I couldn‘t
> find any related information in the PEP:
>
> Why
I don’t see what this simplifies. We still need to implement split, and to
worry about wrapping or not wrapping BaseExceptions and we still need to define
exception handling semantics (except/except*).
> On 20 Apr 2021, at 22:12, srku...@mail.de wrote:
>
> So, forgive me my relatively simple
On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith wrote:
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward
On Tue, Aug 17, 2021 at 12:05 PM Duncan Grisby wrote:
> I don't know if it is pertinent to this at all, but I raised
> https://bugs.python.org/issue9 in which the faulthandler module can
> lead to a segfault inside Py_TRASHCAN_SAFE_BEGIN. Would that be avoided if
> frameobject.c was changed
This is the source of this whole misunderstanding:
On Sun, Aug 15, 2021 at 9:34 PM Marco Sulla
wrote:
>
> I asked for help, because I didn't know __nothing__ about what Monica
> replied to me in the SO answer. And you say to me my post seems spam?
>
> [snipped]
> And you continue to mark my
On Thu, Aug 19, 2021 at 11:28 AM Duncan Grisby
> Thanks. Victor Stinner has now commented on the defect I raised to say
> that it is actually a bug in the traceback module, in that it should not be
> using Py_DECREF at all inside a signal handler. The fact that it leads to
> use of the old
Thanks, I've updated the PR. https://github.com/python/cpython/pull/27693
I added migration instructions to the news file (which Pablo can copy into
what's new once it's committed).
Also added a Py_DEPRECATED(3.11) typedef which is used in the macro.
It remains the decide how to backport the
> On 11 Sep 2021, at 06:57, Ethan Furman wrote:
>
> If the previous output needs to be maintained, for example to ensure
> compatibily between different Python versions, software projects will need to
> create their own enum base class with the appropriate methods overridden.
Perhaps you
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
We can drop except. Say:
try:
..
handle T1:
…
handle T2:
…
Or ‘catch’, or something else.
> On 3 Oct 2021, at 19:12, MRAB wrote:
>
> On 2021-10-03 18:50, Brandt Bucher wrote:
>> Łukasz Langa wrote:
>>> My idea is this:
>>> try:
>>>...
>>> except group E as e:
>>>...
>>>
On Mon, Mar 28, 2022 at 4:44 PM Guido van Rossum wrote:
>
> "Future" imports are special to the parser, and they may also set a flag
> for the runtime to alter its behavior, but they are intentionally not
> treated specially by code generation, so they are still properly imported.
> However the
If you have a __future__ import in a script, and you import * from it in
another script, the object for this future appears in the dir() of the other
script, even though the __future__ import has no effect there.
% cat x.py
from __future__ import annotations
% cat y.py
from x import *
Miro,
I have offered before and my offer still stands to help fix this.
This was already fixed in the cython main branch by Stefan. The discussion
now is about when to backport it to cython 0.29.
I'm actually working on the backport now (learning cython in the process).
But we will need to come
Stefan,
There two separate issues here. One is the timing of committing changes into
cython, and the other is the process by which the cython devs learn about
cpython development.
On the first issue, you wrote:
I'm reluctant to working on adapting Cython during alphas, because it
> happened
_PyErr_StackItem is not part of the C API, it's an internal struct that
cython accesses directly.
On Tue, Feb 1, 2022 at 3:42 PM Christian Heimes
wrote:
> On 01/02/2022 16.08, Victor Stinner wrote:
> > --
> >
> > I would prefer to introduce C API incompatible changes differently:
> > first
A non-core approval changes the label from "awaiting review" to "awaiting
core review". I find this useful, and occasionally filter on "awaiting core
review" because it indicates that at least one other person found the PR
sound / interesting. I would not like this to change - I think high
Hi Matthieu,
The dis output for this function in 3.12 is the same as it is in 3.11.
The pseudo-instructions are emitted by the compiler's codegen stage, but
never make it to compiled bytecode. They are removed or replaced by real
opcodes before the code object is created.
The recent change to
Hi Matthieu,
Yes I am interested. Please ping me for PR reviews or any progress updates.
Thanks
Irit
> On 5 Jul 2022, at 20:27, Matthieu Dartiailh wrote:
>
> Hi Irit, hi Patrick,
>
> Thanks for your quick answers.
>
> First thanks Patrick, it seems I went back to the stable docs at one
77 matches
Mail list logo
