Mailman 3 June 2019 - Python-Dev

v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())
by Phil Thompson June 23, 2019

June 23, 2019

The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is that PyQt is built using the stable ABI and a single wheel is supposed to support all versions of Python starting with v3.5. On the assumption (perhaps naive) that using the stable ABI would avoid future compatibility issues, the existing PyPI wheels have long been tagged with cp38. Was this issue considered at the time? What is the official view? Thanks, Phil

3 3

Preserve keyword argument order in unittest.mock call repr output
by Karthikeyan Singaravelan June 22, 2019

June 22, 2019

From Python 3.6 the order of keyword arguments to a function is preserved. In https://bugs.python.org/issue21256 the order of keyword arguments for unittest.mock's repr were sorted to return deterministic output for usage in doctest and other use cases. This currently gives little inconsistent output where the keyword argument order in below mock call is (b=2, a=1) but it's sorted in the error message and mock_calls list to give (a=1, b=2). I have opened https://bugs.python.org/issue37212 to … [View More]

2 1

Summary of Python tracker Issues
by Python tracker June 21, 2019

June 21, 2019

ACTIVITY SUMMARY (2019-06-14 - 2019-06-21) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7038 (+16) closed 42078 (+65) total 49116 (+81) Open issues with patches: 2828 Issues opened (63) ================== #24214: UTF-8 incremental decoder doesn't support surrogatepass correc https://bugs.python.org/issue24214 reopened by vstinner #32846: … [View More]

1 0

_Py_Identifier should support non-ASCII string?
by Inada Naoki June 21, 2019

June 21, 2019

Hi, all. Both of PyUnicdoe_FromString() and _Py_Identifier are supporting UTF-8 for now. We can not change PyUnicode_FromString() for backward compatibility, so we have _PyUnicode_FromASCII instead. But _Py_Identifier is still private. And non-ASCII identifier is not practical. Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII? Regards, -- Inada Naoki <songofacandy(a)gmail.com>

6 10

Who uses libpython38.a on Windows?
by Steve Dower June 20, 2019

June 20, 2019

One of the most annoying steps in building the Windows installers is generating the libpython38.a file. It's annoying, because it requires having "generic enough" MinGW tools to ensure that the file is compatible with whatever version of MinGW might be trying to build against the regular Windows distribution. I would like to stop shipping this file in 3.8 and instead put the steps into the docs to show people how to generate them themselves (with the correct version of their tools): … [View More]

3 4

why is not 64-bit installer the default download link for Windows?
by Cosimo Lupo June 19, 2019

June 19, 2019

If one goes to httWhps://www.python.org/downloads <https://www.python.org/downloads> from a Windows browser, the default download URL is for the 32-bit installer instead of the 64-bit one. I wonder why is this still the case? Shouldn't we encourage new Windows users (who may not even know the distinction between the two architectures) to use the 64-bit version of Python, since most likely they can? If this is not the correct forum for this, please let me know where I can direct my … [View More]

14 22

radix tree arena map for obmalloc
by Neil Schemenauer June 19, 2019

June 19, 2019

I've been working on this idea for a couple of days. Tim Peters has being helping me out and I think it has come far enough to get some more feedback. It is not yet a good replacement for the current address_in_range() test. However, performance wise, it is very close. Tim figures we are not done optimizing it yet so maybe it will get better. Code is available on my github branch: https://github.com/nascheme/cpython/tree/obmalloc_radix_tree Tim's "obmalloc-big-pools" is what I have … [View More]been comparing it to. It seems 8 KB pools are faster than 4 KB. I applied Tim's arena trashing fix (bpo-37257) to both branches. Some rough (--fast) pyperformance benchmark results are below. +-------------------------+---------------------+-----------------------------+ | Benchmark | obmalloc-big-pools | obmalloc_radix | +=========================+=====================+=============================+ | crypto_pyaes | 168 ms | 170 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | hexiom | 13.7 ms | 13.6 ms: 1.01x faster (-1%) | +-------------------------+---------------------+-----------------------------+ | json_dumps | 15.9 ms | 15.6 ms: 1.02x faster (-2%) | +-------------------------+---------------------+-----------------------------+ | json_loads | 36.9 us | 37.1 us: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | meteor_contest | 141 ms | 139 ms: 1.02x faster (-2%) | +-------------------------+---------------------+-----------------------------+ | nqueens | 137 ms | 140 ms: 1.02x slower (+2%) | +-------------------------+---------------------+-----------------------------+ | pickle_dict | 26.2 us | 25.9 us: 1.01x faster (-1%) | +-------------------------+---------------------+-----------------------------+ | pickle_list | 3.91 us | 3.94 us: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | python_startup_no_site | 8.00 ms | 7.78 ms: 1.03x faster (-3%) | +-------------------------+---------------------+-----------------------------+ | regex_dna | 246 ms | 241 ms: 1.02x faster (-2%) | +-------------------------+---------------------+-----------------------------+ | regex_v8 | 29.6 ms | 30.0 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | richards | 93.9 ms | 92.7 ms: 1.01x faster (-1%) | +-------------------------+---------------------+-----------------------------+ | scimark_fft | 525 ms | 531 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | scimark_sparse_mat_mult | 6.32 ms | 6.24 ms: 1.01x faster (-1%) | +-------------------------+---------------------+-----------------------------+ | spectral_norm | 195 ms | 198 ms: 1.02x slower (+2%) | +-------------------------+---------------------+-----------------------------+ | sqlalchemy_imperative | 49.5 ms | 50.5 ms: 1.02x slower (+2%) | +-------------------------+---------------------+-----------------------------+ | sympy_expand | 691 ms | 695 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | unpickle_list | 5.09 us | 5.32 us: 1.04x slower (+4%) | +-------------------------+---------------------+-----------------------------+ | xml_etree_parse | 213 ms | 215 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | xml_etree_generate | 134 ms | 136 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ | xml_etree_process | 103 ms | 104 ms: 1.01x slower (+1%) | +-------------------------+---------------------+-----------------------------+ Not significant (34): 2to3; chameleon; chaos; deltablue; django_template; dulwich_log; fannkuch; float; go; html5lib; logging_format; logging_silent; logging_simple; mako; nbody; pathlib; pickle; pidigits; python_startup; raytrace; regex_compile; regex_effbot; scimark_lu; scimark_monte_carlo; scimark_sor; sqlalchemy_declarative; sqlite_synth; sympy_integrate; sympy_sum; sympy_str; telco; unpack_sequence; unpickle; xml_etree_iterparse [View Less]

5 28

How to (best) organize platform dependent blocks of Python code
by Michael June 17, 2019

June 17, 2019

CONCERN: How to organize platform dependent blocks of code POLICY/RECOMMENDATION: (today) seems to be: arbitrary, although sys.platform, seems to be the favorite. * I, as 'python-consumer' was very surprised when I learned that sys.platform is "set" when Python is built - and that platform.system() was the call to make to get the run-time value. And, of course, they answered the "question" - what platform am I 'running' on, quite differently. * There are several - to many - issues in the past … [View More]where, in one form or another, sys.platform, platform.system(), os.name, and I expect more but cannot think of them atm - used throughout all of Python. * A Python expert (e.g., core-devs) may understand - inherently - when each of these is the best option. As an 'experienced-novice' I am surprised that a "build-time constant" seems to be preference. This preference is not new (maybe platform.system() is "new", and os.name() too broad). * Zooming back to 2012 when "linux3" first appeared this became apparent that the build-time constant of linux2 was making 'things' difficult when the packaging was built on linux3 but running with applications developed on linux2 systems - and early on the move was made to just have "linux" returned (issue13236). For years the recommendation was (and maybe is?) to use sys.platform.startswith('linux'). * In between there have been other discussions - and the concern remains unresolved. * Personally, not "satisfied", and reluctant to "give up", or "ignore" something that continues to come up - I opened issue36624 to serve as a discussion point and worked through what would be needed to have "most" platforms testing against a CONSTANT defined in test.support - to provide an example of what it could look like. * As a non-expert - I EXPECT guidance from the people who know best why and when the different approaches are preferred. (I am hoping for something better than 'historical' or 'personal preferences'). * So, using this mail to python-dev to re-open the discussion - my suggested focus is NOT look at specific (test) code as it is now, but FOCUS from a perspective of Python3 and beyond - answering the 'concern' how should 'platform dependencies' be organized'. In other words, do not focus on an exception (although "listing" perceived exceptions will be helpful). Focus on "policy" aka "good practice". With that as a starting point discussing, understanding and validating exceptions to the guidelines will be much easier. -- as a 'mentoring' project - I am willing to do as much as I am able to "implement" something. My first PR was a 'stab in the dark' and I have already learned "other things" such as how to git rebase (read merge!). The discussion in the issue-tracker and PR conversation indicate to me that documentation of different approaches to organizing code dependencies is vital. And that it is not easily available. Devguide is one area - but 'core' documentation is more important imho - I read, and compare, the Python documentation much much more often than the devguide docs. Sincerely, Michael [View Less]

3 2

Summary of Python tracker Issues
by Python tracker June 14, 2019

June 14, 2019

ACTIVITY SUMMARY (2019-06-07 - 2019-06-14) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7022 (+15) closed 42013 (+70) total 49035 (+85) Open issues with patches: 2826 Issues opened (54) ================== #36607: asyncio.all_tasks() crashes if asyncio is used in multiple thr https://bugs.python.org/issue36607 reopened by asvetlov #36888: … [View More]

1 0

Expected stability of PyCode_New() and types.CodeType() signatures
by Petr Viktorin June 13, 2019

June 13, 2019

Hello, PEP 570 (Positional-Only Parameters) changed the signatures of PyCode_New() and types.CodeType(), adding a new argument for "posargcount". Our policy for such changes seems to be fragmented tribal knowledge. I'm writing to check if my understanding is reasonable, so I can apply it and document it explicitly. There is a surprisingly large ecosystem of tools that create code objects. The expectation seems to be that these tools will need to be adapted for each minor version of Python. … [View More]

10 19