EuroPython 2020: Introducing our Diamond Sponsor Bloomberg

[M.-A. Lemburg]

We are very pleased to have Bloomberg as Diamond Sponsor for EuroPython
2020. Without sponsors like Bloomberg, we wouldn't be able to make the
event affordable.

You will be able to visit their sponsor exhibit rooms and take the
opportunity to chat with their staff to learn more about the large
Python eco-system they have built internally and how they are
collaborating with the Python community.

Please read a hosted blog post from Bloomberg on our blog with full
detail:

https://blog.europython.eu/post/624164489818980352/europython-2020-introducing-our-diamond-sponsor


Help spread the word


Please help us spread this message by sharing it on your social networks
as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/624164489818980352/europython-2020-introducing-our-diamond-sponsor

Tweet:

https://twitter.com/europython/status/1285198014060154882

Thanks,
--
EuroPython 2020 Team
https://ep2020.europython.eu/
https://www.europython-society.org/

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

Typing modules

[Jonathan Gossage]

I have the following code and I would like to type the variable *contents*:

contents: something = importlib._import_module(name)


I have been unable to find out what *something* should be.

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

Re: Typing modules

[Stephan Lukits]

> On 20 Jul 2020, at 16:31, Jonathan Gossage  wrote:
> 
> I have the following code and I would like to type the variable *contents*:
> 
> contents: something = importlib._import_module(name)
> 
> 
> I have been unable to find out what *something* should be.

types.ModuleType

> 
> -- 
> Jonathan Gossage
> -- 
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 3.8.5 released as a security hotfix. 3.9.0b5, the last beta before 3.9.0, also available

[Łukasz Langa]

This is a combined release of Python 3.8.5 and 3.9.0b5. Both are significant 
but for different reasons. Let’s dig in!

Security content in 3.8.5

We decided to release 3.8.5 ahead of schedule due to a number of 
security-related fixes. All details can be found in the change log 
 but 
the gist is:

CVE-2019-20907 : infinite loop in a 
maliciously created .tar file
BPO-41288 : segmentation fault during 
unpickling of objects using a crafted NEWOBJ_EX opcode
BPO-39603 : HTTP headers could be injected 
through a maliciously crafter method parameter in http.client
the original fix for CVE-2020-15801 caused a regression in 3.8.4 (see: 
BPO-41304 )
A small number of other urgent regression fixes and quality-of-life 
improvements are also present in the release. Get the release here:

https://www.python.org/downloads/release/python-385/ 


Maintenance releases for the 3.8 series will continue at the regular bi-monthly 
calendar, with 3.8.6 planned for mid-September 2020.
The last beta of Python 3.9.0 now also available

Python 3.9 is still in development. This release, 3.9.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. You can get 3.9.0b5 
here:

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


The next pre-release, the first release candidate of Python 3.9.0, will be 
3.9.0rc1. It is currently scheduled for 2020-08-10.
Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.9 during the beta phase and report issues found to the Python bug tracker 
 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 (2020-08-10). Our goal is have no ABI changes after beta 5 and 
as few code changes as possible after 3.9.0rc1, the first release candidate. To 
achieve that, it will be extremely important to get as much exposure for 3.9 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.

A reminder for core developers

To help make Python 3.9.0 the best possible release, our Development Cycle 
 section of the 
Python Developer’s Guide documents that:

A branch preparing for an RC release can only have bugfixes applied that have 
been reviewed by other core developers. Generally, these issues must be severe 
enough (e.g. crashes) that they deserve fixing before the final release. All 
other issues should be deferred to the next development cycle, since stability 
is the strongest concern at this point.

You cannot skip the peer review during an RC, no matter how small! Even if it 
is a simple copy-and-paste change, everything requires peer review from a core 
developer.

Major new features of the 3.9 series, compared to 3.8

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

PEP 584 , Union Operators in dict

PEP 585 , Type Hinting Generics In 
Standard Collections

PEP 593 , Flexible function and 
variable annotations

PEP 602 , Python adopts a stable 
annual release cadence

PEP 615 , Support for the IANA Time 
Zone Database in the Standard Library

PEP 616 , String methods to remove 
prefixes and suffixes

PEP 617 , New PEG parser for CPython

BPO 38379 , garbage collection does not 
block on resurrected objects;

BPO 38692 , os.pidfd_open added that allows 
process management without races and signals;

BPO 39926 , Unicode support updated to 
version 13.0.0;

BPO 1635741 , when Python is initialized 
multiple times in the same process, it does not leak memory anymore;

A number of Python builtins (range, tuple, set, frozenset, list, dict) are now 
sped up using PEP 590  vectorcall;

A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, 
_functools, _json, _locale, operator, resource, time, _weakref) n

Re: frozendict: an experiment

[Marco Sulla]

I just finished to improve the performance of frozendict creation. The
result is very promising.

The speedup is about 30% for small dicts (8 items). For large dicts (1k
items) is about 38% for dicts with only integers as keys and values, and
45% for dicts with only strings.

There's also a little speedup in iteration.

Here's the code:

https://github.com/Marco-Sulla/cpython/commit/8d6c7f727a55d9d922c8a3a755fcb6c68ed26197

The benchmark output:

Name: `constructor(d)`; Size:8; Keys:  int; Type:
dict; Time: 2.956e-07
Name: `constructor(d)`; Size:8; Keys:  int; Type:
frozendict; Time: 2.100e-07

Name: `constructor(d)`; Size:8; Keys:  str; Type:
dict; Time: 2.922e-07
Name: `constructor(d)`; Size:8; Keys:  str; Type:
frozendict; Time: 2.095e-07

Name: `constructor(d)`; Size: 1000; Keys:  int; Type:
dict; Time: 2.401e-05
Name: `constructor(d)`; Size: 1000; Keys:  int; Type:
frozendict; Time: 1.309e-05

Name: `constructor(d)`; Size: 1000; Keys:  str; Type:
dict; Time: 1.822e-05
Name: `constructor(d)`; Size: 1000; Keys:  str; Type:
frozendict; Time: 1.115e-05

You can find the tests and the benchmark code here:
https://github.com/Marco-Sulla/cpython/tree/master/frozendict/test

Here is the entire output of the benchmark:
https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.txt

Notice that d[key] and the constructor(pairs_sequence) is a little slower.
I didn't touch them, so probably this is because I changed frozendict to a
split dict. So I suppose there's a lot of room for other improvements.

Equality check can be improved too, since the object address can be checked
first.

I think the major speedup is due the fact I implemented the solution with a
split dict, as suggested by Inada. Even if some of the improvements could
be applied to dict too, combined dicts could be more efficient and easy to
use for sorting, insertion and deletion.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: frozendict: an experiment

[Inada Naoki]

On Tue, Jul 21, 2020 at 5:07 AM Marco Sulla  wrote:
>
> I just finished to improve the performance of frozendict creation. The result 
> is very promising.
>
> The speedup is about 30% for small dicts (8 items). For large dicts (1k 
> items) is about 38% for dicts with only integers as keys and values, and 45% 
> for dicts with only strings.

Do you mean `frozendict(d)` where d is frozendict?
If so, you don't need to create a new dict. You can just incref the d
and return it.
That is what we do in tuple and frozenset.

> I think the major speedup is due the fact I implemented the solution with a 
> split dict, as suggested by Inada. Even if some of the improvements could be 
> applied to dict too, combined dicts could be more efficient and easy to use 
> for sorting, insertion and deletion.
>

Oh, I don't recommend split dict until you find use case that you can
share many keys.
In general, combined dict is little faster and much efficient.

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