date:20220112



Dong-hee Na  added the comment:

@sobolevn

Do you want to close it?
Cleaning up the issue is one of the duties of triage members :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Change by Dong-hee Na :


--
versions: +Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Dong-hee Na  added the comment:

@gvanrossum

Ah okay, Looks like bpo-46195 is the root of this issue.
In this case, backporting is reasonable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default


Guido van Rossum  added the comment:

Wasn’t the fix for it also backported?

(Weird that the test wasn’t part of the fix.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46279] [docs] Minor information-ordering issue in main doc

2022-01-12 Thread FeRD (Frank Dana)



FeRD (Frank Dana)  added the comment:

Readding Tal to the nosy list, since my previous comment was inadvertently 
accompanied by an eviction! (Sorry about that.)

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()



Change by Raymond Hettinger :


Added file: https://bugs.python.org/file50559/comb_pole2.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()



Raymond Hettinger  added the comment:

def comb64(n, k):
'comb(n, k) in multiplicative group modulo 64-bits'
return (F[n] * Finv[k] * Finv[n-k] & (2**64-1)) << (S[n] - S[k] - S[n - k])

def comb_iterative(n, k):
'Straight multiply and divide when k is small.'
result = 1
for r in range(1, k+1):
result *= n - r + 1
result //= r
return result

def C(n, k):
k = min(k, n - k)
if k == 0: return 1
if k == 1: return n
if k < len(k2n) and n <= k2n[k]:  return comb64(n, k) # 64-bit fast case
if k == FixedJ and n <= Jlim:  return KnownComb[n]# Precomputed diagonal
if k < 10: return comb_iterative(n, k)# Non-recursive for 
small k  
j = FixedJ if k > FixedJ and n <= Jlim else k // 2
return C(n, j) * C(n-j, k-j) // C(k, j)   # Recursive case

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46363] Two typos in verions 3.7 document translation of zh_CN

2022-01-12 Thread perlang


New submission from perlang :

In this URL,
https://docs.python.org/zh-cn/3.7/library/ctypes.html

There are two typos of '回掉' , the correct should be '回调'(means callback) I 
think.

Best Regards,

perlang

--
assignee: docs@python
components: Documentation
messages: 410459
nosy: docs@python, perlang
priority: normal
severity: normal
status: open
title: Two typos in verions 3.7 document translation of zh_CN
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46287] UNC path normalisation issues on Windows

2022-01-12 Thread neonene



neonene  added the comment:

> PathCchSkipRoot() doesn't recognize forward slash as a path separator,
 
I opened issue46362 and PR30571 about the mentioned abspath() behaviors.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46362] os.path.abspath() needs more normalization on Windows

2022-01-12 Thread neonene



Change by neonene :


--
keywords: +patch
pull_requests: +28772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30571

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Dong-hee Na  added the comment:

When I take a look at previous PRs, most of adding test cases were not 
backported.
The backported cases were triggered by bug issues.
But let's pass this case as an exceptional case.

--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46362] os.path.abspath() needs more normalization on Windows

2022-01-12 Thread neonene



New submission from neonene :

3.11a3+ introduced the C version of abspath(), which shows incompletely 
normalized absolute path (see msg410068):

>>> os.path.abspath(r'\\spam\\eggs. . .')
'spameggs. . .'
>>> os.path.abspath('C:\\spam. . .')
'C:\\spam. . .'
>>> os.path.abspath('C:\\nul')
'C:\\nul'

The design is efficient on startup with getpath_abspath(), but 
ntpath.abspath()'s result after startup should be more normalized.

--
components: Windows
messages: 410456
nosy: neonene, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.abspath() needs more normalization on Windows
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

2022-01-12 Thread Jack O'Connor


Jack O'Connor  added the comment:

Yeah by intrinsics I mean stuff like _mm256_add_epi32(). All of that stuff is 
in these vendored files:

blake3_avx2.c
blake3_avx512.c
blake3_neon.c
blake3_sse2.c
blake3_sse41.c

Also to Michał's question above, I'm not necessarily opposed to publishing 
something like "blake3-c" on PyPI once things stabilize. Even if we get BLAKE3 
into hashlib in 3.11, PyPI modules will be useful to folks running older 
versions, and not everyone wants to install the Rust toolchain.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

2022-01-12 Thread Larry Hastings



Larry Hastings  added the comment:

I assume by "intrinsics" you mean using the GCC SIMD stuff, not like inlining 
memcpy() or something.  My assumption is yes, that's fine, we appear to already 
be using them for BLAKE2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

2022-01-12 Thread Jack O'Connor



Jack O'Connor  added the comment:

> As a first pass I say we merge the reference C implementation.

Do you mean portable-only C code, or portable + intrinsics? If the assembly 
files are out, I'd advocate for the latter. The intrinsics implementations are 
nearly as fast as the assembly code, and both of those are several times faster 
than the portable code. You can test this configuration with my current 
setup.py by setting the env var FORCE_INTRINSICS=1.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

2022-01-12 Thread Larry Hastings



Larry Hastings  added the comment:

> In setup.py I assume that the target platform of the build is the same as the 
> current interpreter's platform.

If this is included in CPython, it won't be using setup.py, so this isn't a 
concern.

I don't think there's a way to use setup.py to cross-compile, so I'm not sure 
this ever was a concern.


> - Compiling assembly files.

AFAICT Python currently ships exactly one assembly file, 
"Modules/_decimal/libmpdec/vcdiv64.asm", which is only built on Windows.  It 
would be a brave new world of configure.ac hacking to build assembly language 
files on POSIX platforms.  As a first pass I say we merge the reference C 
implementation.  Maybe someday we could add the SIMD assembly language 
stuff--or use the one built in to OpenSSL (if they ever add BLAKE3).

> I assume we don't want to check in the .obj files?

Correct, we don't.

> - blake3module.c contains an awful lot of gotos to handle allocation failure 
> cases.

Works for me, please keep it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

2022-01-12 Thread Jack O'Connor



Jack O'Connor  added the comment:

I was about to say the only missing feature was docstrings, but then I realized 
I hadn't included releasing the GIL. I've added that and pushed an update just 
now. Fingers crossed there's nothing else I've missed. I think it's in 
reasonably good shape, and I'd like to propose it for inclusion in 3.11.

However, I'm not very experienced with setup.py or the Python C API, so I might 
not be the best judge of shape. Here are some highlights for reviewers, where I 
think the implementation (mostly the build) could be shaky:

- Platform detection. In setup.py I assume that the target platform of the 
build is the same as the current interpreter's platform. So for example, if the 
current interpreter has sys.maxsize==2**31-1, I assume we're compiling for 
32-bit. This clearly doesn't allow for any sort of cross-compilation, and in 
general I need feedback about whether there's a more correct way to obtain the 
target platform.

- Compiling assembly files. On Unix this is easy, because we can supply *.S 
files as `extra_objects` and GCC/Clang will do the right thing. But on Windows 
this isn't easy. Currently I shell out to vswhere.exe, ask it for the path to 
the latest version of the ml64.exe assembler, and then shell out to that to 
build .obj files. Then I pass those assembled .obj files as `extra_objects`. 
This feels awfully manual, and there's a good chance I've missed some 
better-supported way to do it. I assume we don't want to check in the .obj 
files?

- Does Python support the GNU ABI on Windows? We have assembly files for this 
in vendor/, but I'm not currently building them.

- Compiling intrinsics files for 32-bit x86. In this case, I create a 
`ccompiler.new_compiler()` for each intrinsics file, so that I can set the 
appropriate flags for each. This is relatively clean, but it leads to things 
getting rebuilt every single time, rather than participating in `setup.py 
build` caching. Maybe nobody cares about this, but again it makes me think 
there might be a better-supported way to do it.

- blake3module.c contains an awful lot of gotos to handle allocation failure 
cases. Is this still considered a best practice? These are bug-prone, and I'm 
not sure how to test them.

- Existing hashlib implementations include an optimization where they avoid 
allocating an internal mutex until they see a long input and want to release 
the GIL. As a quirky side effect of this, they handle allocation failures for 
that mutex by falling back to the do-not-release-the-GIL codepath. That feels 
kind of complicated to me, and in my code I'm always allocating the mutex 
during initialization. This doesn't seem to make much of a performance 
difference when I measure it, but there might be use cases I haven't considered.

Here are some other API details that might be worth bikeshedding:

- The `max_threads` parameter is currently defined to take a special value, 
`blake3.AUTO`, to indicate that the implementation may use as many threads as 
it likes. (The C implementation doesn't include multithreading support, but 
it's API-compatible with the Rust implementation.) `blake3.AUTO` is currently a 
class attribute equal to -1. We may want to bikeshed this name or propose some 
other representation.

- BLAKE3 has three modes: regular hashing, keyed hashing, and key derivation. 
The keyed hashing mode takes a 32-byte key, and the key derivation mode takes a 
context string. Calling the 32-byte key `key` seems good. Calling the context 
string `context` seems less good. Larry has pointed out before that lots of 
random things are called `context`, and readers might not understand what 
they're seeing. I currently call it `derive_key_context` instead, but we could 
bikeshed this.

- I check `itemsize` on input Py_buffers and throw an exception if it's 
anything other than 1. My test suite exercises this, see 
`test_int_array_fails`. However, some (all?) standard hashes don't do this 
check. For example:

>>> from hashlib import sha256
>>> import array
>>> a = array.array("i", [255])
>>> sha256(a).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'
>>> sha256(bytes([0xff, 0, 0, 0])).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'

Here we can see sha256() hashing an array of int. On my machine, an int is 4 
little-endian bytes, but of course this sort of thing isn't portable. The same 
array will result in a different SHA-256 output on a big-endian machine, or on 
a machine with ints of a different size. This seems undesirable, and I'm 
surprised that hashlib allows it. However, if there's some known compatibility 
reason why we have to allow it, I could remove this check.

--
versions: +Python 3.11 -Python 3.10

___
Python tracker 

___
___

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



miss-islington  added the comment:


New changeset d9101c4e49dc29f21319493818130ad5468402a2 by Miss Islington (bot) 
in branch '3.9':
bpo-46345: Add a test case for implicit `Optional` class attribute (GH-30535)
https://github.com/python/cpython/commit/d9101c4e49dc29f21319493818130ad5468402a2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



miss-islington  added the comment:


New changeset a468866a67d83a24e3a3c3a0070129773d28bbd9 by Miss Islington (bot) 
in branch '3.10':
bpo-46345: Add a test case for implicit `Optional` class attribute (GH-30535)
https://github.com/python/cpython/commit/a468866a67d83a24e3a3c3a0070129773d28bbd9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()



Raymond Hettinger  added the comment:

Okay, will set a cap on the n where a fixedj is used.  Also, making a direct 
computation for k<20 is promising.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()



Change by Raymond Hettinger :


--
Removed message: https://bugs.python.org/msg410440

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5396] os.read not handling O_DIRECT flag

2022-01-12 Thread Jakub Wilk



Change by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



STINNER Victor  added the comment:

I wrote 3 scripts to reproduce the bug in a more reliable way. So I just have 
to type "bisect" and it runs the test 12 times.

(1) bisect.bat:
---
@"C:\vstinner\python\3.9\PCbuild\amd64\python_d.exe" bisect.py
---


(2) bisect.py:
---
import subprocess
import os
import sys

BISECT = False

def run(*args):
print("+ ", ' '.join(args))
env = dict(os.environ)
env['PYTHONFAULTHANDLER'] = '1'
proc = subprocess.run(args, env=env)
exitcode = proc.returncode
if exitcode:
print()
print(f"COMMAND FAILED: {exitcode}")
if BISECT:
print()
print("type: git bisect bad")
sys.exit(exitcode)

python = sys.executable
#script = "win_py399_crash_reproducer.py"
script = "bug.py"
nrun = 12
for i in range(1, nrun+1):
print(f"Run #{i}/{nrun}")
if i % 2:
run(python, script)
else:
run(python, "-X", "dev", script)

if BISECT:
print()
print("Not reproduced")
print()
run("git", "checkout", ".")
run("git", "bisect", "good")
---


(3) win_py399_crash_reproducer.py (import "_sre"):
---
# When this program is run on windows using python 3.9.9 it crashes about 50%
# of the time.

import _testcapi
import threading

code = """
import _sre
print("exit subinterpreter")
"""

def doIt():
_testcapi.run_in_subinterp(code)

tt=[]

for i in range(16):
t = threading.Thread(target=doIt)
t.start()
tt.append(t)

for t in tt:
t.join()
print("exit main")
---


Example:
---
vstinner@DESKTOP-DK7VBIL C:\vstinner\python\3.9>bisect
Run #1/12
+  C:\vstinner\python\3.9\PCbuild\amd64\python_d.exe bug.py
Run #2/12
+  C:\vstinner\python\3.9\PCbuild\amd64\python_d.exe -X dev bug.py
Run #3/12
+  C:\vstinner\python\3.9\PCbuild\amd64\python_d.exe bug.py
Windows fatal exception: access violation
(...)
Current thread 0x0420 (most recent call first):
  File "C:\vstinner\python\3.9\bug.py", line 13 in doIt
  File "C:\vstinner\python\3.9\lib\threading.py", line 910 in run
  File "C:\vstinner\python\3.9\lib\threading.py", line 973 in _bootstrap_inner
  File "C:\vstinner\python\3.9\lib\threading.py", line 930 in _bootstrap
(...)
COMMAND FAILED: 3221225477
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46361] Small ints aren't always cached properly



Change by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



STINNER Victor  added the comment:

I modified PR 30565 (3.10) and PR 30566 (3.9) to fix the ABI. I added 
_PyGC_GetState() which always use PyInterpreterState.gc of the main interpreter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

2022-01-12 Thread Anders Kaseorg


Anders Kaseorg  added the comment:

> While optparse that it isn't being developed further, therebut will not
> be taken away.  IIRC the reason for this was that it too had become
> difficult to build out and that is what necessitated the creation of
> argparse -- there wasn't clean way to add the desired features
> (subparsers, actions, etc).

My concern is not that optparse will be taken away.  My concern is that the 
documentation incorrectly discourages its use.

https://docs.python.org/3/library/optparse.html
“Deprecated since version 3.2: The optparse module is deprecated and will not 
be developed further; development will continue with the argparse module.”

Given that the apparent conclusion of this bug is that argparse has also become 
too difficult to fix, either argparse should be deprecated for exactly the same 
reason, or optparse should be un-deprecated.

Most programs don’t need the extra features of argparse, and optparse doesn’t 
have this bug, so optparse is a better default choice; the documentation should 
not be encouraging argparse over it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



Eric Snow  added the comment:

> adding a new "gc" member in the _PyRuntimeState structure also causes the ABI 
> CI check to fail.

What if you move it to the end of the struct?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +28770
pull_request: https://github.com/python/cpython/pull/30567

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Change by miss-islington :


--
pull_requests: +28771
pull_request: https://github.com/python/cpython/pull/30568

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Guido van Rossum  added the comment:


New changeset 1de60155d5d01be2924e72fb68dd13d4fd00acd7 by Nikita Sobolev in 
branch 'main':
bpo-46345: Add a test case for implicit `Optional` class attribute (GH-30535)
https://github.com/python/cpython/commit/1de60155d5d01be2924e72fb68dd13d4fd00acd7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



STINNER Victor  added the comment:

I prepared 3 pull requests to revert the commit 
7247407c35330f3f6292f1d40606b7ba6afd5700:

* PR 30564: main branch
* PR 30565: 3.10 branch
* PR 30566: 3.9 branch

The problem is that the "Check if the ABI has changed" CI job fails in 3.9 and 
3.10 branches.

I recently had the issue for a different revert in bpo-46006: I decided to keep 
the "removed" member, and mark it as "unused". See the commit 
72c260cf0c71eb01eb13100b751e9d5007d00b70 in the 3.10 branch:

struct _Py_unicode_state {
(...)

-PyObject *interned;

+// Unused member kept for ABI backward compatibility with Python 3.10.0:
+// see bpo-46006.
+PyObject *unused_interned;

(...)
}


I can keep the "gc" member in PyInterpreterState, but adding a new "gc" member 
in the _PyRuntimeState structure also causes the ABI CI check to fail.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45953] Statically allocate interpreter states as much as possible.



Eric Snow  added the comment:


New changeset ed57b36c32e521162dbb97199e64a340d3bff827 by Eric Snow in branch 
'main':
bpo-45953: Statically allocate the main interpreter (and initial thread state). 
(gh-29883)
https://github.com/python/cpython/commit/ed57b36c32e521162dbb97199e64a340d3bff827


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



Change by STINNER Victor :


--
pull_requests: +28769
pull_request: https://github.com/python/cpython/pull/30566

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



Change by STINNER Victor :


--
pull_requests: +28768
pull_request: https://github.com/python/cpython/pull/30565

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)



Change by STINNER Victor :


--
pull_requests: +28767
pull_request: https://github.com/python/cpython/pull/30564

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()


Raymond Hettinger  added the comment:

ISTM that the asymptotic benefits of Karatsuba multiplication are mostly lost 
when each of the factors has to be built-up recursively prior to the multiply.  
Also, the benefits of Karatsuba only start to appear at around 400-bit numbers. 
 For us, we don't get there until comb(400, 200).  Even there, almost all of 
the multiplications are with smaller values that get no benefit at all from 
Karatsuba multiplication.  IOW, I don't think Karatsuba multiplication has been 
helping at all.  More likely, the improvement came from a reduced number of 
divisions.

The depth issue is a red herring.  The fixed j approach is only used up to 
n=235.¹  The largest input, comb(235, 117), recurses only five levels 
C(215,97), C(195,77),
 C(175,57), C(155,37), C(135,17) before handing off to the j=k//2 algorithm.  
Five levels of width one is so inexpensive that it isn't worth talking about, 
especially when considering how many PyLong multiplies and divides are saved.²


¹ Jlim = 235 in the posted comb_pole.py.  I've since changed the span of 
precomputed combinations to C(n, 20) where 87 ≤ n ≤ 250.

² See the trace in the previous post showing a seven-fold reduction in the 
number of PyLong multiply and divide operations.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38204] Cannot compile on RPi with optimizations



Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.7.4 does not build on Raspbian Buster with 
optimizations

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37595] Python 3.7.4 does not build on Raspbian Buster with optimizations



Irit Katriel  added the comment:

Closed issue38204 as a duplicate of this. I don't know whether the problem 
still exists in current python versions.

--
nosy: +iritkatriel
title: Python 3.7.4 does not build on Raspbian Buster -> Python 3.7.4 does not 
build on Raspbian Buster with optimizations

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36854] GC operates out of global runtime state.



Change by STINNER Victor :


--
pull_requests: +28766
pull_request: https://github.com/python/cpython/pull/30566

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36854] GC operates out of global runtime state.



Change by STINNER Victor :


--
pull_requests: +28765
pull_request: https://github.com/python/cpython/pull/30565

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32996] Improve What's New in 3.7



Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37591] test_concurrent_future failed



Irit Katriel  added the comment:

Thanks for reporting, but 3.7 is no longer maintained so it's unlikely that 
anyone will investigate this anymore. Please create a new issue if you are 
seeing this on a current version (>= 3.9).

--
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46361] Small ints aren't always cached properly

2022-01-12 Thread Brandt Bucher



New submission from Brandt Bucher :

To my surprise, it seems that it's possible to create "small" integers that 
should live in _PyLong_SMALL_INTS, but don't. Here are two examples I've found:

>>> import decimal
>>> i = int(decimal.Decimal(42))  # Modules/_decimal/_decimal.c:dec_as_long
>>> i
42
>>> i is 42
:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
False
>>> i = int.from_bytes(bytes([42]))  # 
>>> Objects/longobject.c:_PyLong_FromByteArray
>>> i
42
>>> i is 42
:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
False

I'm not entirely sure if this is "allowed" or not, but in any case it seems 
beneficial to reach into the small ints here (provided it doesn't hurt 
performance, of course).

I'm testing out simple fixes for both of these now.

--
assignee: brandtbucher
components: Interpreter Core
messages: 410437
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Small ints aren't always cached properly
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37422] Documentation on the change of path in Python 3



Irit Katriel  added the comment:

>From the discussion is seems like there is nothing that needs to be added to 
>the docs. I will close this in a while if nobody objects.

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36557] [doc] Clarify the meaning of /uninstall in windows cli



Irit Katriel  added the comment:

This is referring to Doc/using/windows.rst

--
assignee:  -> docs@python
components: +Documentation
keywords: +easy
nosy: +docs@python, iritkatriel
title: Python (Launcher)3.7.3 CMDLine install/uninstall -> [doc] Clarify the 
meaning of /uninstall in windows cli
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36854] GC operates out of global runtime state.



Change by STINNER Victor :


--
pull_requests: +28764
pull_request: https://github.com/python/cpython/pull/30564

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46307] string.Template should allow inspection of identifiers



Change by Alex Waygood :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45331] Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.new should be smarter.



Change by Alex Waygood :


--
components: +Documentation -Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46341] duplicate paragraphs - asyncio Coroutines and Tasks file



Change by Alex Waygood :


--
nosy: +asvetlov, yselivanov
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46357] socket module fix warning build on FreeBSD

2022-01-12 Thread David CARLIER



David CARLIER  added the comment:

I took as initialized to avoid undefined behavior rather than anything.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Change by Alex Waygood :


--
components: +Tests -Library (Lib)
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default



Change by Alex Waygood :


--
nosy: +gvanrossum, kj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46348] Modernize `test_typing`



Change by Alex Waygood :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46358] Modernize `test_asyncio/test_base_events.py`



Change by Alex Waygood :


--
nosy: +asvetlov, yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46359] Continue to modernize `test_typing.py`



Change by Alex Waygood :


--
nosy: +gvanrossum, kj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46342] Make @final introspectable at runtime



Change by Alex Waygood :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46360] Inconsistent import behavior for (unusual) submodules



New submission from Eric Snow :

Let's look at a hypothetical module "spam" and its submodule "spam.eggs":

```
# spam.py
import sys
sys.modules['spam.eggs'] = None
```

Then:

>>> import spam.eggs
>>> import sys
>>> sys.modules['spam.eggs'] is None
True
>>> spam.eggs
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'spam' has no attribute 'eggs'

The key inconsistent behaviors:

* `import spam.eggs` succeeded even though the sys.modules entry is None
* `import spam.eggs` succeeded even though "spam" isn't a package (e.g. no 
`__path__`, `spec.submodule_search_locations`, etc.)
* the "eggs" attr wasn't bound on "spam"

The relevant code is _find_and_load_unlocked() and _find_and_load() in 
Lib/importlib/_bootstrap.py.

In _find_and_load_unlocked() we first import the parent module.  Then we have a 
special case, where we see if "spam.eggs" was added to sys.modules as a side 
effect.  If it was then we short-circuit the rest of import and return the 
submodule as-is.  This leads to some of the inconsistent behavior described 
above, since the subsequent code (e.g. checks, binding to the parent) get 
skipped.

In _find_and_load() we have code which raises ModuleNotFoundError if the 
resulting module is None, which acts as a marker that importing the module is 
disabled.  This check is always skipped when importing the module for the first 
time, leading to the other inconsistent behavior from above.

The is definitely a corner case, but os.path demonstrates it's a real scenario. 
 In fact, os.path is what drew my attention to this code.

Is it worth fixing?  The change shouldn't be invasive so I'm leaning toward 
yes.  It isn't a high priority though.

--
assignee: eric.snow
components: Interpreter Core
messages: 410433
nosy: barry, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Inconsistent import behavior for (unusual) submodules
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46357] socket module fix warning build on FreeBSD



STINNER Victor  added the comment:

> Solves the "Make sure new member of socket address initialized." warning for 
> the bluetooth sockaddr_l2cap usage.

You would to elaborate how you checked that all members of the socket address 
are initialized? Which socketmodule.c functions use this type? Are all members 
initialized?

https://www.leidinger.net/FreeBSD/dox/netgraph/html/d2/de3/structsockaddr__l2cap.html

A quick search points me to:
https://www.leidinger.net/FreeBSD/dox/netgraph/html/d2/de3/structsockaddr__l2cap.html
---
u_char  l2cap_len 
u_char  l2cap_family 
u_int16_t   l2cap_psm 
bdaddr_tl2cap_bdaddr 
u_int16_t   l2cap_cid 
u_int8_tl2cap_bdaddr_type
---

In BTPROTO_L2CAP case of getsockaddrarg(), it seems like only l2cap_family and 
l2cap_bdaddr are set, other members are set to 0. Is it enough? It seems like 
the important call is:

memset(addr, 0, sizeof(struct sockaddr_l2));

On FreeBSD, socketmodule.c uses:

#define sockaddr_l2 sockaddr_l2cap

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46359] Continue to modernize `test_typing.py`



Change by Nikita Sobolev :


--
components: +Tests
type:  -> behavior
versions: +Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46358] Modernize `test_asyncio/test_base_events.py`



Change by Nikita Sobolev :


--
keywords: +patch
pull_requests: +28762
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30562

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46359] Continue to modernize `test_typing.py`



Change by Nikita Sobolev :


--
keywords: +patch
pull_requests: +28763
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30563

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46359] Continue to modernize `test_typing.py`



New submission from Nikita Sobolev :

This is a follow up to:
- https://bugs.python.org/issue46348
- https://github.com/python/cpython/pull/30547

There are several other cases I've missed:
1. There's a test that is only executed under `<3.6`. I think that it should be 
removed: 
https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L4093-L4099
2. Line `if sys.version_info[:2] > (3, 2):` 
https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L1943
3. Line `if sys.version_info >= (3, 3):` 
https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L2069

I hope that this is it! 

PR is on it way :)

--
messages: 410431
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Continue to modernize `test_typing.py`

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46358] Modernize `test_asyncio/test_base_events.py`



New submission from Nikita Sobolev :

Right now there's a special case for python3.4 in 
`Lib/test/test_asyncio/test_base_events.py` file.

Links:
- 
https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_asyncio/test_base_events.py#L24
- 
https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_asyncio/test_base_events.py#L599

Python3.4 is long gone, I propose to remove this special case.
PR is on its way :)

--
components: Tests
messages: 410430
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Modernize `test_asyncio/test_base_events.py`
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

2022-01-12 Thread Steve Dower



Steve Dower  added the comment:

> Microsoft provides stat and struct stat, but they prepend the names with an 
> underscore.
They are also influenced by various compiler options to choose between 
32-bit and 64-bit fields. This makes it impossible to use the standard 
names as part of an ABI, because we can't/don't enforce that the 
preprocessor definitions match.

We should isolate all structures from libc/equivalent in our public API 
so that we can ensure compatibility. (FILE* was historically also an 
issue, but that was bad enough that Windows fixed it on their side. The 
rest of the C runtime library still bleeds everywhere, so we definitely 
don't want it or its semantics in our public API if avoidable.)

--
title: Building Python with clang on Windows fails on _Py_stat(): struct stat 
is not defined -> _Py_stat and _Py_wstat using incorrect type for status 
argument

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27273] subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen

2022-01-12 Thread Gregory P. Smith



Gregory P. Smith  added the comment:

agreed.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33125] Windows 10 ARM64 platform support

2022-01-12 Thread Steve Dower



Steve Dower  added the comment:

PEP 514 is the way to find it on Windows (you should be able to look directly 
for your supported version, rather than enumerating to search). As far as I 
know, the best way to find it on macOS and Linux is to search PATH for 
"python3.X".

Appreciate the size concerns. The Python runtime comes down to about 10MB with 
some basic tricks (already done on Windows in the embeddable distro), such as 
excluding the docs, test suite and zipping the standard library. It's possible 
with different tricks to do the same on other platforms, so you may even find 
the best balance for yourselves and your users is to repackage those and do a 
download-on-demand, rather than looking for a system installed Python.

> as an installer, it should be the most forgotten part of python that usually 
> runs for once or twice. 

Oh I wish this were the case! Installers should be forgotten, but they need to 
be 100% reliable or people *really* notice :)

But updating the installer build to target ARM64 while generating an x86 
executable should be possible, it just hasn't been done yet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

2022-01-12 Thread John Paul Adrian Glaubitz



John Paul Adrian Glaubitz  added the comment:

I'm running into exactly this issue when using 'offlineimap' which is written 
in Python.

--
nosy: +glaubitz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45569] Drop support for 15-bit PyLong digits?

2022-01-12 Thread Stefan Behnel

Stefan Behnel added the comment:

Cython should be happy with whatever CPython uses (as long as CPython's header
files agree with CPython's build ;-) ).

I saw the RasPi benchmarks on the ML. That would have been my suggested trial
platform as well.
https://mail.python.org/archives/list/python-...@python.org/message/5RJGI6THWCDYTTEPXMWXU7CK66RQUTD4/

The results look ok. Maybe the slowdown for pickling is really the increased
data size of integers. And it's visible that some compute-heavily benchmarks
like pyaes did get a little slower. I doubt that they represent a real use case
on such a platform, though. Doing any kind of number crunching on a RasPi
without NumPy would appear like a rather strange adventure.

That said, if we decide to keep 15-bit digits in the end, I wonder if
"SIZEOF_VOID_P" is the right decision point. It seems more of a "has reasonably
fast 64-bit multiply or not" kind of decision – however that translates into
code. I'm sure there are 32-bit platforms that would actually benefit from
30-bit digits today.

If we find a platform that would be fine with 30-bits but lacks a fast 64-bit
multiply, then we could still try to add a platform specific value size check
for smaller numbers. Since those are common case, branch prediction might help
us more often than not.

But then, I wonder how much complexity this is even worth, given that the goal
is to reduce the complexity. Platform maintainers can still decide to configure
the digit size externally for the time being, if it makes a difference for
them. Maybe switching off 15-bits by default is just good enough for the next
couple of years to come. :)

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46342] Make @final introspectable at runtime



Guido van Rossum  added the comment:


New changeset 0bbf30e2b910bc9c5899134ae9d73a8df968da35 by Jelle Zijlstra in 
branch 'main':
bpo-46342: make @typing.final introspectable (GH-30530)
https://github.com/python/cpython/commit/0bbf30e2b910bc9c5899134ae9d73a8df968da35


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40280] Consider supporting emscripten/webassembly as a build target

2022-01-12 Thread Christian Heimes



Christian Heimes  added the comment:


New changeset e34c9367f8e0068ca4bcad9fb5c2c1024d02a77d by Christian Heimes in 
branch 'main':
bpo-40280: Allow to compile _testcapi as builtin module (GH-30559)
https://github.com/python/cpython/commit/e34c9367f8e0068ca4bcad9fb5c2c1024d02a77d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46020] Optimize long_pow for the common case

2022-01-12 Thread Tim Peters

[issue45569] Drop support for 15-bit PyLong digits?

2022-01-12 Thread Mark Dickinson



Mark Dickinson  added the comment:

Adding Stefan Behnel to the nosy, since Cython is one of the few projects that 
might be directly affected by this change. Stefan: can you see any potential 
problems with changing the default to 30 here?

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37295] Possible optimizations for math.comb()

2022-01-12 Thread Tim Peters



Tim Peters  added the comment:

A feature of the current code is that, while the recursion tree can be very 
wide, it's not tall, with max depth proportional to the log of k. But it's 
proportional to k in the proposal (the C(n-j, k-j) term's second argument goes 
down by at most 20 per recursion level).

So, e.g., C(100, 50) dies with RecursionError in Python; in C, whatever 
platform-specific weird things can happen when the C stack is blown.

The width of the recursion tree could be slashed in any case by "just dealing 
with" (say) k <= 20 directly, no matter how large n is. Do the obvious loop 
with k-1 multiplies, and k-1 divides by the tiny ints in range(2, k+1). Note 
that "almost all" the calls in your "trace for the old code" listing are due to 
recurring for k <= 20.  Or use Stefan's method: if limited to k <= 20, it only 
requires a tiny precomputed table of the 8 primes <= 20, and a stack array to 
hold range(n, n-k, -1); that can be arranged to keep Karatsuba in play if n is 
large.

An irony is that the primary point of the recurrence is to get Karatsuba 
multiplication into play, but the ints involved in computing C(240, 112) are 
nowhere near big enough to trigger that.

To limit recursion depth, I think you have to change your approach to decide in 
advance the deepest you're willing to risk letting it go, and keep the current 
j = k // 2 whenever repeatedly subtracting 20 could exceed that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46357] socket module fix warning build on FreeBSD

2022-01-12 Thread David CARLIER



New submission from David CARLIER :

- Solves the "Make sure new member of socket address initialized." warning for 
the bluetooth sockaddr_l2cap usage.

--
components: FreeBSD
messages: 410419
nosy: devnexen, koobs
priority: normal
pull_requests: 28761
severity: normal
status: open
title: socket module fix warning build on FreeBSD
type: compile error
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40280] Consider supporting emscripten/webassembly as a build target

2022-01-12 Thread Christian Heimes



Change by Christian Heimes :


--
pull_requests: +28760
pull_request: https://github.com/python/cpython/pull/30559

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27273] subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen

2022-01-12 Thread Yassir Karroum



Yassir Karroum  added the comment:

As of 3.7, the subprocess.run has a new parameter "text".

IMO it's safer to explicitly set the "text" value instead of inferring it from 
the "input" type.

--
nosy: +ukarroum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46335] asyncio.create_subprocess_exec throws RuntimeError yet still executes subprogram

2022-01-12 Thread Clint Olsen



Clint Olsen  added the comment:

Yes, I tried FastChildWatcher and I've had much better luck with that. If any 
exception gets thrown we _know_ for certain that the process wasn't created.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46318] asyncio and ssl: ResourceWarning: unclosed transport

2022-01-12 Thread Julien Palard



Julien Palard  added the comment:

I don't know if it's related but _SSLPipe._shutdown_cb looks never called, in:

self._sslobj.unwrap()
self._sslobj = None
self._state = _UNWRAPPED

if self._shutdown_cb:
self._shutdown_cb()

the unwrap() call seems to always raise (The operation did not complete (read) 
(_ssl.c:2756)), thus never calling `self._shutdown_cb()`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()



STINNER Victor  added the comment:

> I don't know how we can stop people from using them though.

The first option is to promote helper functions to abstract access to the 
PyFrameObject structure.

The second option is to make the whole structure opaque and enforce the usage 
of helper functions. Before being able to do that, we need to prepare Cython 
and a few more popular C extensions for that. Right now, Cython still has a lot 
of code accessing directly PyFrameObject members.

Well, we can discuss that in bpo-40421 ;-)


> If they don't know better than pulling data out of undocumented internal 
> struct, then I'm not sure an underscore prefix is going to help. It won't do 
> any harm, though.

I propose to rename f_back to trigger a build error for existing C extensions 
which access it directly. So developers have to decide how to handle the 
change: access the renamed member, or read the doc and use a better way, call 
PyFrame_GetBack() :-)

I dislike that this incompatible change is "silent" and that developers may 
only notice the change in production, when it's too late.

Or maybe most C extensions have a a good test suite and will notice the change 
before it's too late.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46348] Modernize `test_typing`



Guido van Rossum  added the comment:


New changeset e2a9c8ef09cb7123d6b28852a323e6cc1f878b5b by Nikita Sobolev in 
branch 'main':
bpo-46348: modernize `test_typing` (GH-30547)
https://github.com/python/cpython/commit/e2a9c8ef09cb7123d6b28852a323e6cc1f878b5b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46351] Makefile missing '/' for some path names

2022-01-12 Thread Zachary Ware



Zachary Ware  added the comment:

This has been fixed in 3.11 with GH-28659, but the fix hasn't been backported 
due to the unlikelihood of this issue actually being a problem and a procedural 
wrinkle in the original PR.  I suspect a clean backport would be accepted, but 
this is still a rather low-priority issue.

--
components: +macOS
nosy: +ned.deily, ronaldoussoren, zach.ware
stage:  -> backport needed
type:  -> behavior
versions: +Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46314] Stray RESUME opcode for unused lambda



Mark Shannon  added the comment:

The news item was added in PR 30515

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46331] 3.11: tracing revisits class line after class docstring



Change by Mark Shannon :


--
assignee: Mark.Shannon -> 
keywords:  -patch
stage: resolved -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45729] [doc] "history and license" link has wrong target

2022-01-12 Thread Éric Araujo


Éric Araujo  added the comment:

dev docs direct to `/license.html` which redirects to `/3/license.html`

3.9 docs have the same; wouldn’t it be better to have `/3.9/license.html`?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46333] ForwardRef.eq does not respect module parameter

2022-01-12 Thread Andreas H.



Andreas H.  added the comment:

Ah, let me add one point: PEP563  (-> `from __future__ import annotations`) is 
also not helping. 

Even with PEP563 enabled, the JSON example  

   Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]

needs to be written in exact the same way as without PEP563. In other words 
there are cases where `ForwardRef` cannot be avoided. And unforntunately these 
are the cases where we have the ForwardRef missing context issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11



Mark Shannon  added the comment:

Are there any C programming guides we can link to, that explain API use?
I would hope that competent C programmers would know not to read or write to 
undocumented fields. But if they come from a Python background, that might not 
be obvious.

If the advice for something is "use Python", we should probably add an API 
function.

--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()



Mark Shannon  added the comment:

f_lineno is not part of the API. No field in PyFrameObject is.

I don't know how we can stop people from using them though.

If they don't know better than pulling data out of undocumented internal 
struct, then I'm not sure an underscore prefix is going to help.
It won't do any harm, though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46333] ForwardRef.eq does not respect module parameter

2022-01-12 Thread Andreas H.



Andreas H.  added the comment:

Yeah, sure. The use-case is (de)serialization. Right now I use the library 
cattr, but there are many others. 

If you are interested there is related discussion in the cattr board [1].


The original problem is how to define the types for serialization.

1. If everything is a class, things work well, but not if type aliases are 
used: 

2. Type aliases sometimes have to be used - they cannot be avoided in all 
cases, 
   especially with recursive types. The famous example is 

  Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]

   (Note: even though mypy does not support this construct, pylance meanwhile 
does [2])

3. `typing.Annotated` seems to be made for specifying additional information 
such as value ranges, right to be used
   in (de)serialization + validation contexts. Often these will just be type 
aliases (not used as class members). 
   Combination is possible with typing.NewType.


The problem is that the implicit `ForwardRef('Json')` cannot be automatically 
resolved (as it only a name with no context). 
There is really no way this could be handle inside a library such as cattr.  

When one wants to separate interface from implementation this issue is even 
more complicated. The module where the serialization function is called is 
typically different from the module with the type definition (This is probably 
more the norm than the exception)



The option I expored is to explicitly create the ForwardRef and specify the 
module parameter (even though I have to admit that I also did read that the 
ForwardRef is only for internal use). 
   
Json = Union[ List[ForwardRef(Json',module=__name__)], Dict[str, 
ForwardRef(Json',module=__name__)], int, float, bool, None ]

Ugly, but this is better than nothing.


A (worse) alternative is to do

Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]
typing._eval_type(Json, globals(), locals())

That works since it puts the ForwardRefs into "evaluated" state 
(self.__forward_value__ is then set)



A third, but future, alternative could be to automatically decompose the 
argument of ForwardRef into module and type. Then one could write

   Json = Union[ List[__name__+'.Json'], Dict[str, __name__+'.Json'], int, 
float, bool, None ]

and all above problems would be solved.

Then ForwardRef could stay internal and this is more readable. Even though, the 
static type checkers would need to understand `__name__+'TYPE'` constructs to 
be useful.


Anyhow, it would be nice to have a solution here.



[1]: https://github.com/python-attrs/cattrs/issues/201
[2]: 
https://devblogs.microsoft.com/python/pylance-introduces-five-new-features-that-enable-type-magic-for-python-developers/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

2022-01-12 Thread Silver Jublee Gaming



Silver Jublee Gaming  added the comment:

This must be normal

--
nosy: +silverjubleegaming

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()



STINNER Victor  added the comment:

It's unclear to me if the ability to read directly the PyFrameObject.f_lineno 
member is a deliberate use case, or if we should enforce the usage of 
PyFrame_GetLineNumber().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11



STINNER Victor  added the comment:

> f_lineno: changed, use PyFrame_GetLineNumber()

Oh I was wrong, PyFrame_GetLineNumber() code is the same in Python 3.10. It was 
already a bad idea to read directly the f_lineno member in Python 3.10: 
PyFrame_GetLineNumber() should always be called.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46356] [C API] Enforce usage of PyFrame_GetBack()



New submission from STINNER Victor :

C extensions written for Python 3.10 and older which access directly to the 
PyFrameObject.f_back member build successfully on Python 3.11, but they can 
fail because f_back must not be read directly. f_back can be NULL even if the 
frame has an outer frame.

PyFrameObject*
PyFrame_GetBack(PyFrameObject *frame)
{
assert(frame != NULL);
PyFrameObject *back = frame->f_back;
if (back == NULL && frame->f_frame->previous != NULL) {
back = _PyFrame_GetFrameObject(frame->f_frame->previous);
}
Py_XINCREF(back);
return back;
}

I suggest to remove or "hide" this member from the structure. For example, 
rename "f_back" to "_f_back" to advice developers to not access it directly.

See also bpo-46355: Document PyFrameObject and PyThreadState changes.

--
components: C API
messages: 410403
nosy: Mark.Shannon, vstinner
priority: normal
severity: normal
status: open
title: [C API] Enforce usage of PyFrame_GetBack()
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46320] runtime/interp/thread state refactoring leads to segmentation fault



Eric Snow  added the comment:

I'm glad we were able to figure it out relatively quickly...and without any big 
headaches. :)

And thanks for testing against the alpha releases!!!  You're having a positive 
impact.

--
resolution:  -> not a bug

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46292] Add microseconds to logging.LogRecord

2022-01-12 Thread Wade Carpenter



Change by Wade Carpenter :


--
nosy: +arwade

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported



STINNER Victor  added the comment:

> On Solaris (and most likely several other platforms), 
> `PyThread_get_thread_native_id` is also not available.

Oh, I added an explicit test for that in my PR 30556.

> `Py_FrozenMain` should be added to stable ABI

I suggest to first fix the issue (export the symbol), and then write a second 
PR to add it to the stable ABI.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40280] Consider supporting emscripten/webassembly as a build target

2022-01-12 Thread Christian Heimes



Christian Heimes  added the comment:


New changeset 43839ba438368a50f22f718d4ce8ce607c17046c by Christian Heimes in 
branch 'main':
bpo-40280: Add --with-emscripten-target to build for browser or node (GH-30552)
https://github.com/python/cpython/commit/43839ba438368a50f22f718d4ce8ce607c17046c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11



Change by STINNER Victor :


--
keywords: +patch
pull_requests: +28759
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30558

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46354] AttributeError: module 'collections' has no attribute 'Mapping'

2022-01-12 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

Hi mareklachbc,

What makes you think that this is a bug? 

Since at least version 3.7, you will have seen this warning:


>>> import collections
>>> collections.Mapping
__main__:1: DeprecationWarning: Using or importing the ABCs from
'collections' instead of from 'collections.abc' is deprecated
since Python 3.3,and in 3.9 it will stop working


So this is not a bug.

--
nosy: +steven.daprano
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11