[issue46751] Windows-style path is not recognized under cygwin

[Christoph Reiter]

Christoph Reiter  added the comment:

Afaik Cywin programs only work with native Windows paths if the paths happen to 
get directly passed to the OS APIs and not interpreted in any way before that. 
So I don't think this is a bug and expected behavior.

Use "cygpath C:/path/to/script.py" to convert the path to the right format 
first.

--
nosy: +lazka

___
Python tracker 

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

[issue46677] TypedDict docs are incomplete

[Charlie Zhao]

Change by Charlie Zhao :


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

___
Python tracker 

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

[issue45756] mock raises exception when using a spec with an attribute that raises exception on access

[hongweipeng]

Change by hongweipeng :


--
nosy: +hongweipeng
nosy_count: 5.0 -> 6.0
pull_requests: +29497
pull_request: https://github.com/python/cpython/pull/31348

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Eryk Sun]

Eryk Sun  added the comment:

WindowsPath.is_mount() should call ntpath.ismount(). This function needs a 
significant redesign, but it's fine to use it as long as it's documented that 
is_mount() is equivalent to os.path.ismount().

Since the owner() and group() methods return names instead of numeric IDs, 
technically we could implement them in WindowsPath. That said, in Windows, 
st_mode and chmod() are unrelated to a file's owner and group, plus object 
ownership is fundamentally different from POSIX. Unless chown() is also 
implemented, I don't think we would gain much from knowing the owner and group, 
other than making it easier to display them.

--
nosy: +eryksun

___
Python tracker 

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +njs

___
Python tracker 

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

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Guido van Rossum]

New submission from Guido van Rossum :

In https://arxiv.org/pdf/2109.03139.pdf ("M Köhl, An Executable Structural 
Operational Formal Semantics for Python, Master Thesis 2020 Saarland 
University) there are some observations on cases where the Language Reference 
(referred to as PLR) is ambiguous or incorrect.

Somebody should go over the thesis, collect the issues, and then we can update 
the language reference.

See also 
https://github.com/faster-cpython/ideas/issues/208#issuecomment-1039612432

--
messages: 413275
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Improve Python Language Reference based on [Köhl 2020]

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Eric Snow  added the comment:


New changeset 12360aa159c42c7798fd14225d271e6fd84db7eb by Eric Snow in branch 
'main':
bpo-46541: Discover the global strings. (gh-31346)
https://github.com/python/cpython/commit/12360aa159c42c7798fd14225d271e6fd84db7eb


--

___
Python tracker 

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

[issue46728] Docstring of combinations_with_replacement for consistency

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset 278fdd3e3a2492665b2c2888fd2f428f7f59a3f5 by DongGeon Lee in 
branch 'main':
bpo-46728: fix docstring of combinations_with_replacement for consistency 
(GH-31293)
https://github.com/python/cpython/commit/278fdd3e3a2492665b2c2888fd2f428f7f59a3f5


--
nosy: +corona10

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +29496
pull_request: https://github.com/python/cpython/pull/31346

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Eryk Sun]

Eryk Sun  added the comment:

MSYS2 has basically the same problem when the script is passed as a Windows 
path, except it uses "/c" for the "C:" drive instead of "/cygdrive/c".

# python3 -VV
Python 3.9.9 (main, Dec 28 2021, 11:05:23)
[GCC 11.2.0]

# echo $PWD
/proc

# python3 C:/Temp/test.py
python3: can't open file '/proc/C:/Temp/test.py': [Errno 2] No such file or 
directory

Windows paths in the command-line arguments appear to be passed without 
conversion:

# python3 -ic 1 C:/Temp/test.py
>>> import os
>>> open(f'/proc/{os.getpid()}/cmdline').read().split('\0')
['python3', '-ic', '1', 'C:/Temp/test.py', '']

They're generally supported:

>>> open('C:/Temp/test.py').read()
'import sys\nprint(sys.executable)\n\n'

>>> os.path.samefile('C:/Temp/test.py', '/c/Temp/test.py')
True

>>> os.path.abspath('C:/Temp/test.py')
'C:/Temp/test.py'

realpath() doesn't support them:

>>> os.path.realpath('C:/Temp/test.py')
'/:/Temp/test.py'

But the C API _Py_wrealpath() does:

>>> import ctypes
>>> path = (ctypes.c_wchar * 1000)()
>>> ctypes.pythonapi._Py_wrealpath('C:/Temp/test.py', path, 1000)
1484496
>>> path.value
'/c/Temp/test.py'

--
nosy: +eryksun

___
Python tracker 

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

[issue46753] Statically allocate and initialize the empty tuple.

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +29495
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31345

___
Python tracker 

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

[issue20923] [doc] Explain ConfigParser 'valid section name' and .SECTCRE

[Irit Katriel]

Irit Katriel  added the comment:

It’s still open. Go for it.

--

___
Python tracker 

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

[issue20923] [doc] Explain ConfigParser 'valid section name' and .SECTCRE

[Vidhya]

Vidhya  added the comment:

I am newbie to Python developer group and have the document source build and 
compiled successfully.

Is this issue updated in the document.
I would like to work on this if this is not closed.
Please let me know.

Thanks

--
nosy: +vidhya.friend

___
Python tracker 

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

[issue46753] Statically allocate and initialize the empty tuple.

[Eric Snow]

Eric Snow  added the comment:

Also see bpo-45953.

--

___
Python tracker 

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

[issue46753] Statically allocate and initialize the empty tuple.

[Eric Snow]

New submission from Eric Snow :

Currently it is created dynamically from the tuple freelist.

--
assignee: eric.snow
components: Interpreter Core
messages: 413268
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Statically allocate and initialize the empty tuple.
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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +29494
pull_request: https://github.com/python/cpython/pull/31344

___
Python tracker 

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

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

[Éric Araujo]

Éric Araujo  added the comment:

Thanks again!

--
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

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue46744] installers on ARM64 suggest wrong folders

[conio]

conio  added the comment:

I understand.

Though I think the naming scheme that includes platform identification is 
better, if *all* installers include the platform name unconditionally, 
including both amd64 and arm64, that's also an improvement. (So the names will 
be `Python311-32`, `Python311-amd64` and `Python311-arm64` - each in the 
appropriate Program Files folder.)

The convention would be uniform, there won't be a collision between arm64 and 
amd64 on the same system, and amd64 won't get preferential treatment even on 
non-amd64 systems.

Assuming `py.exe` will be fixed to recognize the arm64 versions in the 
Registry, I would be able to change the folder from `Python311-arm64` to 
`Python311` myself in the installer if it's so important to me and everything 
will work just the same.

I do wonder though - is there no platform detection code today in the 
installer? Would the x86 versions install into "PythonXY-32" even on 32-bit 
Windows? If there already is, then adding a call to `IsWow64Process2` doesn't 
sound that difficult. Especially since that's almost the same couple of lines 
that will have to added to the PyLauncher anyway. Could you please point me to 
where the code for the Windows Python installer is so I could also take a look?

--

___
Python tracker 

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

[issue46749] Support cross compilation on macOS

[Ned Deily]

Change by Ned Deily :


--
components: +macOS -Cross-Build
nosy: +ronaldoussoren

___
Python tracker 

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

[issue46749] Support cross compilation on macOS

[Ned Deily]

Ned Deily  added the comment:

We don't currently support cross-building a single macOS architecture on 
another, i.e. building an x86_64 only build on an Apple Silicon Mac. However, 
we do support building a multi-architecture build on either on current releases 
of Python 3.9 and 3.10, with what is known as a universal or fat build. In this 
case, you'd want to add these two options:

./configure --enable-universalsdk --with-universal-archs=universal2 ...

For this to succeed, you will also need to provide universal builds of any of 
the third-party libraries used by standard modules you need and that are not 
otherwise provided by macOS, the most common being OpenSSL and XZ (and perhaps 
newer versions of SQLite and Tcl/Tk). For the most part, those are 
straightforward to build yourself but also may be available through some 
third-party distributors like MacPorts and possibly HomeBrew. The 
Mac/README.rst file in repo has some more details about universal builds and 
there may be some useful hints at building the third-party libraries in 
Mac/BuildScript/build-installer.py although it is not intended to be used for 
this purpose. The resulting universal2 build can be used as is on either 
Intel-64 or Apple Silicon Macs but, if you truly need to have only Intel 
binaries you should be able to use the macOS lipo command to separate out the 
desired architecture from the built executables and shared libraries into other 
files. If you want to run t
 hese binaries on a range of macOS versions, you can also set the 
MACOSX_DEPLOYMENT_TARGET environment variable when building the libs and 
Python; we currently test and support back to 10.9.

--
nosy: +ned.deily

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Mike Kaganski]

Mike Kaganski  added the comment:

> As for 3.9: it's not available through the 64 bit installer (at least, I 
> don't see it there). I'll look and see what's involved in installing it.

I don't remember if I did something special to install it; however, just maybe 
you need to install python39 directly.

> Are you running the 32- or 64-bit version?

64-bit.

> Does Cygwin not use : as a path list separator?

It uses : as path separator:

$ echo $PATH
/opt/lo/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program 
Files/AdoptOpenJDK/jdk-11.0.7.10-hotspot/bin:/cygdrive/c/Program Files 
(x86)/Common 
Files/Oracle/Java/javapath:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/System32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:...

But obviously, it can't use Windows-style paths in the $PATH (for that reason?).

--

___
Python tracker 

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

[issue46566] Support -3.11-arm64 in py.exe launcher

[conio]

Change by conio :


--
nosy: +conio

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Barney Gale  added the comment:

Thanks very much Alex. I've added some PRs:

PR 31338 addresses owner(), group() and is_mount(). It moves those methods to 
PosixPath, and adds stubs in WindowsPath that raise deprecation warnings. I 
agree with your analysis that, for static typing purposes, these methods 
shouldn't even exist on WindowsPath!

PR 31339 addresses readlink(), symlink_to() and hardlink_to(). In this case I'm 
working towards making those methods unavailable if os.readlink(), symlink() 
and link() are unavailable. Not totally sold on this - thoughts?

PR 31340 addresses glob() and rglob(), switching the exception type to 
ValueError. I think this is a legitimate bugfix with minimal adverse effects.

PR 31341 addresses the Path constructor. This is a backwards incompatible 
change, and /probably/ not worth doing. I add it for completeness sake, as 
these four PRs cover all cases where pathlib raises NotImplementedError.

--

___
Python tracker 

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

[issue46744] installers on ARM64 suggest wrong folders

[Steve Dower]

Steve Dower  added the comment:

Thanks for the additional info! I agree with the design you propose.

It would be much easier to make the ARM64 install use the tagged 
directory though (C:\Program Files\Python 3.11-arm64). I'd rather not 
get into the business of detecting platforms from the installer, and 
leave that to the OS (which can decide whether the MSI is suitable or not).

I'll try and take a look at what the detection code would be like and 
make a call.

--

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Steve Dower]

Steve Dower  added the comment:

Does Cygwin not use : as a path list separator? (What would normally be 
; on Windows.)

Perhaps the CPython build needs to be patched specially here to handle 
different separator character.

--

___
Python tracker 

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

[Guido van Rossum]

Change by Guido van Rossum :


--
keywords: +patch
pull_requests: +29493
pull_request: https://github.com/python/cpython/pull/31270

___
Python tracker 

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

[Guido van Rossum]

New submission from Guido van Rossum :

After some conversations with Yury, and encouraged by the SC's approval of PEP 
654, I am proposing to add a new class, asyncio.TaskGroup, which introduces 
structured concurrency similar to nurseries in Trio.

I started with EdgeDb's TaskGroup implementation 
(https://github.com/edgedb/edgedb/blob/master/edb/common/taskgroup.py) and 
tweaked it only slightly. I also changed a few things in asyncio.Task (see 
below).

The key change I made to EdgeDb's TaskGroup is that subtasks can keep spawning 
more subtasks while __aexit__ is running; __aexit__ exits once the last subtask 
is done. I made this change after consulting some Trio folks, who knew of 
real-world use cases for this behavior, and did not know of real-world code in 
need of prohibiting task creation as soon as __aexit__ starts running. I added 
some tests for the new behavior; none of the existing tests needed to be 
adjusted to accommodate this change.

(For other changes relative to the EdgeDb's TaskGroup, see GH-31270.)

In order to avoid the need to monkey-patch the parent task, I added two new 
methods to asyncio.Task, .cancelled() and .uncancel(), that manage a flag 
corresponding to __cancel_requested__ in EdgeDb's TaskGroup. 

**This introduces a change in behavior around task cancellation:**

* A task that catches CancelledError is allowed to run undisturbed (ignoring 
further .cancel() calls and allowing any number of await calls!) until it 
either exits or calls .uncancel().

This change in semantics did not cause any asyncio unittests to fail. However, 
it may be surprising (especially to Trio folks, where the semantics are pretty 
much the opposite, once a Trio task is cancelled all further await calls in 
that task fail unless explicitly shielded).

For the TaskGroup tests to pass, we require a flag that is not cleared. 
However, it is probably not really required to ignore subsequent .cancel() 
calls until .uncancel() is called. This just seemed more consistent, and it is 
what @asvetlov proposed above and implemented in GH-31313 (using a property 
.__cancel_requested__ as the API).

--
assignee: gvanrossum
components: asyncio
keywords: needs review
messages: 413260
nosy: asvetlov, gvanrossum, iritkatriel, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Introduce task groups to asyncio and change task cancellation semantics
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

[issue46751] Windows-style path is not recognized under cygwin

[Eric V. Smith]

Eric V. Smith  added the comment:

>:) Citing myself:

>> Trying this *bash* command line:

Oops, sorry for missing that.

As for 3.9: it's not available through the 64 bit installer (at least, I don't 
see it there). I'll look and see what's involved in installing it.

Are you running the 32- or 64-bit version?

Also: I suspect this is a cygwin problem that will need to be reported upstream.

--

___
Python tracker 

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

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

[Mariatta]

Mariatta  added the comment:


New changeset b27195332e91e932501f16cf9877761b218a9c99 by Miss Islington (bot) 
in branch '3.10':
bpo-46436: Fix command-line option -d/--directory in module http.server 
(GH-30701)
https://github.com/python/cpython/commit/b27195332e91e932501f16cf9877761b218a9c99


--

___
Python tracker 

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

[issue46436] Pass the -d/--directory command-line option to http.server.CGIHTTPRequestHandler

[Mariatta]

Mariatta  added the comment:


New changeset 502ad3930ee8fcf76026edfc06a33621363cebea by Miss Islington (bot) 
in branch '3.9':
bpo-46436: Fix command-line option -d/--directory in module http.server 
(GH-30701) 
https://github.com/python/cpython/commit/502ad3930ee8fcf76026edfc06a33621363cebea


--
nosy: +Mariatta

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Mike Kaganski]

Mike Kaganski  added the comment:

Thanks for looking at this!

> Are you running from bash (or another cygwin shell), or from cmd.exe, or 
> something else?

:) Citing myself:

> Trying this *bash* command line:

> To my knowledge, cygwin's installer doesn't have a 3.9 available.

It does: https://cygwin.com/packages/summary/python3.html

--

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29491
pull_request: https://github.com/python/cpython/pull/31340

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29492
pull_request: https://github.com/python/cpython/pull/31341

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29490
pull_request: https://github.com/python/cpython/pull/31339

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Change by Barney Gale :


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

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[miss-islington]

miss-islington  added the comment:


New changeset 1953f03174c18f315aca883babc3819828f868d8 by Miss Islington (bot) 
in branch '3.9':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/1953f03174c18f315aca883babc3819828f868d8


--

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[miss-islington]

miss-islington  added the comment:


New changeset 828253227efe16f0e759df36bbb2ca49083223c8 by Miss Islington (bot) 
in branch '3.10':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/828253227efe16f0e759df36bbb2ca49083223c8


--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Cool! Be aware that using it outside codeop is currently unsupported:

https://github.com/python/cpython/blob/5d53cf30f9cb3758849e859db5d4602cb7c521f7/Lib/codeop.py#L43-L47

So have in mind that the flag, mechanism and semantics can change without 
previous notice

--

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Shivaram Lingamneni]

Shivaram Lingamneni  added the comment:

(Looks like it was 15 milliseconds when measuring inside `python -i`; I'm not 
sure what the root cause of the difference is, but clearly the 5 millisecond 
measurement from regular `python` is more accurate.)

--

___
Python tracker 

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

[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"

[Mateusz Loskot]

Mateusz Loskot  added the comment:

Possibly, the new partial-input mode of the parser 
(https://bugs.python.org/issue46521#msg412832) will improve this issue in 3.11. 
I'm going to play with it soon and I will report back.

--

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Eric V. Smith]

Eric V. Smith  added the comment:

Are you running from bash (or another cygwin shell), or from cmd.exe, or 
something else?

How did you install the version of python you're executing in the examples you 
provided? To my knowledge, cygwin's installer doesn't have a 3.9 available.

I don't see this behavior on cygwin's python3.8, either from cmd.exe or from 
zsh.

--
nosy: +eric.smith

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[Mariatta]

Mariatta  added the comment:

Thanks. I do think it is helpful to state that it is lowercase.
I have merged the PR, and will backport to 3.10 and 3.9.

Thanks.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +29487
pull_request: https://github.com/python/cpython/pull/31334

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[Mariatta]

Mariatta  added the comment:


New changeset 5d53cf30f9cb3758849e859db5d4602cb7c521f7 by 180909 in branch 
'main':
bpo-38619: Update the documentation for UUID.hex (GH-29830)
https://github.com/python/cpython/commit/5d53cf30f9cb3758849e859db5d4602cb7c521f7


--
nosy: +Mariatta

___
Python tracker 

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

[issue38619] [Doc] UUID.hex is lowercase

[miss-islington]

Change by miss-islington :


--
pull_requests: +29488
pull_request: https://github.com/python/cpython/pull/31335

___
Python tracker 

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

[issue46751] Windows-style path is not recognized under cygwin

[Mike Kaganski]

New submission from Mike Kaganski :

Using cyqwin 3.3.4-2, and python3:

Python 3.9.10 (main, Jan 20 2022, 21:37:52)
[GCC 11.2.0] on cygwin

Trying this bash command line:

> python3 C:/path/to/script.py

results in this error:

"python3: can't open file '/cygdrive/c/path/to/curdir/C:/path/to/script.py': 
[Errno 2] No such file or directory"

OTOH, calling it like

> python3 /cygdrive/c/path/to/script.py

gives the expected output:

"usage: script.py [-h] ..."

It seems that python3 doesn't recognize "C:/path/to/script.py" to be a proper 
full path under cygwin, while most other cygwin apps handle those fine. E.g.,

> nano C:/path/to/script.py

opens the script for editing without problems.

The mentioned path syntax is useful and supported under cygwin, so it would be 
nice if python3 could support it, too. Especially useful it is in mixed 
development environment, mixing Windows native tools and cygwin ones; using 
such path style allows to use same paths for both kinds of tools, simplifying 
scripts.

--
components: Windows
messages: 413247
nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows-style path is not recognized under cygwin
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Eric Snow  added the comment:

With core code sorted out, stdlib and 3rd party extension modules are left to 
sort out.

I see the following possibilities:

1. leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
2. change `_Py_IDENTIFIER()` to create static string objects (then get rid of 
global state)
3. get rid of `_Py_IDENTIFIER()`
   a. provide a public alternative (needs a PEP)
   b. first work with 3rd party projects to stop using it

--

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Change by Eric Snow :


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

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Shivaram Lingamneni]

Shivaram Lingamneni  added the comment:

Sorry, I should have been more clear: I am including the initial costs of 
importing stringprep and unicodedata. On my system:

$ python3 -c "import time; start = time.time(); r = 'a'.encode('idna'); elapsed 
= time.time() - start; print(elapsed)"
0.0053806304931640625

So the earlier measurement of 15 milliseconds was excessive (I'm not sure what 
happened) but it's the right order of magnitude: I can reproduce 5 milliseconds 
reliably.

--

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Craig Coleman]

Craig Coleman  added the comment:

>From  https://docs.python.org/3/reference/datamodel.html#object.__hash__

User-defined classes have __eq__() and __hash__() methods by default; with 
them, all objects compare unequal (except with themselves) and x.__hash__() 
returns an appropriate value such that x == y implies both that x is y and 
hash(x) == hash(y).

It doesn't work like that for tuples, NamedTuples nor dataclasses because their 
behaviour isn't expected to be a "user-defined class".

--

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Craig Coleman]

Craig Coleman  added the comment:

Seems I learned a python lesson today.

I've put myself back in python school and done some reading on a) the code 
behind dataclasses, b) PEP 557 and c) the doc'n for __eq__.

After all the reading I've realised this I'd been making some assumptions about 
how __eq__ works which have now been corrected.  Thanks for your help.

--

___
Python tracker 

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

[issue46739] dataclasses __eq__ isn't logical

[Dennis Sweeney]

Change by Dennis Sweeney :


--
resolution:  -> not a bug
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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Christian Heimes]

Christian Heimes  added the comment:

It's 100 times faster. The initial import takes about 150 μsec (0.15msec) and 
it's a one time cost. IDNA encoding of a typical hostname is about 70nsec. A 
DNS lookup is three magnitudes slower.

--

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Eric Snow]

Eric Snow  added the comment:

With core code sorted out, stdlib and 3rd party extension modules are left to 
sort out.

I see the following possibilities:

* leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
* change `_Py_IDENTIFIER()` to create static string objects (then get rid of 
global state)
* get rid of `_Py_IDENTIFIER()`
   a. provide a public alternative (needs a PEP)
   b. first work with 3rd party projects to stop using it

--

___
Python tracker 

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

[issue46474] Inefficient regular expression complexity in EntryPoint.pattern

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 8a84aef0123bd8c13cf81fbc3b5f6d45f96c2656 by Jason R. Coombs in 
branch '3.8':
[3.8] bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with 
importlib_metadata 4.10.1) (GH-30803). (#30829)
https://github.com/python/cpython/commit/8a84aef0123bd8c13cf81fbc3b5f6d45f96c2656


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue46748] Python.h includes stdbool.h

[Petr Viktorin]

Petr Viktorin  added the comment:

It is in C99, but in an optional header.
IMO, including the header in the internals is perfectly OK, but opting everyone 
else in isn't very nice.
i.e. it would probably be OK to use `_Bool`, the actual C99 keyword that `bool` 
is defined as. But that's ugly enough to prefer `int`...

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Guido van Rossum]

Guido van Rossum  added the comment:

Yeah, that should erase the type, not have special semantics.

--

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Shivaram Lingamneni]

Shivaram Lingamneni  added the comment:

Thanks for the prompt response. As evidence that this was of concern to the 
development team in the past, here's an issue where the unnecessary import of 
idna was treated as a regression:

https://bugs.python.org/issue22127

The discussion there also examines the semantic change produced by the 
optimization (some invalid labels making it to a DNS lookup instead of being 
rejected) and doesn't consider it to be a breaking change (albeit a reason not 
to backport).

(I also see references in documentation to a discussion labeled "RFE #1472176", 
but am unable to find the actual bug tracker or database entry this refers to.)

A time cost of 15 milliseconds seems accurate to me. The RAM cost on my release 
build of Python 3.8.10 is about 600 KB in RSS (this is approximately 5% of the 
baseline interpreter usage).

I cannot reproduce the claim that `urllib.parse` imports stringprep or 
unicodedata:

python3 -c "import sys, urllib.parse; assert 'stringprep' not in 
sys.modules"

python3 -c "import sys, urllib.parse; assert 'unicodedata' not in 
sys.modules"

I am developing a new lightweight http library that does use urllib.parse; on 
my system, these patches allow it to function without importing stringprep, 
idna, or unicodedata:

https://github.com/slingamn/mureq

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Gobot1234]

Gobot1234  added the comment:

> Which classes? Every class that inherits from Generic? That would be 
> problematic -- we don't want the addition of typing information to change the 
> behavior of a construct (or at least as little as possible).

The class itself would remain unchanged, the only thing I propose changing is 
what happens when you subscript it and then attempt to instantiate it.

--

___
Python tracker 

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

[issue46748] Python.h includes stdbool.h

[Eric Snow]

Eric Snow  added the comment:

On Mon, Feb 14, 2022 at 2:28 AM Petr Viktorin  wrote:
> Eric, is this necessary? Would an old-school `int` do?
> Or should we say it's 2022 already and everyone needs to use stdbool.hfore 
> bools?

I started using ``bool`` (stdbool.h) when I saw it specified in PEP 7
(https://www.python.org/dev/peps/pep-0007/#c-dialect).  If it is a
problem then I think it should be answered relative to PEP 7.  I'm not
sure what the best route is though.  Personally, I'd argue that if
it's in C99 then it should probably be standard at this point. :)
However, I'm not opposed to going back to plain int.  (And I know
there are definitely a number of old-school folks who prefer plain
int. :) )

--

___
Python tracker 

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

[issue46679] test.support.wait_process ignores timeout argument

[Nikita Sobolev]

Change by Nikita Sobolev :


--
nosy: +sobolevn
nosy_count: 1.0 -> 2.0
pull_requests: +29486
pull_request: https://github.com/python/cpython/pull/31274

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Dennis Sweeney]

Dennis Sweeney  added the comment:

Thanks for the report, Stefan!
Thanks for the PR, Zackery!

--
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

[issue46747] bisect.bisect/insort don't document key parameter

[Dennis Sweeney]

Dennis Sweeney  added the comment:


New changeset 841c77d802e9ee8845fa3152700474021efe03fd by Dennis Sweeney in 
branch '3.10':
[3.10] bpo-46747: Add missing key parameters in the bisect docs (GH-31323) 
(GH-31329)
https://github.com/python/cpython/commit/841c77d802e9ee8845fa3152700474021efe03fd


--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Guido van Rossum]

Guido van Rossum  added the comment:

> On the general class instanciation point would there be anything wrong with 
> just adding a big red warning saying (on the non-existent) docs for these 
> classes that they don't follow normal class initization or is this too 
> insignificant of an issue to bother?

Which classes? Every class that inherits from Generic? That would be 
problematic -- we don't want the addition of typing information to change the 
behavior of a construct (or at least as little as possible).

> I think you could make this work with a Protocol as the bound TypeVar("T", 
> bound=HasTheCorrectNewSignature)?

Sure.

But I am still inclined to reject the feature request as too obscure.

--

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Christian Heimes]

Christian Heimes  added the comment:

Please provide benchmarks and data for your claim that encodings.idna is a 
performance bottleneck.

encodings.idna is a simple, short module without state. On my system it takes 
about 0.15 msec to import the module. When unicodedata and stringprep aren't 
loaded yet, it still takes less than 0.5 msec. The stringprep and unicodedata 
modules are used by other modules, e.g. urllib parse. It's likely that any 
non-trivial program with network access has both imported already.

$ python3 -m timeit -s "import sys" "import encodings.idna; 
sys.modules.pop('encodings.idna'); sys.modules.pop('stringprep'); 
sys.modules.pop('unicodedata')"
500 loops, best of 5: 488 usec per loop


The IDNA codec performs additional verification of the input. You cannot 
replace it with a simple "try encode to ASCII" block:

>>> ("a"*65).encode('idna')
Traceback (most recent call last):
  File "/usr/lib64/python3.10/encodings/idna.py", line 167, in encode
raise UnicodeError("label too long")
UnicodeError: label too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label too long)

--
assignee: christian.heimes -> 
stage: patch review -> 

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Dennis Sweeney]

Change by Dennis Sweeney :


--
pull_requests: +29485
pull_request: https://github.com/python/cpython/pull/31329

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Dennis Sweeney]

Dennis Sweeney  added the comment:


New changeset 96084f4256d2d523b0a4d7d900322b032326e3ed by Zackery Spytz in 
branch 'main':
bpo-46747: Add missing key parameters in the bisect docs (GH-31323)
https://github.com/python/cpython/commit/96084f4256d2d523b0a4d7d900322b032326e3ed


--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Shivaram Lingamneni]

Change by Shivaram Lingamneni :


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

___
Python tracker 

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

[issue46750] some code paths in ssl and _socket still import idna unconditionally

[Shivaram Lingamneni]

New submission from Shivaram Lingamneni :

Importing the idna encoding has a significant time and memory cost. Therefore, 
the standard library tries to avoid importing it when it's not needed (i.e. 
when the domain name is already pure ASCII), e.g. in Lib/http/client.py and 
Modules/socketmodule.c with `idna_converter`.

However, there are code paths that still attempt to encode or decode as idna 
unconditionally, in particular Lib/ssl.py and _socket.getaddrinfo. Here's a 
one-line test case:

python3 -c "import sys, urllib.request; 
urllib.request.urlopen('https://www.google.com'); assert 'encodings.idna' not 
in sys.modules"

These code paths can be converted using existing code to do the import 
conditionally (I'll send a PR).

--
assignee: christian.heimes
components: Interpreter Core, Library (Lib), SSL
messages: 413229
nosy: christian.heimes, slingamn
priority: normal
severity: normal
status: open
title: some code paths in ssl and _socket still import idna unconditionally
type: resource usage
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

[issue46586] In documentation contents enum.property erroneously links to built-in property

[Meer Suri]

Meer Suri  added the comment:

https://docs.python.org/3.11/library/io.html?highlight=io#text-i-o -

The easiest way to create a text stream is with open(), optionally specifying 
an encoding:

https://docs.python.org/3.11/library/io.html?highlight=io#binary-i-o - 

The easiest way to create a binary stream is with open() with 'b' in the mode 
string:

For both of these cases, the markup for the open() is :meth:`open()` but it 
links to the builtins open(), which I see is an alias of io.open() so maybe it 
doesn't matter?
Another question is why do only these two instances use :meth: while the other 
instances in the file use :func: (some refer directly to builtins open() so its 
understandable, but not all instances)
I'm wondering if the above two should be left alone or changed to 
:meth:`~io.open` or even :func:`open`

--

___
Python tracker 

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

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

[Alex Waygood]

Alex Waygood  added the comment:

Thanks, Andrew! I've submitted a patch.

--

___
Python tracker 

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

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

[Alex Waygood]

Change by Alex Waygood :


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

___
Python tracker 

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

[issue46724] Odd Bytecode Generation in 3.10

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +29482
pull_request: https://github.com/python/cpython/pull/31326

___
Python tracker 

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

[issue46622] Support decorating a coroutine with functools.cached_property

[Andrew Svetlov]

Andrew Svetlov  added the comment:

>From my point of view, both sync and async functions can be cached.

Sync and async iterators/generators are other beasts: they don't return a value 
but generate a series of items. The series can be long and memory-consuming, I 
doubt if it should be cached safely.

--

___
Python tracker 

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

[issue46622] Support decorating a coroutine with functools.cached_property

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Note that there is a similar issue with cached generators.

>>> from functools import *
>>> @lru_cache()
... def g():
... yield 1
... 
>>> list(g())
[1]
>>> list(g())
[]

I am not sure that it is safe to detect awaitables and iterables in caching 
decorators and automatically wrap them in re-awaitable and re-iterable objects. 
But we can add explicit decorators and combine them with arbitrary caching 
decorators. For example:

@lru_cache()
@reiterable
def g():
yield 1

--

___
Python tracker 

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

[issue46749] Support cross compilation on macOS

[autoantwort]

Change by autoantwort :


--
components: +Cross-Build -Build
nosy: +Alex.Willmer

___
Python tracker 

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

[issue46749] Support cross compilation on macOS

[autoantwort]

New submission from autoantwort :

Currently you get the following output:
```
➜  debug git:(main) ✗ ../configure --host=x86_64-apple-darwin 
--build=arm64-apple-darwin --with-build-python=./python3.11
checking for git... found
checking build system type... aarch64-apple-darwin
checking host system type... x86_64-apple-darwin
checking for --with-build-python... ./python3.11
checking for Python interpreter freezing... ./python3.11
checking for python3.11... (cached) ./python3.11
checking Python for regen version... Python 3.11.0a5+
checking for x86_64-apple-darwin-pkg-config... no
checking for pkg-config... /opt/homebrew/bin/pkg-config
configure: WARNING: using cross tools not prefixed with host triplet
checking pkg-config is at least version 0.9.0... yes
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... configure: error: cross build not supported for 
x86_64-apple-darwin
```

Is "needed" for https://github.com/microsoft/vcpkg/issues/22603

--
components: Build
messages: 413224
nosy: autoantwort
priority: normal
severity: normal
status: open
title: Support cross compilation on macOS
type: enhancement
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

[issue46622] Support decorating a coroutine with functools.cached_property

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Agree. Let's start from async functions support by `functools.lru_cache`. 

If we will have an agreement that cached_property is an important use-case we 
can return to this issue.

I have a feeling that async lru_cache is much more important. 
https://pypi.org/project/async_lru/ has 0.5 million downloads per month: 
https://pypistats.org/packages/async-lru

--

___
Python tracker 

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

[issue46072] Unify handling of stats in the CPython VM

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +29481
pull_request: https://github.com/python/cpython/pull/31324

___
Python tracker 

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

[issue46622] Support decorating a coroutine with functools.cached_property

[Tzu-ping Chung]

Tzu-ping Chung  added the comment:

I agree that `print(await a.hello)` does look awkward, although I know some 
would disagree. (Context: I submitted this BPO after a colleague of mine at 
$WORK pointed out the behavioural difference between `functools` and 
`cached_property to me.)

Personally I’d feel this more natural:

class Foo:
@functools.cache
async def go(self):
print(1)

async def main():
foo = Foo()
await foo.go()
await foo.go()

Although now I just noticed this actually does not work either.

Perhaps we should fix this instead and add a line in the documentation under 
cached_property to point people to the correct path?

--

___
Python tracker 

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

[issue46743] Enable usage of object.__orig_class__ in __init__

[Gobot1234]

Gobot1234  added the comment:

On the general class instanciation point would there be anything wrong with 
just adding a big red warning saying (on the non-existent) docs for these 
classes that they don't follow normal class initization or is this too 
insignificant of an issue to bother?

> I don't think it's possible in general, since you are blindly instantiating 
> the type (self.__orig_class__.__args__[0]) without arguments. That doesn't 
> work for all types.

I think you could make this work with a Protocol as the bound TypeVar("T", 
bound=HasTheCorrectNewSignature)?

> I'm also not sure what static type checkers would make of this. But I presume 
> you don't care about that.

Yeah considering this is only accessed in one place and how likely difficult it 
would be to implement it doesn't bother me much no. (You can avoid the 
attribute access errors using __orig_class__: GenericAlias if you know what 
your doing is always safe).

> Or is the main goal that the original code is simpler then this lazy 
> initialization workaround.

Pretty much yeah I'd like the code to be much simplier and avoid this work 
around (although you could probably simplify it with a cached_property)

--

___
Python tracker 

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

[issue46748] Python.h includes stdbool.h

[Petr Viktorin]

Petr Viktorin  added the comment:

Yes, stdbool.h is essentially a backport of C++'s bool type to C.

--

___
Python tracker 

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

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

[Eryk Sun]

Eryk Sun  added the comment:

> 4) use Job objects to group Windows processes for termination

I think a separate issue should be created for this enhancement.

_winapi wrappers would be needed for CreateJobObjectW(), 
SetInformationJobObject(), AssignProcessToJobObject(), TerminatejobObject(), 
and ResumeThread(), plus the constant CREATE_SUSPENDED. I'd also prefer to make 
related changes to send_signal(), which would require GetConsoleProcessList() 
and GenerateConsoleCtrlEvent().

A new Popen option would be needed to configure whether the job allows 
descendants to break away via the process creation flag 
CREATE_BREAKAWAY_FROM_JOB. This should be allowed by default.

---

send_signal(): SIGKILL, SIGTERM, SIBREAK, SIGINT

Support Popen.kill(group=False) and Popen.terminate(group=False) on all 
platforms as Popen.send_signal(signal.SIGKILL, group=group) and 
Popen.send_signal(signal.SIGTERM, group=group).

The Universal CRT (ucrt) in Windows doesn't define SIGKILL. Even when it's not 
defined by the platform, signal.SIGKILL should always be defined, preferably as 
9 (unused by ucrt), else as an unused value in the range up to NSIG, else as 
NSIG + 1.

The `group` keyword-only option broadens the scope to the process group or job. 
A process is a group leader if it was created with the flag 
CREATE_NEW_PROCESS_GROUP (save self._creationflags) and its process ID is in 
GetConsoleProcessList().

For SIGKILL, always use forced termination. For SIGTERM, use forced termination 
either if `group` is false or if `group` is true and the process is not a group 
leader. To force termination, call TerminateJobObject(self._job_handle, 1) if 
`group` is true, else TerminateProcess(self._handle, 1). 

For SIGTERM, SIGBREAK, and SIGINT, call GenerateConsoleCtrlEvent() if `group` 
is true and the process is a group leader. For SIGTERM and SIGBREAK, send 
CTRL_BREAK_EVENT. For SIGINT, send CTRL_C_EVENT. 

Behavior to deprecate:

When `group` is false and `sig` is CTRL_C_EVENT (0) or CTRL_BREAK_EVENT (1), 
send_signal() always calls os.kill(). This legacy behavior tries to handle a 
process as if it's a process group, and it combines POSIX kill() with Windows 
API constants. subprocess should distance itself from the fundamental problems 
with os.kill() in Windows.

--

___
Python tracker 

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

[issue46741] Docstring for asyncio.protocols.BufferedProtocol appears out of date

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Alex, you are right. BufferedProtocol is considered stable since 3.8
A pull request with docstring fix is welcome.

--

___
Python tracker 

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

[issue46745] Typo in new PositionsIterator

[Alex Waygood]

Change by Alex Waygood :


--
keywords: +patch
stage:  -> patch review
type:  -> behavior

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +rhettinger
type:  -> behavior

___
Python tracker 

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

[issue46748] Python.h includes stdbool.h

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Is it compatible with C++?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue46748] Python.h includes stdbool.h

[Petr Viktorin]

New submission from Petr Viktorin :

In main, cpython/pystate.h newly includes stdbool.h, providing a definition for 
`bool` that might be incompatible with other software.

See here: https://github.com/cmusphinx/sphinxbase/pull/90

Eric, is this necessary? Would an old-school `int` do?
Or should we say it's 2022 already and everyone needs to use stdbool.hfore 
bools?

--
messages: 413216
nosy: eric.snow, petr.viktorin
priority: normal
severity: normal
status: open
title: Python.h includes stdbool.h
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

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

[Eryk Sun]

Eryk Sun  added the comment:

> I fear the potential 3rd-party breakage alone should bump
> this to its own issue.

The change to the DWORD converter in _winapi should only be in 3.11+. If this 
causes problems for other projects, they're probably depending on undefined 
behavior in the standard library. No third-party package or application should 
use _winapi directly.

> 1) modify Windows Popen._wait() to raise on out of bounds 
> values [< 0 or >= INFINITE]

I think raising ValueError would be best at this level. For example:

if timeout is None:
timeout_millis = _winapi.INFINITE
else:
timeout_millis = int(timeout * 1000)
if timeout_millis >= _winapi.INFINITE:
raise ValueError("'timeout' exceeds the platform limit")
if timeout_millis < 0:
raise ValueError("'timeout' must be non-negative")

--

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Zackery Spytz]

Zackery Spytz  added the comment:

Thank you for the report.

--

___
Python tracker 

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

[issue46747] bisect.bisect/insort don't document key parameter

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +29480
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31323

___
Python tracker 

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