[Python-Dev] Requesting Review of Pull Request

[Nathan Beals]

Good Afternoon Python Devs,

I'm requesting that someone review the pull request linked to this issue: 
https://bugs.python.org/issue42994 (github PR: 
https://github.com/python/cpython/pull/24287).

I'm following the contributing guidelines instructions to email this address if 
the PR hasn't been addressed in a month (+1 week after pinging it again). 
Thankfully this PR is tiny, at 9 lines total (and even then, it's just 9 new 
entries to a dictionary).

Thank you for your time,
Nathan Beals

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

[Python-Dev] Re: Which thing is "Development Mode"

[Coyot Linden (Glenn Glazer)]

  
  
On 3/1/21 08:49, Paul Moore wrote:


  
On Mon, 1 Mar 2021 at 16:25, Coyot Linden (Glenn Glazer)
 wrote:


  This is one of those cases, where those of us who have been around
Python for awhile can perhaps infer from context which his meant, but
the phrase "put your Python project into development mode" is ambiguous
in a way that is different from your example.


The commonly used packaging terminology is actually "editable mode"
(at least in the sense that that's what most people seem to call it,
so knowing and using that term will get better results from Google
;-)). If you feel inclined to raise a PR against the pip documentation
to prefer that term, it can be discussed over there (but note that the
underlying setuptools command is `setup.py develop` and that's not
likely to change, as it's hard-coded in a number of applications,
including pip).

But ultimately, I think the reality is that there *are* terminology
confusions all over the place in computing, much like in any other
discipline (I'm currently teaching someone music, and the number of
terms that get re-used in different contexts there is even worse than
computing!) So I think that ultimately, beginners simply need to get
used to understanding that terms can be context-dependent. It's not
easy, and as teachers we can do what we can to make things clearer,
but we can't ever completely make such problems go away.

Paul

  


I think we have fundamentally different worldviews, Paul. Just
because something is bad or even often bad, is no reason to let it
stay that way or to not try and make things better. Engineering
almost never makes any problem completely go away, the perfect can't
be the enemy of the good.

Personally, since it is newer and not stuck with the problems you
mention, I would prefer to change the name of the new Python runtime
option than mess with the setuptools mess.

Best,

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Thor Whalen]

Thanks Brett. I'll stay put (and hopeful) then. Thanks for all the great
work you're doing out there. Despite the (loud) dissenters, a lot of us
(silently) appreciate it.

On Thu, Feb 25, 2021 at 10:57 AM Brett Cannon  wrote:

>
>
> On Thu, Feb 25, 2021 at 8:46 AM Thor Whalen  wrote:
>
>> Finally! One of my top python wishes!
>>
>> Where can I vote?
>>
>
> There is no explicit voting, but thanks for sharing your opinion!
>
>
>>
>> How can I get my hands on a back port?
>>
>
> Probably can't since it will be new to 3.10 if the PEP gets accepted.
>
>
>>
>> How can I help getting this sooner?
>>
>
> As of right now there's nothing to do as the steering council has not even
> begun reviewing the PEP yet. If the PEP gets accepted then you can
> volunteer to help with the implementation and/or the review of the code.
>
> -Brett
>
>
>> ___
>> 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/2QPAZ26E77MV2AZLDF3Z6DNHWZHQUPH5/
>> 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/DCLYEBBRS7QMKML7LPP7DWVQKJ6GH4P6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sven R. Kunze]

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 for the use cases described above (remote or concurrent
python processes)?

If you want to catch the whole ExceptionGroup and format its 
traceback, then you can just do "except ExceptionGroup as eg" and then 
traceback.print_exception(eg).


The except* syntax is for when you want to handle only certain types 
of exceptions from the group, selectively.


Just to make sure, I understand this completely.


In order to make it more tangible here is an example from the stdlib:

https://github.com/python/cpython/blob/bf2e7e55d7306b1e2fce7dce767e8df5ff42cf1c/Lib/concurrent/futures/process.py#L215

As you can see, BaseException is caught multiple times as the only 
except-clause. _sendback_result(...) then used to transfer the 
return_val/exception back to parent process.



How is the supposed way of handling a raised ExceptionGroup?


a) will the existing code simply work as it?
b) if not what are the changes to this lib specifically as a blueprint 
example for others



Reading from the other subthread for this PEP, I am not 100% sure now 
that "except BaseException" will suffice if ExceptionGroup inherits from 
Exception instead of BaseException because it seems that ExceptionGroup 
somehow is handled specially. So, why I try to approach this very issue 
with existing code. Once that is clear, it should be easy for everybody 
to apply the same pattern to their code. Here is the copy from github:



try:
    r = call_item.fn(*call_item.args, **call_item.kwargs)
except BaseException as e:
    exc = _ExceptionWithTraceback(e, e.__traceback__)
    _sendback_result(result_queue, call_item.work_id, exception=exc)
else:
    _sendback_result(result_queue, call_item.work_id, result=r)
    del r


Maybe even _sendback_result could benefit from using ExceptionGroup 
itself. You can see there another "except BaseException" in case of an 
error. But that's maybe a different topic.



2) What is the recommended approach of printing the traceback
potentially incorporating multiple tracebacks - I couldn't find it
in the PEP and tracebacks are a really neat tool for error hunting.


Part of the proposal of the PEP is that we teach the builtin traceback 
formatting code to display ExceptionGroups with all that information.



As long as there's the possibility to receive the usual (two-line) 
entry-based list, I guess that is enough for every one to work with it 
(e.g. hiding unnecessary tb entries).



The reference implementation has this, and the examples in the PEP 
were produced with it. Some of the examples (the early ones) show 
exceptions that were never raised so there is no traceback. But if you 
scroll down to the later examples, you see the output for exceptions 
with tracebacks, cause, context etc.



Ah I see them now. Thank you. :-)


We didn't put too much effort into making the traceback output pretty, 
so at the moment it's a draft. If there is an ascii artist out there 
who has suggestions on improving this, that would be great.



Well, yes. It's not really pretty. I would recommend a tree-based 
solution such as the following:



Traceback (most recent call last):
  File "", line 3, in 
ExceptionGroup
|
+---+   Traceback (most recent call last):
|   | File "", line 3, in 
|   |   ExceptionGroup: eg
|   |   |
|   |   +---+ ValueError: a
|   |
|   |   During handling of the above exception, another exception occurred:
|   |
|   |   Traceback (most recent call last):
|   | File "", line 5, in 
|   |   KeyError: 'x'
|
|
+---+   Traceback (most recent call last):
|   | File "", line 3, in 
|   |   ExceptionGroup: eg
|   |   |
|   |   +---+ TypeError: b


I used a similar pattern for the remote-execution lib and received good 
user feedback (even requesting color encoding for each layer of the tree 
(not the text), so people know what belongs together). Besides colors, I 
used https://en.wikipedia.org/wiki/Box-drawing_character but I guess 
pipes, dashes and pluses could suffice for CPython.



One other remark from my side here: in the example of the PEP there seem 
to be missing a space before 'File ""'. Comparing outer tbs with 
inner tbs, you can see that the "F" of "File" is not underneath the a of 
"Traceback" but underneath the "r" of it.


Regards,
Sven

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

[Python-Dev] [RELEASE] Python 3.10.0a6 is available, now with 100% more pattern matching

[Pablo Galindo Salgado]

Remember us? It's your friendly CPython release team and we have something
we think you may like: The new alpha release of Python 3.10 is here, now
with 100% more pattern matching. If I were you, I would download it and
start playing with it. Extra points if you report us any bugs you find
along the way! Are you confused about all this pattern matching business?
Fear not, this release also includes some fantastic documentation and some
shiny new "What's new" entries.

Check them here and tell us how we can improve it:

What's new: https://docs.python.org/3.10/whatsnew/3.10.html
Tutorial:
https://docs.python.org/3.10/tutorial/controlflow.html#match-statements

Go get the new alpha here:

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


*Note: The alpha was officially released yesterday, but my email client
failed to deliver this email to the mailing lists so I am reposting it.*
**This is an early developer preview of Python 3.10**

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

Python 3.10 is still in development.  This release, 3.10.0a6 is the sixth
of seven planned alpha releases.
Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.
During the alpha phase, features may be added up until the start of the
beta phase (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04).  Please keep in mind that
this is a preview release and its use is **not** recommended for production
environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major
new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from
Unicode
* [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.
* [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now
the default.
* [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

* (Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release),
currently scheduled for Monday, 2021-04-05.

# 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](/psf/donations/).

# And now for something completely different
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that the spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).

Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).

Regards from rainy London,

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

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

[Sven R. Kunze]

Hey Irit,

cool proposal.

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 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 these exceptions are wrapped, transferred to the parent process, 
there is the current call stack added, then reraised as a different 
exception, and so on and so forth if a chain of parents exist. The 
outermost parent process takes care of printing the tb.



My two questions regarding PEP 654:


1) What is the right "except pattern" when ExceptionGroup is introduced 
for the use cases described above (remote or concurrent python processes)?



2) What is the recommended approach of printing the traceback 
potentially incorporating multiple tracebacks - I couldn't find it in 
the PEP and tracebacks are a really neat tool for error hunting.



Best Regards,
Sven



On 23.02.21 01:24, 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/ 



It proposes language extensions that allow programs to raise and 
handle multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and other 
concurrency libraries,

but with other use cases as well.

* A new standard exception type, ExceptionGroup, to represent multiple 
exceptions with

  shared traceback.
* Updates to the traceback printing code to display (possibly nested) 
ExceptionGroups.

* A new syntax except* for handling ExceptionGroups.

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

[Python-Dev] Re: Which thing is "Development Mode"

[Paul Moore]

I'm somewhat baffled by your comment here. "Just because something is
bad or even often bad, is no reason to let it stay that way or to not
try and make things better." I have no idea what gives you the
impression that I think that way.

*Shrug* I guess I don't understand what you expect here. But if you
want to champion a change, I'm not going to stop you.

My comment on the packaging terminology stands, though - you'd be
better referring to that as "editable mode" as that is common usage,
*and* it doesn't clash with the cpython option.
Paul

On Tue, 2 Mar 2021 at 16:12, Coyot Linden (Glenn Glazer)
 wrote:
>
> On 3/1/21 08:49, Paul Moore wrote:
>
> On Mon, 1 Mar 2021 at 16:25, Coyot Linden (Glenn Glazer)
>  wrote:
>
> This is one of those cases, where those of us who have been around
> Python for awhile can perhaps infer from context which his meant, but
> the phrase "put your Python project into development mode" is ambiguous
> in a way that is different from your example.
>
> The commonly used packaging terminology is actually "editable mode"
> (at least in the sense that that's what most people seem to call it,
> so knowing and using that term will get better results from Google
> ;-)). If you feel inclined to raise a PR against the pip documentation
> to prefer that term, it can be discussed over there (but note that the
> underlying setuptools command is `setup.py develop` and that's not
> likely to change, as it's hard-coded in a number of applications,
> including pip).
>
> But ultimately, I think the reality is that there *are* terminology
> confusions all over the place in computing, much like in any other
> discipline (I'm currently teaching someone music, and the number of
> terms that get re-used in different contexts there is even worse than
> computing!) So I think that ultimately, beginners simply need to get
> used to understanding that terms can be context-dependent. It's not
> easy, and as teachers we can do what we can to make things clearer,
> but we can't ever completely make such problems go away.
>
> Paul
>
>
> I think we have fundamentally different worldviews, Paul. Just because 
> something is bad or even often bad, is no reason to let it stay that way or 
> to not try and make things better. Engineering almost never makes any problem 
> completely go away, the perfect can't be the enemy of the good.
>
> Personally, since it is newer and not stuck with the problems you mention, I 
> would prefer to change the name of the new Python runtime option than mess 
> with the setuptools mess.
>
> Best,
>
> coyot
___
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/VRLGKI5J6FFX7KFLFOCM2GI473CM5EFV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 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 these exceptions are wrapped, transferred to the parent process,
> there is the current call stack added, then reraised as a different
> exception, and so on and so forth if a chain of parents exist. The
> outermost parent process takes care of printing the tb.
>
>
> My two questions regarding PEP 654:
>
>
> 1) What is the right "except pattern" when ExceptionGroup is introduced
> for the use cases described above (remote or concurrent python processes)?
>

If you want to catch the whole ExceptionGroup and format its traceback,
then you can just do "except ExceptionGroup as eg" and then
traceback.print_exception(eg).

The except* syntax is for when you want to handle only certain types of
exceptions from the group, selectively.


> 2) What is the recommended approach of printing the traceback potentially
> incorporating multiple tracebacks - I couldn't find it in the PEP and
> tracebacks are a really neat tool for error hunting.
>

Part of the proposal of the PEP is that we teach the builtin traceback
formatting code to display ExceptionGroups with all that information. The
reference implementation has this, and the examples in the PEP were
produced with it. Some of the examples (the early ones) show exceptions
that were never raised so there is no traceback. But if you scroll down to
the later examples, you see the output for exceptions with tracebacks,
cause, context etc.

We didn't put too much effort into making the traceback output pretty, so
at the moment it's a draft. If there is an ascii artist out there who has
suggestions on improving this, that would be great.

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/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N6ACTVYIPUXQGUXF7EGFXTX27VAA45L3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Integer concatenation to byte string

[Memz]

Currently, the only way to concatenate an integer to a bytes object is by
converting
the integer to bytes with a function call before concatenating. And there
is no way to
make a mutable bytes object without a function call. And bytearray function
calls are 9-10x slower than b-strings.

I propose an array-type string like the, or for the bytearray. It would
work as a
mutable b-string, as

foo = a"\x00\x01\x02abcÿ"   # a-string, a mutable bytes object.
foo[0] = 123  # Item assignment
foo+= 255 # Works the same as
bytesvariable+=b"ÿ"
foo+= a"\x255\x00"  # Concatenation with itself
foo+= b"\x255\x00"  # Cross compatibility with bytes
objects.

This would be processed the same as, or would be the bytearray,

>>> type(a"\x00\x01\x02abcÿ")

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

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

[Irit Katriel via Python-Dev]

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 suggestions on syntax?


>
> As others have said needing to change all except Exception:
> handlers would be a breaking change for code that I maintain.
>

> I think its accepted that that idiom should continue to be as
> reliable as it currently is. Can you confirm that I have understood
> the conversation on this point?
>

That's not happening. The PEP has been updated regarding this.  It was
never going to be all "except Exception", most of them would not be
affected. But we have a better plan now so this discussion is moot.

As an aside - I found it interesting that the option to wrap BaseException
instances by an Exception, which came up a couple of times in this thread,
didn't generate any anxiety. In my day job I maintain a proprietary DSL
that ~4000 developers use, and my experience has been that a bug that
swallows an exception you need is worse than a bug that makes you get an
exception you did not expect. The latter can hurt you once (and then you
fix it). But the former is (1) harder to detect (2) longer to debug (3)
once you know about it there is nothing you can do to work around it.
Problems like that cost us years and years of work.


>
> I have been thinking about why I would be getting an ExceptionGroup
> with, for example, a number of OSError for a handler to deal with.
> Would it not be a difficult piece of code to write without the context of
> each OSError?
>
> What I'm think is that the lower level pieces would be catching the OSError
> closer to the source of the problem and raising a App/Lib specific
> exception
> that provides the context. For example AppFailedToSaveConfigError and
> AppFailedToSaveDataError as oppose to a two permission OSError's.
>


I think you're right about this. OSError is an example of an exception with
a data field that is often inspected for its value, so we picked on it to
talk about how you would do something like this. Most of the time this
won't be needed, but we still need to know that it's possible and
reasonably ergonomic to do it.


> With context I can imagine that handling the ExceptionGroup would be
> a lot easier for the App designer.
>
> If that the pattern that emerges then is the complexity of nested
> ExceptionGroups going to only rarely used?
>


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 from
a TemporaryDirectory.__exit__().

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/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3W6C3Y6WVKGYL4H63VDLB7VF6JH52TV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.10.0a6 is available, now with 100% more pattern matching

[Pablo Galindo Salgado]

Remember us? It's your friendly CPython release team and we have something
we think you may like: The new alpha release of Python 3.10 is here, now
with 100% more pattern matching. If I were you, I would download it and
start playing with it. Extra points if you report us any bugs you find
along the way! Are you confused about all this pattern matching business?
Fear not, this release also includes some fantastic documentation and some
shiny new "What's new" entries.

Check them here and tell us how we can improve it:

What's new: https://docs.python.org/3.10/whatsnew/3.10.html
Tutorial:
https://docs.python.org/3.10/tutorial/controlflow.html#match-statements

Go get the new alpha here:

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

**This is an early developer preview of Python 3.10**

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

Python 3.10 is still in development.  This release, 3.10.0a6 is the sixth
of seven planned alpha releases.
Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.
During the alpha phase, features may be added up until the start of the
beta phase (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04).  Please keep in mind that
this is a preview release and its use is **not** recommended for production
environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major
new features and changes so far:

* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from
Unicode
* [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.
* [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now
the default.
* [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


* (Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:pablog...@python.org
).)

The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release),
currently scheduled for Monday, 2021-04-05.

# 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](/psf/donations/).

# And now for something completely different
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that the spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
the spacetime).

Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).

Regards from rainy London,

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

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

[Barry Scott]

> On 23 Feb 2021, at 00:24, 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/ 
> 
> 
> It proposes language extensions that allow programs to raise and handle 
> multiple unrelated
> exceptions simultaneously, motivated by the needs of asyncio and other 
> concurrency libraries,
> but with other use cases as well.
> 
> * A new standard exception type,  ExceptionGroup, to represent multiple 
> exceptions with
>   shared traceback.
> * Updates to the traceback printing code to display (possibly nested) 
> ExceptionGroups.
> * A new syntax except* for handling ExceptionGroups.
> 
> A reference implementation (unreviewed) can be found at:
> https://github.com/iritkatriel/cpython/pull/10 
> 
Have you considered alternative syntax to the "except*"?
I feel that expect* is too easy to confuse with plain except.

As others have said needing to change all except Exception:
handlers would be a breaking change for code that I maintain.

I think its accepted that that idiom should continue to be as
reliable as it currently is. Can you confirm that I have understood
the conversation on this point?

I have been thinking about why I would be getting an ExceptionGroup
with, for example, a number of OSError for a handler to deal with.
Would it not be a difficult piece of code to write without the context of
each OSError?

What I'm think is that the lower level pieces would be catching the OSError
closer to the source of the problem and raising a App/Lib specific exception
that provides the context. For example AppFailedToSaveConfigError and
AppFailedToSaveDataError as oppose to a two permission OSError's.

With context I can imagine that handling the ExceptionGroup would be
a lot easier for the App designer.

If that the pattern that emerges then is the complexity of nested
ExceptionGroups going to only rarely used?

Barry


> 
> Thank you for your help
> 
> Kind regards
> Irit, Yury & Guido
> 
> 
> ___
> 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/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/
> 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/DPIXB6UFJFL2SIWPHNG2ZUURRJO7DTAV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Requesting Review of Pull Request

[Senthil Kumaran]

Hello Nathan,

The PR is merged. Thank you for contributing and following up here.

--
Senthil

On Tue, Mar 02, 2021 at 07:50:13PM +, Nathan Beals wrote:
> Good Afternoon Python Devs,
> 
> I'm requesting that someone review the pull request linked to this issue:
> https://bugs.python.org/issue42994 (github PR: https://github.com/python/
> cpython/pull/24287).
> 
> I'm following the contributing guidelines instructions to email this address 
> if
> the PR hasn't been addressed in a month (+1 week after pinging it again).
> Thankfully this PR is tiny, at 9 lines total (and even then, it's just 9 new
> entries to a dictionary).
> 
> Thank you for your time,
> Nathan Beals
> 

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

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

[Guido van Rossum]

On Tue, Mar 2, 2021 at 1:53 PM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

> [...]
> 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 from
> a TemporaryDirectory.__exit__().
>

I assume that in serious asyncio apps it is not uncommon to see some
operation use gather() to wrap several tasks, and then to see that
operation itself be passed to an outer gather() call together with some
other tasks. If several things go wrong you could easily end up with a
nested EG. Same in Trio -- you could have multiple nested "nurseries".

If you're catching such exceptions it may not be so important to be aware
of the nesting, but if you're logging tracebacks (or if the exception is
never caught and the program exits with a traceback) it is pretty important
to be able to show everything that went wrong without unnecessary
duplication of stack traces.

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