[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Inada Naoki 
On Tue, Jun 25, 2019 at 5:49 AM Antoine Pitrou  wrote:
>
>
> For the record, there's another contender in the allocator
> competition now:
> https://github.com/microsoft/mimalloc/
>
> Regards
>
> Antoine.

It's a very strong competitor!

$ ./python -m pyperf compare_to pymalloc.json mimalloc.json -G --min-speed=3
Faster (14):
- spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
- unpickle: 19.7 us +- 1.9 us -> 17.6 us +- 1.3 us: 1.12x faster (-11%)
- json_dumps: 17.1 ms +- 0.2 ms -> 15.7 ms +- 0.2 ms: 1.09x faster (-8%)
- json_loads: 39.0 us +- 2.6 us -> 36.2 us +- 1.1 us: 1.08x faster (-7%)
- crypto_pyaes: 162 ms +- 1 ms -> 150 ms +- 1 ms: 1.08x faster (-7%)
- regex_effbot: 3.62 ms +- 0.04 ms -> 3.38 ms +- 0.01 ms: 1.07x faster (-7%)
- pickle_pure_python: 689 us +- 53 us -> 650 us +- 5 us: 1.06x faster (-6%)
- scimark_fft: 502 ms +- 2 ms -> 478 ms +- 2 ms: 1.05x faster (-5%)
- float: 156 ms +- 2 ms -> 149 ms +- 1 ms: 1.05x faster (-5%)
- pathlib: 29.0 ms +- 0.5 ms -> 27.7 ms +- 0.4 ms: 1.05x faster (-4%)
- mako: 22.4 ms +- 0.1 ms -> 21.6 ms +- 0.2 ms: 1.04x faster (-4%)
- scimark_sparse_mat_mult: 6.21 ms +- 0.04 ms -> 5.99 ms +- 0.08 ms:
1.04x faster (-3%)
- xml_etree_parse: 179 ms +- 5 ms -> 173 ms +- 3 ms: 1.04x faster (-3%)
- sqlalchemy_imperative: 42.0 ms +- 0.9 ms -> 40.7 ms +- 0.9 ms: 1.03x
faster (-3%)

Benchmark hidden because not significant (46): ...
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CTIOESA4NQSWSXH5SZ5D6D7YITDGK33S/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Antoine Pitrou 
On Thu, 4 Jul 2019 16:19:52 +0900
Inada Naoki  wrote:

> On Tue, Jun 25, 2019 at 5:49 AM Antoine Pitrou  wrote:
> >
> >
> > For the record, there's another contender in the allocator
> > competition now:
> > https://github.com/microsoft/mimalloc/
> >
> > Regards
> >
> > Antoine.  
> 
> It's a very strong competitor!
> 
> $ ./python -m pyperf compare_to pymalloc.json mimalloc.json -G --min-speed=3
> Faster (14):
> - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
> - unpickle: 19.7 us +- 1.9 us -> 17.6 us +- 1.3 us: 1.12x faster (-11%)
> - json_dumps: 17.1 ms +- 0.2 ms -> 15.7 ms +- 0.2 ms: 1.09x faster (-8%)
> - json_loads: 39.0 us +- 2.6 us -> 36.2 us +- 1.1 us: 1.08x faster (-7%)
> - crypto_pyaes: 162 ms +- 1 ms -> 150 ms +- 1 ms: 1.08x faster (-7%)
> - regex_effbot: 3.62 ms +- 0.04 ms -> 3.38 ms +- 0.01 ms: 1.07x faster (-7%)
> - pickle_pure_python: 689 us +- 53 us -> 650 us +- 5 us: 1.06x faster (-6%)
> - scimark_fft: 502 ms +- 2 ms -> 478 ms +- 2 ms: 1.05x faster (-5%)
> - float: 156 ms +- 2 ms -> 149 ms +- 1 ms: 1.05x faster (-5%)
> - pathlib: 29.0 ms +- 0.5 ms -> 27.7 ms +- 0.4 ms: 1.05x faster (-4%)
> - mako: 22.4 ms +- 0.1 ms -> 21.6 ms +- 0.2 ms: 1.04x faster (-4%)
> - scimark_sparse_mat_mult: 6.21 ms +- 0.04 ms -> 5.99 ms +- 0.08 ms:
> 1.04x faster (-3%)
> - xml_etree_parse: 179 ms +- 5 ms -> 173 ms +- 3 ms: 1.04x faster (-3%)
> - sqlalchemy_imperative: 42.0 ms +- 0.9 ms -> 40.7 ms +- 0.9 ms: 1.03x
> faster (-3%)
> 
> Benchmark hidden because not significant (46): ...

Ah, interesting.  Were you able to measure the memory footprint as well?

Regards

Antoine.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/47NHQNPQVR6GPZ3PPRCAVZLPRXGV4GNW/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Inada Naoki 
On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou  wrote:
>
> Ah, interesting.  Were you able to measure the memory footprint as well?
>

Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
benchmarks.  I will look it later.

```
$ ./python  -m pyperf compare_to pymalloc-mem.json mimalloc-mem.json -G
Slower (60):
- logging_format: 10.6 MB +- 384.2 kB -> 27.2 MB +- 21.3 kB: 2.58x
slower (+158%)
- logging_simple: 10028.4 kB +- 371.2 kB -> 22.2 MB +- 24.9 kB: 2.27x
slower (+127%)
- regex_dna: 13.3 MB +- 19.1 kB -> 27.0 MB +- 12.1 kB: 2.02x slower (+102%)
- json_dumps: 8351.8 kB +- 19.8 kB -> 15.2 MB +- 18.0 kB: 1.87x slower (+87%)
- regex_v8: 8434.6 kB +- 20.9 kB -> 14.4 MB +- 11.0 kB: 1.75x slower (+75%)
- unpack_sequence: 7521.0 kB +- 17.0 kB -> 9980.8 kB +- 24.7 kB: 1.33x
slower (+33%)
- hexiom: 7412.2 kB +- 19.0 kB -> 9307.4 kB +- 8004 bytes: 1.26x slower (+26%)
- xml_etree_process: 12.2 MB +- 26.3 kB -> 15.0 MB +- 28.9 kB: 1.23x
slower (+23%)
- genshi_text: 10.2 MB +- 24.0 kB -> 12.5 MB +- 24.8 kB: 1.22x slower (+22%)
- crypto_pyaes: 7602.2 kB +- 35.7 kB -> 9242.8 kB +- 7873 bytes: 1.22x
slower (+22%)
- tornado_http: 24.9 MB +- 72.1 kB -> 30.1 MB +- 33.0 kB: 1.21x slower (+21%)
- chameleon: 15.8 MB +- 24.5 kB -> 19.1 MB +- 23.4 kB: 1.21x slower (+21%)
- genshi_xml: 10.9 MB +- 24.0 kB -> 12.9 MB +- 19.6 kB: 1.18x slower (+18%)
- go: 8662.6 kB +- 16.4 kB -> 10082.8 kB +- 26.2 kB: 1.16x slower (+16%)
- pathlib: 8863.6 kB +- 30.2 kB -> 10229.8 kB +- 19.4 kB: 1.15x slower (+15%)
- scimark_fft: 7473.4 kB +- 14.4 kB -> 8606.0 kB +- 28.6 kB: 1.15x slower (+15%)
- scimark_lu: 7463.2 kB +- 15.1 kB -> 8569.8 kB +- 28.6 kB: 1.15x slower (+15%)
- pidigits: 7380.2 kB +- 20.0 kB -> 8436.0 kB +- 24.2 kB: 1.14x slower (+14%)
- scimark_monte_carlo: 7354.4 kB +- 18.2 kB -> 8398.8 kB +- 27.0 kB:
1.14x slower (+14%)
- scimark_sparse_mat_mult: 7889.8 kB +- 20.1 kB -> 9006.2 kB +- 29.4
kB: 1.14x slower (+14%)
- scimark_sor: 7377.2 kB +- 18.9 kB -> 8402.0 kB +- 29.0 kB: 1.14x slower (+14%)
- chaos: 7693.0 kB +- 33.0 kB -> 8747.6 kB +- 10.5 kB: 1.14x slower (+14%)
- richards: 7364.2 kB +- 29.8 kB -> 8331.4 kB +- 20.2 kB: 1.13x slower (+13%)
- raytrace: 7696.0 kB +- 30.3 kB -> 8695.4 kB +- 30.0 kB: 1.13x slower (+13%)
- sqlite_synth: 8799.2 kB +- 25.5 kB -> 9937.4 kB +- 27.1 kB: 1.13x
slower (+13%)
- logging_silent: 7533.8 kB +- 32.0 kB -> 8488.2 kB +- 25.1 kB: 1.13x
slower (+13%)
- json_loads: 7317.8 kB +- 22.7 kB -> 8215.2 kB +- 21.5 kB: 1.12x slower (+12%)
- unpickle_list: 7513.4 kB +- 9790 bytes -> 8420.6 kB +- 25.6 kB:
1.12x slower (+12%)
- unpickle: 7519.8 kB +- 11.4 kB -> 8425.4 kB +- 27.1 kB: 1.12x slower (+12%)
- fannkuch: 7170.0 kB +- 14.9 kB -> 8033.0 kB +- 22.5 kB: 1.12x slower (+12%)
- pickle_list: 7514.6 kB +- 18.2 kB -> 8414.6 kB +- 24.0 kB: 1.12x slower (+12%)
- telco: 7685.2 kB +- 15.0 kB -> 8598.2 kB +- 17.6 kB: 1.12x slower (+12%)
- nbody: 7214.8 kB +- 10.7 kB -> 8070.2 kB +- 19.5 kB: 1.12x slower (+12%)
- pickle: 7523.2 kB +- 12.4 kB -> 8415.0 kB +- 21.0 kB: 1.12x slower (+12%)
- 2to3: 7171.2 kB +- 35.8 kB -> 8016.4 kB +- 21.7 kB: 1.12x slower (+12%)
- nqueens: 7425.2 kB +- 21.8 kB -> 8296.8 kB +- 25.5 kB: 1.12x slower (+12%)
- spectral_norm: 7212.6 kB +- 19.6 kB -> 8052.8 kB +- 18.4 kB: 1.12x
slower (+12%)
- regex_compile: 8538.0 kB +- 21.0 kB -> 9528.6 kB +- 22.1 kB: 1.12x
slower (+12%)
- pickle_pure_python: 7559.8 kB +- 19.4 kB -> 8430.0 kB +- 25.6 kB:
1.12x slower (+12%)
- unpickle_pure_python: 7545.4 kB +- 9233 bytes -> 8413.0 kB +- 15.6
kB: 1.11x slower (+11%)
- float: 23.9 MB +- 22.5 kB -> 26.6 MB +- 19.7 kB: 1.11x slower (+11%)
- sqlalchemy_imperative: 18.2 MB +- 46.2 kB -> 20.2 MB +- 36.5 kB:
1.11x slower (+11%)
- regex_effbot: 7910.8 kB +- 15.1 kB -> 8804.8 kB +- 20.9 kB: 1.11x
slower (+11%)
- pickle_dict: 7563.4 kB +- 15.3 kB -> 8415.2 kB +- 19.3 kB: 1.11x slower (+11%)
- sqlalchemy_declarative: 18.9 MB +- 40.2 kB -> 21.0 MB +- 26.4 kB:
1.11x slower (+11%)
- xml_etree_parse: 11.8 MB +- 12.6 kB -> 13.0 MB +- 16.3 kB: 1.11x slower (+11%)
- html5lib: 20.1 MB +- 44.9 kB -> 22.2 MB +- 46.6 kB: 1.10x slower (+10%)
- xml_etree_iterparse: 12.0 MB +- 26.5 kB -> 13.2 MB +- 31.3 kB: 1.10x
slower (+10%)
- sympy_integrate: 36.4 MB +- 26.7 kB -> 40.0 MB +- 33.2 kB: 1.10x slower (+10%)
- sympy_str: 37.2 MB +- 28.4 kB -> 40.7 MB +- 26.6 kB: 1.10x slower (+10%)
- sympy_expand: 36.2 MB +- 19.9 kB -> 39.7 MB +- 25.1 kB: 1.09x slower (+9%)
- mako: 15.3 MB +- 19.1 kB -> 16.7 MB +- 25.4 kB: 1.09x slower (+9%)
- django_template: 19.3 MB +- 14.9 kB -> 21.0 MB +- 14.6 kB: 1.09x slower (+9%)
- xml_etree_generate: 12.3 MB +- 39.5 kB -> 13.3 MB +- 26.9 kB: 1.08x
slower (+8%)
- deltablue: 8918.0 kB +- 19.8 kB -> 9615.8 kB +- 12.5 kB: 1.08x slower (+8%)
- dulwich_log: 12.2 MB +- 102.9 kB -> 13.1 MB +- 26.6 kB: 1.08x slower (+8%)
- meteor_contest: 9296.0 kB +- 11.9 kB -> 9996.8 kB +- 20.7 kB: 1.08x
slower (+8%)
- sympy_sum: 62.2 MB +- 20.8 kB -> 66.5 MB +- 21.1 kB: 1.07x slower (+7%)
- python_startup: 7946.6 kB +-

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Antoine Pitrou 
On Thu, 4 Jul 2019 23:32:55 +0900
Inada Naoki  wrote:
> On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou  wrote:
> >
> > Ah, interesting.  Were you able to measure the memory footprint as well?
> >  
> 
> Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
> benchmarks.  I will look it later.

Ah, indeed, MADV_FREE will make it complicated to measure actual memory
usage :-/

Regards

Antoine.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/46QXQLQWHB4ASSBL5LB5QXJIYJLTDY77/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Tim Peters 
[Antoine Pitrou ]
>> Ah, interesting.  Were you able to measure the memory footprint as well?

[Inada Naoki ]
> Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
> benchmarks.  I will look it later.
>
> ```
> $ ./python  -m pyperf compare_to pymalloc-mem.json mimalloc-mem.json -G
> Slower (60):
> - logging_format: 10.6 MB +- 384.2 kB -> 27.2 MB +- 21.3 kB: 2.58x
> slower (+158%)
> ...

Could you say more about what's being measured here?  Like, if this is
on Linux, is it reporting RSS?  VSS?  Something else?

mimalloc is "most like" obmalloc among those I've looked at in recent
weeks.  I noted before that its pools (they call them "pages") and
arenas (called "segments") are at least 16x larger than obmalloc uses
(64 KiB minimum pool/page size, and 4 MiB minimum arena/segment size,
in mimalloc).

Like all "modern" 64-bit allocators, it cares little about reserving
largish blobs of address space, so I'd _expect_ Linuxy VSS to zoom.
But it also releases (in some sense, ;like MADV_FREE) physical RAM
back to the system at a granularity far smaller than arena'segment.

At an extreme, the SuperMalloc I linked to earlier reserves a 512 MiB
vector at the start, so no program linking to that can consume less
than half a gig of address space.  But it only expects to _use_ a few
4 KiB OS pages out of that.  mimalloc doesn't do anything anywhere
near _that_ gonzo (& since mimalloc comes out of Microsoft, it never
will - "total virtual memory" on Windows is a system-wide resource,
limited to the sum of physical RAM + pagefile size - no "overcommit"
is allowed).
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ES3BFCBXS7N56XGUHHSOPHRT3UAEGKVA/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Victor Stinner 
I guess that INADA-san used pyperformance --track-memory.

pyperf --track-memory doc:
"--track-memory: get the memory peak usage. it is less accurate than
tracemalloc, but has a lower overhead. On Linux, compute the sum of
Private_Clean and Private_Dirty memory mappings of /proc/self/smaps.
On Windows, get PeakPagefileUsage of GetProcessMemoryInfo() (of the
current process): the peak value of the Commit Charge during the
lifetime of this process."
https://pyperf.readthedocs.io/en/latest/runner.html#misc

On Linux, pyperf uses read_smap_file() of pyperf._memory:
https://github.com/vstinner/pyperf/blob/master/pyperf/_memory.py

# Code to parse Linux /proc/%d/smaps files.
#
# See http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html for
# a quick introduction to smaps.
#
# Need Linux 2.6.16 or newer.
def read_smap_file():
total = 0
fp = open(proc_path("self/smaps"), "rb")
with fp:
for line in fp:
# Include both Private_Clean and Private_Dirty sections.
line = line.rstrip()
if line.startswith(b"Private_") and line.endswith(b'kB'):
parts = line.split()
total += int(parts[1]) * 1024
return total

It spawns a thread which reads /proc/self/smaps every milliseconds and
then report the *maximum*.

Victor

Le jeu. 4 juil. 2019 à 17:12, Tim Peters  a écrit :
>
> [Antoine Pitrou ]
> >> Ah, interesting.  Were you able to measure the memory footprint as well?
>
> [Inada Naoki ]
> > Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
> > benchmarks.  I will look it later.
> >
> > ```
> > $ ./python  -m pyperf compare_to pymalloc-mem.json mimalloc-mem.json -G
> > Slower (60):
> > - logging_format: 10.6 MB +- 384.2 kB -> 27.2 MB +- 21.3 kB: 2.58x
> > slower (+158%)
> > ...
>
> Could you say more about what's being measured here?  Like, if this is
> on Linux, is it reporting RSS?  VSS?  Something else?
>
> mimalloc is "most like" obmalloc among those I've looked at in recent
> weeks.  I noted before that its pools (they call them "pages") and
> arenas (called "segments") are at least 16x larger than obmalloc uses
> (64 KiB minimum pool/page size, and 4 MiB minimum arena/segment size,
> in mimalloc).
>
> Like all "modern" 64-bit allocators, it cares little about reserving
> largish blobs of address space, so I'd _expect_ Linuxy VSS to zoom.
> But it also releases (in some sense, ;like MADV_FREE) physical RAM
> back to the system at a granularity far smaller than arena'segment.
>
> At an extreme, the SuperMalloc I linked to earlier reserves a 512 MiB
> vector at the start, so no program linking to that can consume less
> than half a gig of address space.  But it only expects to _use_ a few
> 4 KiB OS pages out of that.  mimalloc doesn't do anything anywhere
> near _that_ gonzo (& since mimalloc comes out of Microsoft, it never
> will - "total virtual memory" on Windows is a system-wide resource,
> limited to the sum of physical RAM + pagefile size - no "overcommit"
> is allowed).
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/ES3BFCBXS7N56XGUHHSOPHRT3UAEGKVA/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/HF4UIZP5J3KKWQMLCHKJD3G6YZLHWWBE/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Inada Naoki 
I found calibrated loop count is not stable so memory usage is very different
in some benchmarks.
Especially, RAM usage of logging benchmark is very relating to loop count:

$ PYTHONMALLOC=malloc LD_PRELOAD=$HOME/local/lib/libmimalloc.so
./python bm_logging.py simple --track-memory --fast --inherit-environ
PYTHONMALLOC,LD_PRELOAD -v
Run 1: calibrate the number of loops: 512
- calibrate 1: 12.7 MB (loops: 512)
Calibration: 1 warmup, 512 loops
Run 2: 0 warmups, 1 value, 512 loops
- value 1: 12.9 MB
Run 3: 0 warmups, 1 value, 512 loops
- value 1: 12.9 MB
...

$ PYTHONMALLOC=malloc LD_PRELOAD=$HOME/local/lib/libmimalloc.so
./python bm_logging.py simple --track-memory --fast --inherit-environ
PYTHONMALLOC,LD_PRELOAD -v -l1024
Run 1: 0 warmups, 1 value, 1024 loops
- value 1: 21.4 MB
Run 2: 0 warmups, 1 value, 1024 loops
- value 1: 21.4 MB
Run 3: 0 warmups, 1 value, 1024 loops
- value 1: 21.4 MB
...

-- 
Inada Naoki  
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QBXLRFXDD5TLLDATV2PWE2QNLLDWRVXY/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

2019-07-04 Thread Tim Peters 
[Victor Stinner ]
> I guess that INADA-san used pyperformance --track-memory.
>
> pyperf --track-memory doc:
> "--track-memory: get the memory peak usage. it is less accurate than
> tracemalloc, but has a lower overhead. On Linux, compute the sum of
> Private_Clean and Private_Dirty memory mappings of /proc/self/smaps.
> ...

So I'll take that as meaning essentially that it's reporting what RSS
would report if it ignored shared pages (so peak # of private pages
actually backed by physical RAM).

Clear as mud how MADV_FREE affects that.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6H7HP6TXKGZBIPVNBTLULGYEDFJKVFCQ/

[Python-Dev] Re: Change SystemError to NOT inherit from Exception

2019-07-04 Thread Brett Cannon 
Jeroen Demeyer wrote:
> On 2019-07-02 23:29, Brett Cannon wrote:
> > But two, this would be a semantic shift of what
> > classes directly inherit from BaseException.
> > It depends how you interpret that. I always interpreted classes 
> inheriting directly from BaseException as exceptions that you almost 
> never want to catch in an "except Exception" block.

As co-author of PEP 352 I can tell you the intent is the one I laid out. ;) 
(See https://www.python.org/dev/peps/pep-0352/#exception-hierarchy-changes.)

> > Adding SystemError to that list would
> > make it a unique error condition that doesn't inherit from Exception.
> > I would argue that the various exception classes inheriting from 
> BaseException are already quite unique: a KeyboardInterrupt is very 
> different from a GeneratorExit for example.

Depends on your view. To me they are both control flow; one is for generators, 
one is for whole applications, but the point of both is to bubble up a control 
flow shift as appropriate and not be caught by `except Exception` blocks.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/EQHW2CKD4WDKZWQBB3BFFYJP2N2TYSXB/

[Python-Dev] [RELEASE] Python 3.8.0b2 is now available for testing

2019-07-04 Thread Łukasz Langa 
After a few days of delay, but somewhat cutely timed with the US Independence 
Day, I present you Python 3.8.0b2:

https://www.python.org/downloads/release/python-380b2/ 


This release is the second of four 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. The next pre-release of Python 3.8 will be 3.8.0b3, currently 
scheduled for 2019-07-29.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.8 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 (2019-09-30). Our goal is have no ABI changes after beta 3 and 
no code changes after 3.8.0rc1, the release candidate. To achieve that, it will 
be extremely important to get as much exposure for 3.8 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.

No more non-bugfixes allowed on the “3.8” branch

The time has come, team. Please help make Python 3.8 as stable as possible and 
keep all features not currently landed for Python 3.9. Don’t fret, it’ll come 
faster than you think.


- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IOPMOE7BAZMGBPXLTEXGUIQ53ZIUU3KJ/