[issue46645] Portable python3 shebang for Windows, macOS, and Linux

Christoph Reiter added the comment: (MSYS2 maintainer here) If you run a Python script in MSYS2 bash, the shebang gets interpreted by bash, which looks up in PATH (which by default doesn't include the full Windows PATH to avoid conflicts) and if installed leads to the MSYS2 included CPython

[issue42353] Proposal: re.prefixmatch method (alias for re.match)

Serhiy Storchaka added the comment: I am not convinced. What are examples of using re.match() instead of re.search()? How common is this type of errors? There are perhaps many millions of scripts which use re.match(), deprecating re.match() at any time in future would be very destructive, an

[issue41259] Find adverbs is not correct on the documentation

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing

New submission from Nikita Sobolev : Reproduction steps: 1. Add to `Setup.local`: ``` *disabled* _functoolsmodule ``` 2. `.configure && make -j`. Then, ensure that this module is not available: ``` » ./python.exe -c 'import _functools' Traceback (most

[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29318 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31141 ___ Python tracker ___ _

[issue36019] test_urllib fail in s390x buildbots: http://www.example.com/

Nikita Sobolev added the comment: `test.test_urllib2.MiscTests.test_issue16464` started to fail again: ``` == ERROR: test_issue16464 (test.test_urllib2.MiscTests) --

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

New submission from Nikita Sobolev : Today I've noticed that a lot of CI runs fail because of this test. Output: ``` == ERROR: test_issue16464 (test.test_urllib2.MiscTests) -

[issue36019] test_urllib fail in s390x buildbots: http://www.example.com/

Nikita Sobolev added the comment: I can also reproduce it locally with: `./python.exe -m test -v test_urllib2 -m test_issue16464 -u network` I've opened a new issue for it: https://bugs.python.org/issue46648 -- ___ Python tracker

[issue46649] Propagate Python thread name to thread state structure

New submission from Gabriele N Tornetta : For tools like Austin (https://github.com/P403n1x87/austin) it is currently quite challenging to derive the name of a thread based on the information exposed by the PyThreadState structure and one stored in threading._active. I would like to propose p

[issue46649] Propagate Python thread name to thread state structure

Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +29319 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31142 ___ Python tracker

[issue46649] Propagate Python thread name to thread state structure

STINNER Victor added the comment: bpo-15500 looks like a more generic option, debuggers should be able to retrieve thread names. faulthandler dumps "tstate->thread_id", maybe it should also dump "tstate->native_thread_id" and/or the thread name. -- nosy: +vstinner _

[issue46649] Propagate Python thread name to thread state structure

Gabriele N Tornetta added the comment: Thanks for mentioning that issue, it didn't come up in my search for a similar one. Indeed, with the proposals in bpo-15500 implemented, and the fact that native_thread_id is already in PyThreadState, retrieving the name should be easy and might make fo

[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing

Christian Heimes added the comment: _functoolsmodule is a core bootstrap module and defined in Modules/Setup.bootstrap. It has no external dependencies. There is no reason and no point to disable the module. We can safely assume that all modules defined in Modules/Setup.bootstrap are always

[issue46632] test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64

Change by Christian Heimes : -- assignee: christian.heimes -> type: -> behavior versions: +Python 3.10, Python 3.9 ___ Python tracker ___

[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing

Nikita Sobolev added the comment: Cristian, in this case - is there a reason to keep `skipUnless(c_functools)` around? If we are sure that it is always available - then it should be always tested. We either should have: 1. Cleanly defined skips that work (this PR) 2. Unconditional coverage

[issue46649] Propagate Python thread name to thread state structure

Oleg Iarygin added the comment: > bpo-15500 looks like a more generic option, debuggers should be able to > retrieve thread names. That option is not viable. 1. > Created on 2012-07-30 16:19 by bra, last changed 2022-01-19 00:32 by pitrou 2. > I don't think this should be done by default as

[issue44796] Add __parameters__ and __getitem__ in TypeVar and ParamSpec

Change by Serhiy Storchaka : -- pull_requests: +29321 pull_request: https://github.com/python/cpython/pull/31143 ___ Python tracker ___

[issue44796] Add __parameters__ and __getitem__ in TypeVar and ParamSpec

Serhiy Storchaka added the comment: I have created an alternative PR 31143 which adds special method __typing_subst__ in TypeVar and ParamSpec instead of __parameters__ and __getitem__. It has almost the same effect except making TypeVar and ParamSpec and subscriptable. The Python code in ty

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly). Python

[issue46650] `priority` in `sched.scheduler` is not sufficiently tested

New submission from Nikita Sobolev : Right now there only a single test to ensure `priority` works correctly in `scheduler`: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_sched.py#L90-L97 It looks like it is not enough. Why? ``` for priority in

[issue46650] `priority` in `sched.scheduler` is not sufficiently tested

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29322 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31144 ___ Python tracker ___ _

[issue46608] Exclude marshalled-frozen data if deep-freezing to save 300 KB space

Guido van Rossum added the comment: New changeset 9d4161a60ca8b470148ffd6c73e3110a0aa6d66f by Kumar Aditya in branch 'main': bpo-46608: Fix argument parsing in freeze_modules.py (GH-31131) https://github.com/python/cpython/commit/9d4161a60ca8b470148ffd6c73e3110a0aa6d66f --

[issue46479] Implement typing.reveal_locals

Jelle Zijlstra added the comment: Withdrawn as there's insufficient demand for this function. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46639] Ceil division with math.ceildiv

Mark Dickinson added the comment: I'm not convinced that this deserves to be a math module function. I agree that `-(-x // y)`, while simple to write, isn't necessarily obvious. But it does have some advantages, like not needing an import, and being naturally duck-typed, so that it automatic

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: > The big blocker here is that a platform that fully supports C99 might not > define the "NAN" macro. I don't think we can require that NAN be defined in > order for Python to build (which is what the PR currently does, if I'm > understanding it correctly).

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: > If a platform doesn't implement NaN, it should define the Py_NO_NAN macro Ah. In that case your PR description (and the PR news entry) is misleading: > Building Python now requires a C99 header file providing the > NAN constant. Please could you update th

[issue46639] Ceil division with math.ceildiv

Vladimir Feinberg added the comment: Mark, I will say I'm pretty sympathetic to the feature-bloat avoidance perspective here, and if the outcome here is to improve docs, that's still a win, I think. That said, since this thread will become precedent, and I think `math.ceildiv` is the exactly-a

[issue46644] typing: remove callable() check from typing._type_check

Gobot1234 added the comment: I also support this change. I've had to write a lot of code to make SpecialForms able to accept my types where the code has to look like: ```py class Something: ... def __call__(self, *args, **kwargs): raise NotImplementedError ``` I also know this c

[issue46644] typing: remove callable() check from typing._type_check

Jelle Zijlstra added the comment: I agree with removing this check. I suspect it's a holdover from very early typing when static types were supposed to be runtime types. Now the check is a bug magnet and doesn't serve a useful purpose. I think we can just remove the tests that check for ints

[issue46651] test_urllib2.test_issue16464() fails randomly

New submission from STINNER Victor : test_urllib2.test_issue16464() fails randomly. It uses http://www.example.com/ server. Instead, I proposed to use http://httpbin.org/post URL which is written to support HTTP POST. $ ./python -m test test_urllib2 -u all -v -m test_issue16464 =

[issue46651] test_urllib2.test_issue16464() fails randomly

STINNER Victor added the comment: Oh, bpo-46648 was already opened. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> `test.test_urllib2.MiscTests.test_issue16464` started to fail ___ Python tracker

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

STINNER Victor added the comment: I close my bpo-46651 as a duplicate of this issue. Copy of my message. test_urllib2.test_issue16464() fails randomly. It uses http://www.example.com/ server. Instead, I proposed to use http://httpbin.org/post URL which is written to support HTTP POST. $ ./

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

Change by STINNER Victor : -- keywords: +patch pull_requests: +29323 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31146 ___ Python tracker ___ _

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Gregory Beauregard added the comment: The reason this test passed before is a bit confusing. Run the following code standalone to see where the type(TypeVar('T'))(name, bases, namespace) check is coming from. ``` class TypeVar: def __init__(self, name, *constraints): # in actual T

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Change by Gregory Beauregard : -- keywords: +patch pull_requests: +29324 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31148 ___ Python tracker _

[issue46639] Ceil division with math.ceildiv

Tim Peters added the comment: GMP's mpz has 18 functions of this form. These are the 6 "ceiling" flavors: c_divmod c_div c_mod c_divmod_2exp c_div_2exp c_mod_2exp The suggestion here is for c_div. There are 6 more for floor rounding (with prefix "f_" instead of "c_"), and another 6 for tru

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Gregory Beauregard added the comment: Fixing this test unblocks bpo-46644 -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: I've been keeping my eyes open. The only mariginally relevant thing I've noticed is Hart's "one line factoring" method: http://wrap.warwick.ac.uk/54707/1/WRAP_Hart_S1446788712000146a.pdf That wants the _ceiling_ of the square root. And in another place it wants

[issue46639] Ceil division with math.ceildiv

Mark Dickinson added the comment: [Tim] > Because it's a bit obscure, and in real life y is always known to be > positive, so the nearly obvious (x + y - 1) // y works fine. Whereas I find (x + y - 1) // y less obvious at first sight than -(-x // y). :-) I don't care about negative y - that'

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

Change by Gregory Beauregard : -- nosy: +GBeauregard nosy_count: 2.0 -> 3.0 pull_requests: +29325 pull_request: https://github.com/python/cpython/pull/31148 ___ Python tracker

[issue46639] Ceil division with math.ceildiv

Tim Peters added the comment: I expect "obviousness" is mostly driven by background here. You know, e.g., that ceil(x) = -floor(-x) for any real x, and the application to integer division is just a special case of that. I expect programmers mostly don't know that, though. And Python having f

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

Christian Heimes added the comment: New changeset 96b344c2f15cb09251018f57f19643fe20637392 by Christian Heimes in branch 'main': bpo-40280: Address more test failures on Emscripten (GH-31050) https://github.com/python/cpython/commit/96b344c2f15cb09251018f57f19643fe20637392 -- _

[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool

Change by Jacob Walls : -- keywords: +patch nosy: +jacobtylerwalls nosy_count: 6.0 -> 7.0 pull_requests: +29326 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31149 ___ Python tracker

[issue38941] xml.etree.ElementTree.Element inconsistent warning for bool

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue46644] typing: remove callable() check from typing._type_check

Gregory Beauregard added the comment: Under the same failing int test cases before there were 2 more cases next to them that fail: with self.assertRaises(TypeError): ClassVar[int, str] with self.assertRaises(TypeError): Final[int, str] These fail because tuple literals are not callab

[issue46644] typing: remove callable() check from typing._type_check

Gregory Beauregard added the comment: Further questions: the msg argument in _type_check now wouldn't be used for anything! It was only used in the case where a type wasn't callable(). I think it should be removed. I'm also a bit negative on disallowing tuples in the case of e.g. Final and s

[issue46652] Use code.co_qualname to provide richer information

New submission from Gabriele N Tornetta : https://bugs.python.org/issue44530 introduced the co_qualname field to code objects. This could be used to, e.g. enrich the information provided by tracebacks. Consider this simple example ~~~ python import traceback class Bogus: def __init__(sel

[issue46652] Use code.co_qualname to provide richer information

Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +29327 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31150 ___ Python tracker

[issue46644] typing: remove callable() check from typing._type_check

Gregory Beauregard added the comment: I made a draft pull request where I went ahead and added a check to disallow tuple literals. This is basically already disallowed for types by restrictions on `__getitem__` because Union[typeform]->type needs to be different from Union[type,type]->Union[

[issue32442] file_open unc

Change by Mike Auty : -- title: Result of pathlib.Path.resolve() with UNC path is not very useful -> file_open unc ___ Python tracker ___ _

[issue46653] sys.path entries normalization in site.py doesn't follow POSIX symlink behaviour

New submission from Josselin Poiret : Whenever sys.prefix contains a symlink followed by a '..', the corresponding part of sys.path entries will not refer to the parent directory of the directory pointed to by the symlink, but rather to the directory in which the symlink is. Thus, it will be

[issue32442] Result of pathlib Path.resolve() with UNC path is not very useful

Mike Auty added the comment: Sorry for the spam, thought I was in a different text box. 5:( -- nosy: +ikelos title: file_open unc -> Result of pathlib Path.resolve() with UNC path is not very useful ___ Python tracker

[issue46644] typing: remove callable() check from typing._type_check

Change by Gregory Beauregard : -- keywords: +patch pull_requests: +29328 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31151 ___ Python tracker _

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

New submission from Mike Auty : I've found open to have difficulty with a resolved pathlib path: Example code of: import pathlib path = "Z:\\test.py" with open(path) as fp: print("Stock open: works") data = fp.read() with open(pathlib.Path(path).resolve().as_uri()) as

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Barney Gale added the comment: Why are you adding `.as_uri()`? -- nosy: +barneygale ___ Python tracker ___ ___ Python-bugs-list mai

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Eryk Sun added the comment: Builtin open() calls C open(). This C function supports whatever path types are supported natively. In Windows, C open() calls WinAPI CreateFileW(), which does not support "file://" URIs. The Windows API handles it as a relative path, which gets resolved against t

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Mike Auty added the comment: > Why are you adding `.as_uri()`? The API we provide accepts URIs, so whilst the example seems a little contrived, the code itself expects a URI and then calls open (making use of the ability to add open handlers). > Builtin open() calls C open(). As best I can

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Mike Auty added the comment: My bad, sorry, I realized I was conflating open with urllib.request.urlopen. I believe the issue still exists though, sorry for the confusion. -- ___ Python tracker ___

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Mike Auty added the comment: Here's the revised code sample: import pathlib import urllib.request path = "Z:\\test.py" print(f"Stock open: {pathlib.Path(path).as_uri()}") with urllib.request.urlopen(pathlib.Path(path).as_uri()) as fp: data = fp.read()

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg412604 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Barney Gale added the comment: urllib uses nturl2path under the hood. On my system it seems to return reasonable results for both two and four leading slashes: >>> nturl2path.url2pathname('host/share/test.py') 'host\\share\\test.py' >>> nturl2path.url2pathname('//host/shar

[issue45948] Unexpected instantiation behavior for xml.etree.ElementTree.XMLParser(target=None)

Change by Jacob Walls : -- keywords: +patch nosy: +jacobtylerwalls nosy_count: 1.0 -> 2.0 pull_requests: +29329 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31152 ___ Python tracker

[issue46652] Use code.co_qualname to provide richer information

Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue46654] file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Mike Auty added the comment: I can confirm that url2pathname work with either number of slashes, and that open_file appears to have had the file: removed. However, in even if the check in open_file were bypassed, it calls open_local_file, which then strips any host before calling url2pathnam

[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Change by Mike Auty : -- title: file_open doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) -> urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Eryk Sun added the comment: In FileHandler.file_open(), req.host is the host name, which is either None or an empty string for a local drive path such as, respectively, "file:/Z:/test.py" or "file:///Z:/test.py". The value of req.selector never starts with "//", for which file_open() checks,

[issue46554] Add append keyword argument to Path.write_text() and Path.write_bytes()

Keelung Yang added the comment: OK. Since most are opposed to append kwarg, I close this issue. Thanks ALL! -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker _

[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Eryk Sun added the comment: > file://server/host/file.ext on windows, even though > file:server/host/file.ext open just fine. For r"\\host\share\test.py", the two slash conversion "file://host/share/test.py" is correct according to RFC80889 "E.3.1. URI with Authority" [1]. In this case

[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes)

Barney Gale added the comment: Agree with the previous analysis. Just noting that: >>> nturl2path.pathname2url('host\\share\\test.py') 'host/share/test.py' So four slashes are produced by the urllib code, whereas pathlib only produces two. According to wikipedia, both the tw

[issue46654] urllib.request.urlopen doesn't handle UNC paths produced by pathlib's as_uri() (but can handle UNC paths with additional slashes)

Change by Barney Gale : -- title: urllib.request.urlopen doesn't handle UNC paths produced by pathlib's resolve() (but can handle UNC paths with additional slashes) -> urllib.request.urlopen doesn't handle UNC paths produced by pathlib's as_uri() (but can handle UNC paths with additi

[issue40479] Port _hashlib to OpenSSL 3.0.0

Change by Zackery Spytz : -- nosy: +ZackerySpytz nosy_count: 3.0 -> 4.0 pull_requests: +29330 pull_request: https://github.com/python/cpython/pull/31153 ___ Python tracker ___

[issue40479] Port _hashlib to OpenSSL 3.0.0

Zackery Spytz added the comment: There is a missing call to va_end() in 443b308fee088e21bbf472c376c5c9e3648f916c (which is undefined behavior). PR 31153 fixes this. -- ___ Python tracker __

[issue34191] argparse: Missing subparser error message should be more clear

Jacob Walls added the comment: Duplicate of issue29298 (fixed) -- nosy: +jacobtylerwalls ___ Python tracker ___ ___ Python-bugs-lis

[issue46652] Use code.co_qualname to provide richer information

Dennis Sweeney added the comment: Similar changes at bpo-40679 accidentally broke Cython when it was assumed that co_qualname was non-null, which was then fixed by defaulting to co_name in that case. I don't know if Cython still produces cases like that, but we should make sure not to needle

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail

Change by Dong-hee Na : -- pull_requests: -29325 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue45447] Make IDLE recognize .pyi stub files (and .pyw) as python source

Terry J. Reedy added the comment: I broaden the issue title scope and will correspondingly restrict the PR scope. 'Recognition' applies to open and save dialogs, syntax marking, and module browsing. (The latter needs fixing for .pyw also.) Improving the handling of no extension source with

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

New submission from Gregory Beauregard : typing.TypeAlias is allowed to be bare, but it's not listed in the list of types in typing._type_check that are allowed to be bare. This means it's possible to reach the wrong error `TypeError: Plain typing.TypeAlias is not valid as type argument` at r

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

Change by Gregory Beauregard : -- nosy: +Jelle Zijlstra ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue46655] typing.TypeAlias is not in the list of allowed plain _SpecialForm typeforms

Change by Gregory Beauregard : -- nosy: +kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth