> On 8 Dec 2020, at 19:59, Gregory Szorc wrote:
>
> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
>
> Without the changes from https://github.com/python/cpython/pull/22855
> <https://github.com/python/cpython/pull/22855> backported,
<mailto:gregory.sz...@gmail.com>> wrote:
> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren <mailto:ronaldousso...@mac.com>> wrote:
>
>
>> On 8 Dec 2020, at 19:59, Gregory Szorc > <mailto:gregory.sz...@gmail.com>> wrote:
>>
>> Regarding the 3.
015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______
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/
Messa
ork. For 3.7 and earlier this will never work, those branches are closed for
development.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
>
> --
> Greg
> ___
> Python-Dev mailing list -- python-de
A recent technical note from Microsoft describes a new reference counting
algorithm, Perceus. It seemed worth posting here in case there are any thoughts
about whether it might be useful for Python. I couldn't find any existing
references to it in this list.
"""
We i
particular way.
In short: a test named `assertSequenceEqual` should, I would think,
work for any sequence and therefore (based on the available documentation)
should not depend on the class-specific implementation of __eq__.
Is that wrong?
Thank you, Alan Isaac
____
ac
On 12/22/2020 2:28 PM, Ivan Pozdeev via Python-Dev wrote:
You sure about that? For me, bool(np.array) raises an exception:
In [12]: np.__version__ Out[12]: '1.19.4'
In [11]: if [False, False]==np.array([False, False]): print("foo") <...> ValueError: The truth va
In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked
to from https://mail.python.org/archives/list/python-dev@python.org/message/AQRLRVY7EJT4LTOCV7CLOFK3FJJTVYYM/ )
I reckon that
*like the other code before
On 22.12.2020 22:59, Ivan Pozdeev via Python-Dev wrote:
In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked
to from https://mail.python.org/archives/list/python-dev@python.org/message
> On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev
> wrote:
>
> I was directed to post this request to the general Python development
> community so hopefully this is on topic.
>
> One of the weaknesses of the PyUnicode implementation is that the type is
>
On 26/12/2020 10:52, Ronald Oussoren via Python-Dev wrote:
On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev
wrote:
I was directed to post this request to the general Python development
community so hopefully this is on topic.
One of the weaknesses of the PyUnicode implementation is
> On 26 Dec 2020, at 18:43, Guido van Rossum wrote:
>
> On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
> mailto:python-dev@python.org>> wrote:
> It's worth comparing the situation with byte arrays. There is no problem
> of translating different
d compare both type and value.
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/mess
know about the OP, but for me that wouldn’t be good enough as I’d still
have to copy the string value because of the semantics of ObjC strings.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
_____
On 28/12/2020 02:07, Inada Naoki wrote:
On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev
wrote:
On 26 Dec 2020, at 18:43, Guido van Rossum wrote:
On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
wrote:
That wouldn’t be a solution for code using the PyUnicode_
m OK to un-deprecate PyUnicode_READY() and make it no-op
> macro since Python 3.12.
> But I don't know how many third-parties use it properly, because
> legacy Unicode objects are very rare already.
For me lazy population might not be enough (as I'm not sure precisely
what you mean by
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
___
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 ar
dress this kind
of issue?
___
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
This mailing list is for the development _of_ the Python language and its
CPython implementation.
Please consult other resources for help with using or learning Python.
On 01.01.2021 11:58, hadi esmaeely wrote:
hi my name is hadi
i'm from iran (the country which filtering others an
Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
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
Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.o
This was discussed a bit over on python-ideas recently, so a note from me,
and one from that thread:
Or for that matter, not the reason to provide
> object's internal storage via object's attribute: obj.__dict__.
>
Well, it IS an implementation detail that it's a dictionary
> On 8 Jan 2021, at 20:38, Chris Barker via Python-Dev
> wrote:
>
> Sorry if I'm out of the loop here, but with Apple's new chip coming out, we
> need new a build configuration (which I think has already been started, if
> not done).
>
> Perhaps we cou
My code pretty much does what you suggest at the end of your message:
On Mon, 2021-01-11 at 09:22 -0800, Larry Hastings wrote:
> Or code can just use inspect.get_type_hints(), which is tied to the
> Python version
> anyway and should always do the right thing.
So far, this has proven
tanza from
> the end too.
> Welcome to the world, baby 649!
>
> /arry
> ___
> 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-de
ons can continue to serve runtime type
validation.
PEP 563 does go on to state:
> For code which uses annotations for other purposes, a
> regulareval(ann, globals, locals) call is enough to resolve the
> annotation.
And I believe this would no longer be true under PEP 649;
furth
ld not just store
a callable in __annotations__, and use the descriptor to resolve it to
a dictionary and store it when it is accessed? It would be one less
dunder in the Python data model.
On Mon, 2021-01-11 at 15:46 -0800, Larry Hastings wrote:
>
> On 1/11/21 3:02 PM, Paul Bryan wrote:
&
xception, or just
> doesn't return an acceptable value--then the getter immediately
> exits, and the internal state of the object is unchanged. If you
> wanted to, you could catch the exception, fix the error, and get
> __annotations__ again, and it'd work.
OK.
> > s/__c
Will do.
On Mon, 2021-01-11 at 20:55 -0800, Guido van Rossum wrote:
> On Mon, Jan 11, 2021 at 3:51 PM Larry Hastings
> wrote:
> > [...]
> > > This passage in PEP 563 appears not true in Python 3.9 with
> > > __future__ annotations, emphasis mine:
> > >
;t be marshalled.
Since the __co_annotations__ function will get globals from the
function it annotates, doesn't it get more than just module scope?
Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
ignature_backslash` in cpython 3.10
to have the same behavior.
So the question is: Should we bump minimum version of Sphinx from 1.8 to
3.2.1 along with Python 3.10? For the moment this is where we go, but if
you're having to maintain a release of Python along with Sphinx < 3,
please make
On 13.01.2021 2:47, Senthil Kumaran wrote:
On Wed, Jan 13, 2021 at 12:28:42AM +0100, Victor Stinner wrote:
The alternative is to keep Sphinx 2 support, use
strip_signature_backslash and don't use :no-trim-doctest-flags: ?
+1. :no-trim-doctest-flags: was introduced to python docs
t; and "type(None)".
> > >
> > Huh, I wasn't aware of that.
> >
>
> This has tripped up many people. Maybe we should just bite the bullet
> and change this?
+1, FWIW.
_______
Python-Dev mailing list -- python
On 13.01.2021 3:12, Senthil Kumaran wrote:
On Wed, Jan 13, 2021 at 02:53:30AM +0300, Ivan Pozdeev via Python-Dev wrote:
I support keeping same Sphinx version across all the supported python versions.
This is not a sustainable route since this way, there's no way to change the
version a
ed to allow Sphinx 3 to
behave like Sphinx 2 in respect of backslash in signatures. It would
allow us to write Sphinx 2 and Sphinx 3 compatible doc.
> I noticed that you suggested not to backport this PR
> https://github.com/python/cpython/pull/24142
I'm against changing the major versio
elease is already hard, I don't think
we can bump dependencies on current releases like Python 3.8.
> I would prefer to not have to check manually if a doc backport PR is
> still compatible with Sphinx 2 or not.
As we're using `-W` flag of sphinx-build, the tests would spot it and
Hi Matthias,
Le 2021-01-13 à 12:27, Matthias Klose a écrit :
> That's not true. Ubuntu 20.04 LTS still sees updates to subminor Python 3.8
> versions, having sphinx 1.8.5.
I do agree to *not* bump our Sphinx dependencies for already published
Pythons.
Would it be OK to bump Sphinx
Ned,
Thanks -- I'll take further discussion to the python-mac list.
Ronald:
That’s a feature of the framework build. The unix build is exactly the same
> as a unix build on other platform. Adding the same feature to the unix
> build should be possible, but would complicate the bui
ien Palard](https://mdk.fr)
_______
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/l
still be "optimised" away?
Thanks
Rob Cliffe
_______
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
> On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev
> wrote:
>
> Ned,
>
> Thanks -- I'll take further discussion to the python-mac list.
>
> Ronald:
>
> That’s a feature of the framework build. The unix build is exactly the same
> as a unix bui
>
> >
> > > I'm probably naive, but is there a reason that one could not just
> > > store a callable in __annotations__, and use the descriptor to
> > > resolve it to a dictionary and store it when it is accessed? It
> > > would be one less dunder i
nnotations__. If you're not even aware that it exists, it's
> not mysterious ;-)
>
> Cheers,
>
> /arry
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.
ew
> annotations() function to hide the details. It wouldn't
> be the same as get_type_hints(), since it wouldn't make
> any assumptions about what the annotations mean.
>
_______
Python-Dev mailing list -- python-dev@python.org
To u
Thanks Ronald,
This is really helpful.
-CHB
On Fri, Jan 15, 2021 at 5:43 AM Ronald Oussoren
wrote:
>
>
> On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev <
> python-dev@python.org> wrote:
>
> Ned,
>
> Thanks -- I'll take further discussion to the pyth
bers
> - A node representing JSON arrays
> - A node representing JSON dictionaries
>
> The function transforms a tree of nodes, beginning at the root node, and
> proceeding recursively through each child node in turn. The result is a
> Python object, with the following transformation a
be a different implementation of this function. I’ve looked into this
in the past for macOS, and that platform
has an API to retrieve the size of the stack as well as a pointer to the start
of the stack (AFAIK stacks aren’t auto-growing
on macOS)
Ronald
—
Twitter / micro.blog: @ronal
dule_names attribute, list (technically a
frozenset) of all stdlib module names:
https://bugs.python.org/issue42955
There are multiple use cases:
* Group stdlib imports when reformatting a Python file,
* Exclude stdlib imports when computing dependencies.
* Exclude stdlib modules when listing extension
s no way to verify a
module's contents, either.
As such, there's no way to tell if any given module being imported is a
standard or a 3rd-party one.
On 25.01.2021 20:33, Chris Jerdonek wrote:
On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>>
Fortunately for, you :) , all this argument is not against the feature per se but only against its use to blindly filter module lists for
automated bug reports.
On 26.01.2021 1:34, Victor Stinner wrote:
On Mon, Jan 25, 2021 at 11:22 PM Ivan Pozdeev via Python-Dev
wrote:
That's not pos
On 29.01.2021 20:15, Victor Stinner wrote:
Hi Mark,
I tried to use C11 _Thread_local (Thread Local Storage, TLS) only with
GCC and clang and I got issues on macOS:
https://github.com/python/cpython/pull/23976
My PR uses __thread if _Thread_local is not available.
I don't think tha
_new which does a few context-specific checks before calling
PyBaseObject_Type.tp_new() directly to actually create the object. This
works fine.
However I want to allow class B to be used with a Python mixin. A's
tp_new() then has to do something similar to super().__new__(). I have
On 01/02/2021 23:50, Greg Ewing wrote:
On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote:
TypeError: object.__new__(B) is not safe, use B.__new__()
It's not safe because object.__new__ doesn't know about any
C-level initialisation that A or B need.
But A.__new__ is call
Phil
On Mon, Feb 1, 2021 at 3:27 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:
Hi,
I'm trying to understand the purpose of the check in tp_new_wrapper()
of
typeobject.c that results in the "is not safe" exception.
I have the following class hierarchy
new. If you do not do this, Python
subclasses of your type that also inherit from other Python-defined
classes may not work correctly. (Specifically, you may not be able to
create instances of such subclasses without getting a TypeError.)
-
ct type-wise.
Thanks for the explanation.
Phil
_______
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.p
AICT, no justification is given for this.
Why can't pattern matching use the object model?
PEP 343 (the "with" statement) added the __enter__ and __exit__ methods to the
object model, and that works very well.
2. PEP 634 deliberately introduces a large area of undefined behaviour i
_future__ due to its contentious
nature met immediate resistance. No point going down that road.
Kind regards,
Steve
On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:
With such a large new area of functionality that's at odds with existing
On 07.02.2021 0:24, Paul Sokolovsky wrote:
Hello,
On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev wrote:
Who said "__future__"?
Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not
Hi Python Dev team,
I submitted a PR https://github.com/python/cpython/pull/23736 two months ago.
The PR, which fixes an issue https://bugs.python.org/issue41928 in ZipFile, is
"awaiting core review".
Best regards.
Andrea Giudiceandrea
_______
program did not seem to imply it was the python program.
In a nutshell the proposal is to change from this:
python-3.10.0a5.exe
python-3.10.0a5-amd64.exe
to this (thanks to Matthew Barnett for the improved names:
python-3.10.0a5-win32-setup.exe
python-3.10.0a5-win64-setup.exe
Barry
How a standard by ANSI, ECMA and/or ISO is any better than a standard by the
PSF?
Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion
or smth?
On 12.02.2021 21:33, Dan Stromberg wrote:
What would it take to create an ANSI, ECMA and/or ISO standard for P
Terry Reedy wrote:
> I nosied and requested a review from the active zipfile 'expert' (Serhiy).
Thank you Terry.
Regards.
Andrea
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pyt
egards,
--
Regards,
Ivan
___
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/arch
nse them all at once and be done with it?
In fact, this whole thread feels like removing 80%-complete translations
from a program because they 'burden developers' and confuse users. Even
if the translations are not actively updated and degenerates with
strings changing, some users find the
ing emails multiple times per month about real bug which
must be fixed. My main annoyance is that every single buildbot failure
sends me an email, and I'm overwhelmed by emails (I'm not only getting
emails from buildbots ;-)).
Python has already a long list of buildbot workers (between 75
s issue at last!
Likewise, half of the bullet points in https://mail.python.org/archives/list/python-dev@python.org/message/LJ3E2UQBPDSFEH7ULNF3QVOYEQYRSAGI/
comes from either ppl trying to bypass the process, or the release manager doing others' jobs that should've already been done had t
.
A reference implementation (unreviewed) can be found at:
https://github.com/iritkatriel/cpython/pull/10
Thank you for your help
Kind regards
Irit, Yury & Guido
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to py
didn't do that already if handling specific exception types and reraising the rest is the standard
procedure!
Then the code would be reduced to:
try:
except (MultiError, ValueError) as e:
MultiError.filter({ValueError: lambda _: None},
e)
* https://github.c
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 l
ption from the PEP on how to handle this kind of pattern,
> especially for code that must support multiple versions of Python, would be
> extremely helpful.
>
> Damian
>
>>
>>
___
Python-Dev mailing list -- python-dev@python.org
To u
up('', (NotADirectoryError(20, 'The directory
name is invalid'),))
There is no need for it to always raise ExceptionGroup. It can propagate
the user's exception as is if it has no exceptions to add. But the caller
needs to assume that it may raise an ExceptionGroup, and use
ubgroup(lambda e: not predicate(e))
> assert g1 == h1 and g2 == h2 # only true if `None not in {g1, g2}`
> ```
>
An empty subgroup should also return None. I see this is not mentioned in
the PEP, so I will add it. Thanks.
Irit
___
Python-Dev m
rrently have:
>
> try:
> create_connection(*addresses)
> except (Timeout, NetworkNotConnected):
> # that's OK, let's try later
> pass
>
> what should happen after Python 3.10? Apart from adding a new function,
> I can see two pos
ly to be overused than actually needed.
We did that in an earlier version of the PEP for the "filter OSErrors by
type" example, which we did with iteration and now do with subgroup:
try:
low_level_os_operation()
except *OSerror as errors:
raise errors.subgroup(lambda e: e.errno != er
Those are quite different directions.
_______
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/archive
split() currently copies (context, cause, traceback) from the original
ExceptionGroup to the new ones. We could have some protocol, but I'm not
sure what it would look like. I'm pretty sure there will be a cost, and I'm
not sure I understand why no subclassing is a serious enough l
distinction between code that raises
ExceptionGroups and code that doesn't. Any code can propagate them, like
any code can raise any other exception.
Does this mean that more code needs to be aware of the possibility of them
showing up? Is that a problem? Maybe this a simpler state of affairs
o
teration utility we are
implying that this is what you should do.
So let me be more direct instead of proposing passive-aggressive APIs.
Can we take a step back and talk about how we think people would want to
handle ExceptionGroups?
In the rejected ideas section we discuss this a bit, with a re
dditional data that's only available in that stack frame.
>
> So I think there are enough serious use cases that we should do what's
> best for those use cases, and not try to lecture users about abuse of the
> idiom.
>
> I don't know what we would have done if we we
back.py,
> but it probably is full of distractions.)
>
I've added it here: https://github.com/python/peps/pull/1841
I'd rather do this for now, and add it to the standard library only when we
have a better idea about common patterns // best pract
ing faster than the implementation.
But these aren't differences that are more than a technicality to fix
(rename things, move an error from runtime to the parser, things like that).
The except* implementation is probably pretty close to the PEP because it's
the most recent bit.
___
ds to be fixed.
>
> If you write 'except ExceptionGroup': this clause is a no-op that will
> never execute, because it's impossible to still have an ExceptionGroup
> when we start matching 'except' clauses. (We could additionally emit a
> diagnostic if we wa
'hello')
and this raises a RuntimeError:
try:
raise ExceptionGroup("", [ValueError()])
except ValueError:
print('hello')
What am I missing?
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
think it says anything about whether except* clauses should be able
> to see into nested ExceptionGroups ... nor am I at all confident that I
> understood your intent.
>
> -jJ
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send
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,
>>
me experience with this from the Trio experiments with
MultiError though, so we are not starting from scratch.
Can you spell out how you see ExceptionGroup handling work with pattern
matching?
___
Python-Dev mailing list -- python-dev@python.org
To unsubsc
if ... some other ok situation ...
>> else:
>> raise
>>
>> My natural inclination with an ExceptionGroup would be to winnow the
>> OSErrors I'm handed, and push the _unhandled_ errors back into the
>> original ExceptionGroup. That
ta (unless eg's tree has
>> depth 1).
>>
>
> Is this a typo? Did you mean "If you flatten [it] and create a new list...
> you *do* lose metadata (unless ... depth 1)"?
>
It is a typo, thanks.
___
Python-Dev mailin
al__ # or __parent__ or something
> unhandled.extend(eg)
> if unhandled:
> raise eg0.with_exceptions(unhandled)
>
> Except that here I have no way to get "eg0", the original
> ExceptionGroup, for the final raise without the additional .__origi
ocess_worker) from the stdlib.
>
> Almost similarly, I maintain a library using this pattern to wrap/unwrap
> exceptions from remote Python processes to create nicely formatted
> tracebacks (also recursively of course if needed) at the calling python
> process.
>
> Usually t
sed?
>
I can't imagine people building deep trees of exceptions in practice (at
least not on purpose). But some nesting may show up naturally, and we need
to support it because otherwise it can get awkward if, for example,
asyncio.gather() needs to wrap an exception group that came fro
On Tue, Mar 2, 2021 at 7:25 PM Sven R. Kunze wrote:
> Just to be on the safe side here, I would want to asked a little bit
> further.
>
>
> On 02.03.21 12:22, Irit Katriel wrote:
>
>
> 1) What is the right "except pattern" when ExceptionGroup is introduced
>>
u want to catch, because 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:
PIs
that discard errors because they need to pick one. That's what we're trying
to fix.
Irit
___
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
the program. Exiting")
> sys.exit(1)
>
It suffices to do
try:
main()
except *KeyboardInterrupt:
print("User interrupted the program. Exiting")
sys.exit(1)
because "except *T" catches Ts as well.
>
> Did I miss an easier way of writing this code
to do
> ># reraise the rest
>
> I'd be inclined to suggest that a complete version of this should be
> included in the "Backward compatibility" part of the PEP, as I
> honestly don't really know how I'd write that without doing more
> research
>
> Best
> Sven
>
>
> PS:
>
> the reason why I was a bit puzzled by the
> BaseExceptionGroup/ExceptionGroup issue is that:
> - if it doesn't matter (so we do it automatically, because we do not
> want to bother anybody), why do we need ExceptionGroup at all,
>
se a bunch of them and the order of the
except clauses in caller's code determines which one of them counts and
which ones are discarded. What do you make of that?
Irit
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
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
1201 - 1300 of 1712 matches
Mail list logo
