Re: random.SystemRandom().randint() inefficient

[Chris Angelico]

On Wed, 27 Jul 2022 at 09:28, Dennis Lee Bieber  wrote:
>
> On Tue, 26 Jul 2022 16:38:38 +0200, Cecil Westerhof 
> declaimed the following:
>
> >I need to get a random integer. At first I tried it with:
> >from secrets import randbelow
> >index = randbelow(len(to_try))
> >
> >This works perfectly, but it took some time. So I thought I try:
> >from random  import SystemRandom
> >index = SystemRandom().randint(0, len(to_try) - 1)
> >
> >A first indication is that the second version would take about two
> >times as much time as the first. Is there a reason for this, or should
> >this not be happening?
>
> Well, off the top of my head...
>
> For one generation of "index" you are first creating an instance of
> SystemRandom(), using it to generate your random integer, and then
> disposing of the instance.
>
> If you only need ONE random integer, the time difference probably
> doesn't matter. OTOH, if you need many during the run, using
>
> sr = SystemRandom()
> #stuff in some loop that generates multiple ints
> index = sr.randint(...)
>
> Hmmm, wonder if there is a speed difference between
> .randint(0, len(to_try) - 1)
> and
> .randint(1, len(to_try)) - 1
>

Probably not significant, since the same amount of arithmetic gets
done either way. But switching to single-arg randrange(len(to_try))
will definitely help, and IMO is clearer as well (since the
implication is selecting one from a group of items).

Incidentally - if you are actually trying to select a specific item,
you may want to consider random.choice.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Dennis Lee Bieber]

On Tue, 26 Jul 2022 23:47:59 +0200, Cecil Westerhof 
declaimed the following:


>The new code:
>from random  import SystemRandom
>system_random   = SystemRandom()
>index = system_random.randint(0, len(to_try) - 1)
>
>The first two statements are executed once.
>The last statement I think about 75 * 10 ** 6.
>
>So it seems that my first idea of using randbelow was the correct one.
>But if anyone could explain why SystemRandom is so much more
>expensive, I would be interested to know it.
>(Or am I still doing something wrong?)

What happens with

system_randint = SystemRandom().randint #no parens

index = system_randint(...)

which may remove the method lookup from the repetition.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Dennis Lee Bieber]

On Tue, 26 Jul 2022 16:38:38 +0200, Cecil Westerhof 
declaimed the following:

>I need to get a random integer. At first I tried it with:
>from secrets import randbelow
>index = randbelow(len(to_try))
>
>This works perfectly, but it took some time. So I thought I try:
>from random  import SystemRandom
>index = SystemRandom().randint(0, len(to_try) - 1)
>
>A first indication is that the second version would take about two
>times as much time as the first. Is there a reason for this, or should
>this not be happening?

Well, off the top of my head...

For one generation of "index" you are first creating an instance of
SystemRandom(), using it to generate your random integer, and then
disposing of the instance.

If you only need ONE random integer, the time difference probably
doesn't matter. OTOH, if you need many during the run, using

sr = SystemRandom()
#stuff in some loop that generates multiple ints
index = sr.randint(...)

Hmmm, wonder if there is a speed difference between
.randint(0, len(to_try) - 1)
and
.randint(1, len(to_try)) - 1


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Chris Angelico]

On Wed, 27 Jul 2022 at 08:18, Cecil Westerhof via Python-list
 wrote:
>
> Chris Angelico  writes:
>
> > On Wed, 27 Jul 2022 at 06:06, Cecil Westerhof via Python-list
> >  wrote:
> >>
> >> Chris Angelico  writes:
> >>
> >> > On Wed, 27 Jul 2022 at 01:06, Cecil Westerhof via Python-list
> >> >  wrote:
> >> >>
> >> >> I need to get a random integer. At first I tried it with:
> >> >> from secrets import randbelow
> >> >> index = randbelow(len(to_try))
> >> >>
> >> >> This works perfectly, but it took some time. So I thought I try:
> >> >> from random  import SystemRandom
> >> >> index = SystemRandom().randint(0, len(to_try) - 1)
> >> >>
> >> >> A first indication is that the second version would take about two
> >> >> times as much time as the first. Is there a reason for this, or should
> >> >> this not be happening?
> >> >>
> >> >
> >> > You're setting up a brand new SystemRandom instance just for a single
> >> > random number. For a fairer comparison, set up the instance, then
> >> > generate far more than just a single number, and see how that goes.
> >>
> >> Thanks. I thought I did something wrong and I did.
> >> I will try to implement like you said and look what the result will
> >> be. (And share it.)
> >
> > Thanks! Don't feel bad; performance testing is *hard*, getting
> > meaningful results takes a lot of of fiddling with parameters, and
> > getting interesting AND meaningful results can sometimes seem about
> > impossible.
> >
> >> (As I understand it both do more, or less the same and should have
> >> comparable performance.)
> >
> > In normal production work? Yes (the SystemRandom object doesn't have
> > any significant state - a seeded RNG could have a lot more overhead
> > here). But for performance testing? The work of instantiating the
> > class could be completely irrelevant, or it could be dominating your
> > results. It's hard to say, hence the suggestion to try it without
> > reinstantiating.
>
> It had a very big influence. Original it took about three times more
> time to run my program. (The program was still running when I posted
> the original post and the difference was higher as I anticipated.)
> Removing that did cut about 45% of the execution time of the program.
> (So the initiation is quit expensive.)
> But it still takes about 50% more time. So I am still a bit
> flabbergasted.
>
> The new code:
> from random  import SystemRandom
> system_random   = SystemRandom()
> index = system_random.randint(0, len(to_try) - 1)
>
> The first two statements are executed once.
> The last statement I think about 75 * 10 ** 6.
>
> So it seems that my first idea of using randbelow was the correct one.
> But if anyone could explain why SystemRandom is so much more
> expensive, I would be interested to know it.
> (Or am I still doing something wrong?)

Hmm. There are still a lot of differences here. Are you able to make
use of randrange() instead, to make them more consistent?

According to the source code, secrets.randbelow is calling on an
internal method _randbelow of the SystemRandom object, but randrange
(if called with only one arg) will go straight into that same method.
Here's my results:

rosuav@sikorsky:~$ python3 -m timeit -s 'from random import randrange'
'randrange(1)'
100 loops, best of 5: 322 nsec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from random import
SystemRandom; r = SystemRandom()' 'r.randint(0, 1)'
20 loops, best of 5: 1.92 usec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from random import
SystemRandom; r = SystemRandom()' 'r.randrange(1)'
20 loops, best of 5: 1.87 usec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from secrets import
randbelow' 'randbelow(1)'
20 loops, best of 5: 1.64 usec per loop

(The difference with the first one is that it isn't using the system
RNG, so it has the limitations of an internal PRNG.)

When you call randint, what happens is (1) the endpoint is incremented
to transform it from inclusive-inclusive to inclusive-exclusive; (2)
randrange is called with two args; (3) fast path 1 is skipped, fast
path 2 is taken, and _randbelow gets called to get an actual random
number, which gets zero added to it before returning.

If, instead, you use randrange(len(to_try)), what would happen is (1)
fast path 1 is used, and (2) _randbelow is called to get the random
number.

In secrets.randbelow, it's even better: (1) _randbelow is called to
get the random number.

I think that might be what's going on here. You're adding some tiny
amounts of extra work, but if you were to make them more similar, the
distinctions would evaporate. Here's a couple of other variants that
use SystemRandom:

rosuav@sikorsky:~$ python3 -m timeit -s 'from random import
SystemRandom; randrange = SystemRandom().randrange' 'randrange(1)'
20 loops, best of 5: 1.81 usec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from random import
SystemRandom; randrange = SystemRandom()._randbelow'

Re: random.SystemRandom().randint() inefficient

[Cecil Westerhof via Python-list]

Chris Angelico  writes:

> On Wed, 27 Jul 2022 at 06:06, Cecil Westerhof via Python-list
>  wrote:
>>
>> Chris Angelico  writes:
>>
>> > On Wed, 27 Jul 2022 at 01:06, Cecil Westerhof via Python-list
>> >  wrote:
>> >>
>> >> I need to get a random integer. At first I tried it with:
>> >> from secrets import randbelow
>> >> index = randbelow(len(to_try))
>> >>
>> >> This works perfectly, but it took some time. So I thought I try:
>> >> from random  import SystemRandom
>> >> index = SystemRandom().randint(0, len(to_try) - 1)
>> >>
>> >> A first indication is that the second version would take about two
>> >> times as much time as the first. Is there a reason for this, or should
>> >> this not be happening?
>> >>
>> >
>> > You're setting up a brand new SystemRandom instance just for a single
>> > random number. For a fairer comparison, set up the instance, then
>> > generate far more than just a single number, and see how that goes.
>>
>> Thanks. I thought I did something wrong and I did.
>> I will try to implement like you said and look what the result will
>> be. (And share it.)
>
> Thanks! Don't feel bad; performance testing is *hard*, getting
> meaningful results takes a lot of of fiddling with parameters, and
> getting interesting AND meaningful results can sometimes seem about
> impossible.
>
>> (As I understand it both do more, or less the same and should have
>> comparable performance.)
>
> In normal production work? Yes (the SystemRandom object doesn't have
> any significant state - a seeded RNG could have a lot more overhead
> here). But for performance testing? The work of instantiating the
> class could be completely irrelevant, or it could be dominating your
> results. It's hard to say, hence the suggestion to try it without
> reinstantiating.

It had a very big influence. Original it took about three times more
time to run my program. (The program was still running when I posted
the original post and the difference was higher as I anticipated.)
Removing that did cut about 45% of the execution time of the program.
(So the initiation is quit expensive.)
But it still takes about 50% more time. So I am still a bit
flabbergasted.

The new code:
from random  import SystemRandom
system_random   = SystemRandom()
index = system_random.randint(0, len(to_try) - 1)

The first two statements are executed once.
The last statement I think about 75 * 10 ** 6.

So it seems that my first idea of using randbelow was the correct one.
But if anyone could explain why SystemRandom is so much more
expensive, I would be interested to know it.
(Or am I still doing something wrong?)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Chris Angelico]

On Wed, 27 Jul 2022 at 06:06, Cecil Westerhof via Python-list
 wrote:
>
> Chris Angelico  writes:
>
> > On Wed, 27 Jul 2022 at 01:06, Cecil Westerhof via Python-list
> >  wrote:
> >>
> >> I need to get a random integer. At first I tried it with:
> >> from secrets import randbelow
> >> index = randbelow(len(to_try))
> >>
> >> This works perfectly, but it took some time. So I thought I try:
> >> from random  import SystemRandom
> >> index = SystemRandom().randint(0, len(to_try) - 1)
> >>
> >> A first indication is that the second version would take about two
> >> times as much time as the first. Is there a reason for this, or should
> >> this not be happening?
> >>
> >
> > You're setting up a brand new SystemRandom instance just for a single
> > random number. For a fairer comparison, set up the instance, then
> > generate far more than just a single number, and see how that goes.
>
> Thanks. I thought I did something wrong and I did.
> I will try to implement like you said and look what the result will
> be. (And share it.)

Thanks! Don't feel bad; performance testing is *hard*, getting
meaningful results takes a lot of of fiddling with parameters, and
getting interesting AND meaningful results can sometimes seem about
impossible.

> (As I understand it both do more, or less the same and should have
> comparable performance.)

In normal production work? Yes (the SystemRandom object doesn't have
any significant state - a seeded RNG could have a lot more overhead
here). But for performance testing? The work of instantiating the
class could be completely irrelevant, or it could be dominating your
results. It's hard to say, hence the suggestion to try it without
reinstantiating.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Cecil Westerhof via Python-list]

Chris Angelico  writes:

> On Wed, 27 Jul 2022 at 01:06, Cecil Westerhof via Python-list
>  wrote:
>>
>> I need to get a random integer. At first I tried it with:
>> from secrets import randbelow
>> index = randbelow(len(to_try))
>>
>> This works perfectly, but it took some time. So I thought I try:
>> from random  import SystemRandom
>> index = SystemRandom().randint(0, len(to_try) - 1)
>>
>> A first indication is that the second version would take about two
>> times as much time as the first. Is there a reason for this, or should
>> this not be happening?
>>
>
> You're setting up a brand new SystemRandom instance just for a single
> random number. For a fairer comparison, set up the instance, then
> generate far more than just a single number, and see how that goes.

Thanks. I thought I did something wrong and I did.
I will try to implement like you said and look what the result will
be. (And share it.)

(As I understand it both do more, or less the same and should have
comparable performance.)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python code: brief

[dn]

On 27/07/2022 06.24, KK CHN wrote:
> List ,
> 
> I have come across a difficulty to understand the code in this file.  I am
> unable to understand exactly what the code snippet is doing here.
> 
> https://raw.githubusercontent.com/CODARcode/MDTrAnal/master/lib/codar/oas/MDTrSampler.py
> 
> I am new to this type of scientific computing code snippets and it is coded
> by someone.  Due to a requirement I would like to understand what these
> lines of code will do exactly.  If someone  could explain to me what the
> code snippets do in the code blocks, it will be a great help .


Which lines of code, specifically?
Is it some Python idiom that is problematic, or the code-logic?

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Python code: brief

[KK CHN]

List ,

I have come across a difficulty to understand the code in this file.  I am
unable to understand exactly what the code snippet is doing here.

https://raw.githubusercontent.com/CODARcode/MDTrAnal/master/lib/codar/oas/MDTrSampler.py

I am new to this type of scientific computing code snippets and it is coded
by someone.  Due to a requirement I would like to understand what these
lines of code will do exactly.  If someone  could explain to me what the
code snippets do in the code blocks, it will be a great help .

Thanks in advance
Krish
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Chris Angelico]

On Wed, 27 Jul 2022 at 01:06, Cecil Westerhof via Python-list
 wrote:
>
> I need to get a random integer. At first I tried it with:
> from secrets import randbelow
> index = randbelow(len(to_try))
>
> This works perfectly, but it took some time. So I thought I try:
> from random  import SystemRandom
> index = SystemRandom().randint(0, len(to_try) - 1)
>
> A first indication is that the second version would take about two
> times as much time as the first. Is there a reason for this, or should
> this not be happening?
>

You're setting up a brand new SystemRandom instance just for a single
random number. For a fairer comparison, set up the instance, then
generate far more than just a single number, and see how that goes.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Weatherby,Gerard]

Absolutely. The task (“generate a random number”) is ill-defined.

Want a fast random number? Use 552015933 (I just retrieved it from random.org).

Want a true random number, use random.org API. (https://api.random.org/pricing).

Something in between, follow approaches Stefan suggests.



—
Gerard Weatherby | Application Architect NMRbox | NAN | Department of Molecular 
Biology and Biophysics
 UConn Health 263 Farmington Avenue, Farmington, CT 06030-6406 uchc.edu
On Jul 26, 2022, 11:45 AM -0400, Stefan Ram , wrote:
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

Cecil Westerhof  writes:
I need to get a random integer.

There are all kinds of trade-offs. When you need entropy,
the function sometimes has to collect data from hardware,
which takes some time. Pseudo-random integers sometimes can
be calculated faster. As a compromise, you can get some
entropy and use it to initialize ("seed") a pseudo-random
number generator and then get some pseudo-random numbers
until you seed it again. A linear-congruential generator
should be fast enough, but in some cases might not be random
enough.


--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kjJ7U6kkSW8uOTWJCnHeXn0Acczd619asmIrVMA_NOqvP_JMqqQ1Rpp61sptQucbOuEFGb6ot499_FqaRajiS9s$
-- 
https://mail.python.org/mailman/listinfo/python-list

random.SystemRandom().randint() inefficient

[Cecil Westerhof via Python-list]

I need to get a random integer. At first I tried it with:
from secrets import randbelow
index = randbelow(len(to_try))

This works perfectly, but it took some time. So I thought I try:
from random  import SystemRandom
index = SystemRandom().randint(0, len(to_try) - 1)

A first indication is that the second version would take about two
times as much time as the first. Is there a reason for this, or should
this not be happening?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

PEP about recommended project folder layout

[c . buhtz]

Hello,

I am not sure if I looked into the correct sources. I was looking in 
"PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the 
"PyPA specifications" [2].


My question in short: Is there an official document (e.g. a PEP) about a 
recommended layout for project folders.


Looking into the wild and past there are a lot of variations of such 
layouts. I am far away from being a pro but depending on experience in 
my own projects and what I have learned from others (e.g. in 
blog-posts/tutorials) I recommend to have the "test" folder and the 
package folder side by side on the same level in the project folder (the 
root).


my_project
|- tests
|  └ test_*.py
|- my_package
|  └ __init__.py
└-- README.md

I sometimes add to it the so called "src"-Layout where the package 
folder is one level deeper in an extra "src" folder.


my_project
|- tests
|  └ test_*.py
|- src
|  └- my_package
| └ __init__.py
└-- README.md

I don't want to discuss the pros and cons of all variations. What I need 
is an official document I can use in discussions with other maintainers. 
If there is a PEP/document against my current recommendation I am also 
fine with this. ;)


Kind
Christian

[1] -- 
[2] -- 
--
https://mail.python.org/mailman/listinfo/python-list

[Python-announce] [ANN] Numba 0.56.0 and llvmlite 0.39.0

[Valentin Haenel]

Dear all,

Numba 0.56.0 and llvmlite 0.39.0 have been released.  Please point your
browsers at our Discourse for more information:

https://numba.discourse.group/t/ann-numba-0-56-0/1461

https://numba.discourse.group/t/ann-llvmlite-0-39-0/1460

Best,

V-
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] [RELEASE] The last 3.11 beta release (3.11.0b5) is now available

[Pablo Galindo Salgado]

Here we are. The universe. The vastness of spacetime. At the edge. The last
frontier. The last beta*(conditions apply) for Python 3.11.

We have defied the powerful gods of release blockers and we have won by
using the required amount of ruse and subterfuge.

https://www.python.org/downloads/release/python-3110b5/

## :warning:  PLEASE HELP US TO TEST THIS RELEASE :warning:

Due to the modified release schedule and the stability concerns regarding
the past beta releases, please, please, please, please, help us to test
Python 3.11 by testing this beta releases.

* if you maintain a library or a third-party package. Test the beta
releases!
* If you have code that you maintain at work/research
centre/classroom/whatever. Test the beta releases!
* If you are a multi-million corporation that uses Python. Test the beta
releases!
* If you are a single-person company that uses Python. Test the beta
releases!
* If you have a bunch of Python scripts. Test the beta releases!
* If you use Python for work, research, teaching or literally for anything.
Test the beta releases!
* If you ...

In summary: no matter who you are of what you do. Test the beta releases!

Is **very** important for us that we identify all possible things that may
break your code **before** the final release is done and we can only do
this if you help us by testing the beta releases and then report anything
that doesn't work!

## This is a beta preview of Python  3.11

Python 3.11 is still in development. 3.11.0b5 is the last of five planned
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

We **strongly encourage** maintainers of third-party Python projects to
**test with 3.11** during the beta phase and report issues found to [the
Python bug tracker](https://github.com/python/cpython/issues) as soon as
possible.  While the release is planned to be feature complete entering the
beta phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2021-08-02).  Our goal is have no ABI changes after beta 5 and as few code
changes as possible after 3.11.0rc1, the first release candidate.  To
achieve that, it will be **extremely important** to get as much exposure
for 3.11 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

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

Some of the new major new features and changes in Python 3.11 are:

## General changes

* [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include
Fine-Grained Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups
and except*
* [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
for Parsing TOML in the Standard Library
* [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class
Transforms
* [bpo-46752](https://github.com/python/cpython/issues/90908)-- Introduce
task groups to asyncio
* [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic
grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are
now supported in regular expressions.
* The [Faster Cpython Project](https://github.com/faster-cpython/) is
already yielding some exciting results. Python 3.11 is up to 10-60% faster
than Python 3.10. On average, we measured a 1.22x speedup on the standard
benchmark suite. See [Faster CPython](
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details.

## Typing and typing language changes

* [PEP 673](https://www.python.org/dev/peps/pep-0673/)  -- Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics
* [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual
TypedDict items as required or potentially-missing

(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.11 will be 3.11.0rc1, currently scheduled
for Monday, 2022-08-01.

# More resources

* [Online Documentation](https://docs.python.org/3.11/)
* [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release
Schedule
* Report bugs at [
https://github.com/python/cpython/issues](https://github.com/python/cpython/issues)
.
* [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 

[RELEASE] The last 3.11 beta release (3.11.0b5) is now available

[Pablo Galindo Salgado]

Here we are. The universe. The vastness of spacetime. At the edge. The last
frontier. The last beta*(conditions apply) for Python 3.11.

We have defied the powerful gods of release blockers and we have won by
using the required amount of ruse and subterfuge.

https://www.python.org/downloads/release/python-3110b5/

## :warning:  PLEASE HELP US TO TEST THIS RELEASE :warning:

Due to the modified release schedule and the stability concerns regarding
the past beta releases, please, please, please, please, help us to test
Python 3.11 by testing this beta releases.

* if you maintain a library or a third-party package. Test the beta
releases!
* If you have code that you maintain at work/research
centre/classroom/whatever. Test the beta releases!
* If you are a multi-million corporation that uses Python. Test the beta
releases!
* If you are a single-person company that uses Python. Test the beta
releases!
* If you have a bunch of Python scripts. Test the beta releases!
* If you use Python for work, research, teaching or literally for anything.
Test the beta releases!
* If you ...

In summary: no matter who you are of what you do. Test the beta releases!

Is **very** important for us that we identify all possible things that may
break your code **before** the final release is done and we can only do
this if you help us by testing the beta releases and then report anything
that doesn't work!

## This is a beta preview of Python  3.11

Python 3.11 is still in development. 3.11.0b5 is the last of five planned
beta release previews. Beta release previews are intended to give the wider
community the opportunity to test new features and bug fixes and to prepare
their projects to support the new feature release.

We **strongly encourage** maintainers of third-party Python projects to
**test with 3.11** during the beta phase and report issues found to [the
Python bug tracker](https://github.com/python/cpython/issues) as soon as
possible.  While the release is planned to be feature complete entering the
beta phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2021-08-02).  Our goal is have no ABI changes after beta 5 and as few code
changes as possible after 3.11.0rc1, the first release candidate.  To
achieve that, it will be **extremely important** to get as much exposure
for 3.11 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

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

Some of the new major new features and changes in Python 3.11 are:

## General changes

* [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include
Fine-Grained Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups
and except*
* [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support
for Parsing TOML in the Standard Library
* [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class
Transforms
* [bpo-46752](https://github.com/python/cpython/issues/90908)-- Introduce
task groups to asyncio
* [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic
grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are
now supported in regular expressions.
* The [Faster Cpython Project](https://github.com/faster-cpython/) is
already yielding some exciting results. Python 3.11 is up to 10-60% faster
than Python 3.10. On average, we measured a 1.22x speedup on the standard
benchmark suite. See [Faster CPython](
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details.

## Typing and typing language changes

* [PEP 673](https://www.python.org/dev/peps/pep-0673/)  -- Self Type
* [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics
* [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal
String Type
* [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual
TypedDict items as required or potentially-missing

(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.11 will be 3.11.0rc1, currently scheduled
for Monday, 2022-08-01.

# More resources

* [Online Documentation](https://docs.python.org/3.11/)
* [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release
Schedule
* Report bugs at [
https://github.com/python/cpython/issues](https://github.com/python/cpython/issues)
.
* [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 

Re: My first attempt at a package.

[Antoon Pardon]

Op 25/07/2022 om 16:43 schreef Dennis Lee Bieber:

On Mon, 25 Jul 2022 10:39:46 +0200, Antoon Pardon 
declaimed the following:


Yes it is, but it doesn't answer my question: How do I create a package
in which a file is built at install time.
I just want to build a configuration file that will among some other
info contain the date the package
was installed. The idea is that you can execute python3 -m
.release to know what version
of the package you installed and when you installed it. But seem unable
to find a way to do this.

Does
https://stackoverflow.com/questions/72320778/autostart-installed-package-with-python
provide any hints?


Yes it does, thanks.

--
https://mail.python.org/mailman/listinfo/python-list