[issue47178] Improve the implementations of Sequence.index and MutableSequence.extend in collections.abc

[Géry]

New submission from Géry :

This P.R. will make the following changes to the `collections.abc` module:

- simplify the implementation with slicing in function `Sequence.index`.
- remove an unnecessary copy of `self` when a sequence extends itself in 
function `MutableSequence.extend`.

--
components: Library (Lib)
messages: 416415
nosy: maggyero
priority: normal
pull_requests: 30285
severity: normal
status: open
title: Improve the implementations of Sequence.index and MutableSequence.extend 
in collections.abc
type: enhancement
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

[issue47176] Interrupt handling for wasm32-emscripten builds without pthreads

[Hood Chatham]

Change by Hood Chatham :


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

[issue47176] Interrupt handling for wasm32-emscripten builds without pthreads

[Hood Chatham]

Change by Hood Chatham :


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

[issue47176] Interrupt handling for wasm32-emscripten builds without pthreads

[Hood Chatham]

Change by Hood Chatham :


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

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[Dong-hee Na]

Change by Dong-hee Na :


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

[issue47166] Dataclass transform should ignore TypeAlias variables

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

>From a typing perspective this is reasonable. See this thread about type 
>aliases in class scopes: 
>https://mail.python.org/archives/list/typing-...@python.org/thread/CGOO7GPPECGMLFDUDXSSXTRADI4BXYCS/
> 

However, it's a niche use case and we could decide that we don't want to 
further complicate the annotation parsing in dataclasses.py.

--

___
Python tracker 

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

[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception

[Enji Cooper]

Enji Cooper  added the comment:

Grégory: good question.

I would personally advocate for doing it out of selfish interests. 

I'm working with middleware based on 3.8 (moving to 3.9+ is non-trivial), and 
we have a common fault scenario where the system breaks if 
logging.handlers.SysLogHandler is instantiated and the target host cannot be 
resolved, like seen in the first comment.

Backporting the changes you referenced would make addressing the above issue 
easier, since the logic in connect(..) was moved into its own routine.

--

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[miss-islington]

miss-islington  added the comment:


New changeset d04a21344ae69c66f5a6df69ee6fa6988a69b89d by Miss Islington (bot) 
in branch '3.9':
bpo-46775: OSError should call winerror_to_errno unconditionally on Windows 
(GH-32179)
https://github.com/python/cpython/commit/d04a21344ae69c66f5a6df69ee6fa6988a69b89d


--

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[miss-islington]

miss-islington  added the comment:


New changeset 1f2ec4cef1804cda9d2df99a318373b2982919e9 by Miss Islington (bot) 
in branch '3.10':
bpo-46775: OSError should call winerror_to_errno unconditionally on Windows 
(GH-32179)
https://github.com/python/cpython/commit/1f2ec4cef1804cda9d2df99a318373b2982919e9


--

___
Python tracker 

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

[issue47166] Dataclass transform should ignore TypeAlias variables

[Jelle Zijlstra]

Change by Jelle Zijlstra :


--
nosy: +AlexWaygood, GBeauregard, JelleZijlstra

___
Python tracker 

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

[issue47146] PR check "Check if generated files are up to date" failing intermittently

[Eric Snow]

Eric Snow  added the comment:


New changeset db4dada5108dd49ebca23e4559a53630a2df8447 by Eric Snow in branch 
'main':
bpo-47146: Avoid Using make Recursively (gh-32206)
https://github.com/python/cpython/commit/db4dada5108dd49ebca23e4559a53630a2df8447


--

___
Python tracker 

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

[issue47177] Frames should store next_instr instead of lasti

[Brandt Bucher]

Change by Brandt Bucher :


--
keywords: +patch
pull_requests: +30283
pull_request: https://github.com/python/cpython/pull/32208

___
Python tracker 

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

[issue47177] Frames should store next_instr instead of lasti

[Brandt Bucher]

New submission from Brandt Bucher :

Rather than maintaining the offset of the "last instruction" (`f_lasti`), 
interpreter frames should instead just maintain a pointer to the true next 
instruction. This has several benefits, most notably reducing the register 
pressure associated with loading first_instr on every instruction and call in 
the main interpreter loop:

When entering a frame:

- Before: `next_instr = first_instr + frame->f_lasti + 1;`
- After:  `next_instr = frame->next_instr;`

When starting a new instruction:

- Before: `frame->next_instr = next_instr++ - first_instr;`
- After:  `frame->next_instr = ++next_instr;`

Benchmarks suggest that this overhead is surprisingly significant (something 
like 2%).

--
assignee: brandtbucher
components: Interpreter Core
messages: 416409
nosy: Mark.Shannon, brandtbucher
priority: normal
severity: normal
stage: patch review
status: open
title: Frames should store next_instr instead of lasti
type: performance
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

[issue14911] generator.throw() documentation inaccurate

[David Goncalves]

Change by David Goncalves :


--
nosy: +dpg
nosy_count: 6.0 -> 7.0
pull_requests: +30282
pull_request: https://github.com/python/cpython/pull/32207

___
Python tracker 

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

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

[Tim Peters]

Tim Peters  added the comment:

I believe I'm elaborating on your "footgun".

It doesn't matter to me whether we pick some scheme and document it, _if_ that 
scheme is incoherent, impossible to remember, error-prone, etc.

That's how, e.g., regular expression syntax was designed. "I know! ++*??+) 
doesn't have a coherent meaning now, so let's say it means to match a prime 
number of the pattern it follows" ;-)

That is, an error-prone extension is worse than no extension at all.

The algorithm now isn't guessing at anything: it's saying up front that two 
tasks are the same task if and only if they compare equal. Context, execution 
history, ..., nothing else is relevant. It's simple. Complicating a simple 
thing may open new possibilities, but creates new traps too.

One trap is pretty obviously making "the rules" for when two tasks are the same 
task depend on the execution history at the time the question is asked.

That goes away, though, if the current rule is retained ("the same iff =="), 
but can be explicitly overridden by .forget() (or some such).

That doesn't make it a no-brainer, though. For example, do

.add(A, B)

and run until A and B are marked done. Now do

.add(B, C)

What then? We're back in a guessing game again. We've just been told that B 
depends on C first. But we already did B. Depending on _domain_ knowledge we 
cannot have, that may or may not be worthy of raising an exception.

You can make up any rule you want about that and arbitrarily declare victory, 
but the chance that a user will realize it's not the behavior _their_ domain 
needs is approximately 0 until after they've been burned by it. So now it's 
error-prone, at least to them.

FWIW, in that specific case I'd say "tough beans - you told us too late that B 
depends on C to stop B the first time, but now that you've told us we'll 
respect it in future".

Another twist: assuming that's "the rule", what does

.add(B, C)

really mean? If B really is "the same task" as it was the first time around, 
well, it's already been marked done. Are we supposed to do it _again_ now? Why? 
Why not?

It's hard for me to find any _compelling_ sense here - just masses of 
more-or-less arbitrary implementation decisions. In which case "hard to 
remember" follows soon after.

None of that haunts the current API. It all follows quite directly from what 
"depends on" means to essentially everyone.

--

___
Python tracker 

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

[issue47166] Dataclass transform should ignore TypeAlias variables

[Ned Deily]

Change by Ned Deily :


--
nosy: +eric.smith

___
Python tracker 

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

[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception

[Ned Deily]

Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue47146] PR check "Check if generated files are up to date" failing intermittently

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +30281
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32206

___
Python tracker 

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

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

[Larry Hastings]

Larry Hastings  added the comment:

I'm not sure I follow you.  What do you suggest graphlib is guessing at?  I 
thought we were discussing what graphlib's (documented, intentional) behavior 
should be; if there was any guessing going on, it was us doing it, guessing at 
what behavior the user would prefer.

I appreciate you corresponding on the issue, but I'm having difficulty 
understanding what light you're shining on the problem.

--

___
Python tracker 

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

[issue44733] Feature request: maxtasksperchild for ProcessPoolExecutor

[Logan Jones]

Logan Jones  added the comment:

Ok I now have a PR up with the features requested. Let me know if you need 
anything else!

--

___
Python tracker 

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

[issue47150] HTTPRedirectHandler fails on POST for 307 and 308

[Ned Deily]

Change by Ned Deily :


--
nosy: +orsenthil

___
Python tracker 

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

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

[Tim Peters]

Tim Peters  added the comment:

Various kinds of tasks:

- "Power switch must be on." Needs to done the first time. _May_ need to be 
done again later (if some later task turns the power off again). Can be done 
any number of times without harm (beyond the expense of checking), so long as 
the switch is on.

- "Ensure gas tank is full." Probably needs to be done anew for every new added 
task that depends on it.

- "Remove outermost layer of skin." Probably shouldn't be done more than once 
;-)

- "Flip Najdorf switch." Who knows? Doing it a second time - or failing to do 
it a second time - may be necessary, harmless, or deadly.

I'd rather not bother with any of this dicey guessing. While some dynamism may 
be attractive, what it all "should mean" appears to be a rat's nest, and 
depends on domain knowledge graphlib can't possibly have.

I doubt there is a compelling default. As is, two tasks are considered to be 
"the same" task if and only if they compare equal, so that's the least 
_surprising_ default for tasks added later. "Remove outermost layer of skin"

"Two tasks that compare equal may or may not be considered the same task, 
depending on the execution history at the time the question is posed" is at 
best expedient, at worst disastrous.

--

___
Python tracker 

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

[issue46841] Inline bytecode caches

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +30280
pull_request: https://github.com/python/cpython/pull/32205

___
Python tracker 

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

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

[Larry Hastings]

Larry Hastings  added the comment:

Having slept on it, I think the footgun is slightly bigger than I gave it 
credit for.  Also the problem of nodes lingering forever is easily solved: give 
the user control.

My next iteration will keep the done nodes around, but I'll also add a forget() 
method that compels the graph to forget all done nodes.

--

___
Python tracker 

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

[issue47173] test_launcher fails on win-arm64 buildbot

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
stage: needs patch -> 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

[issue47176] Interrupt handling for wasm32-emscripten builds without pthreads

[Hood Chatham]

New submission from Hood Chatham :

In Pyodide, we need to patch the interpreter to allow keyboard interrupts. We 
build Python without pthreads support because Emscripten doesn't currently 
support using pthreads and dynamic linking in the same build. It is still 
possible to handle UI at the same time as running Python code by running Python 
in a web worker. However, the web assembly memory is private to the webworker 
and cannot be modified from the main thread. The standard way that keyboard 
interrupts are handled is that the operating system preempts the task to run a 
signal handler. This can't happen in Emscripten because there is no operating 
system.

Instead, in Emscripten we create a SharedArrayBuffer, share it with the main 
thread, and then write the signal into this shared memory from the main thread. 
We patch the main loop to periodically poll this SharedArrayBuffer and if an 
interrupt has been requested it calls `PyErr_SetInterruptEx` to signal the 
interrupt. I've set the polling rate to once every 50 interpreter operations, 
which seems to be reasonably responsive and have a negligible performance cost. 

One interesting feature of this setup is that it is impossible to create a 
pointer to the shared memory so it cannot be read directly from C (instead we 
check it from an `EM_ASM` block).

--
components: Interpreter Core
messages: 416403
nosy: hoodmane
priority: normal
severity: normal
status: open
title: Interrupt handling for wasm32-emscripten builds without pthreads
type: enhancement
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

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

[Géry]

Géry  added the comment:

Alright, thanks. Raymond, any objections before I propose the removal of 
one-argument super?

--

___
Python tracker 

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

[issue47175] Allow applications to tune the condition that triggers a GIL release and implementation choice in hashlib

[Gregory P. Smith]

New submission from Gregory P. Smith :

## Background

All `hashlib` computations and `binascii.crc32` and `zlib.crc32` release the 
GIL around their computational core.  But they use a hard coded length check to 
determine when to do so, or always do it.

That already accomplishes the larger good of releasing the GIL on big 
computations. But _probably_ just serves to slow down smaller ones when a GIL 
release adds more overhead than a context switch to another thread could 
meaningfully provide in terms of forward progress.

## Desire 1

Determine if a threshold should exist at all (should we just always release the 
GIL for these?) and if so, allow it to be tuned on a per algorithm basis.

This comes at the same time as other enhancements like bpo-47102 and its 
windows and macos cousins could shift us towards using OS kernel APIs for a 
subset of algorithms where available - which may effectively "always release" 
the GIL on OS APIs that are virtual IO call based such as bpo-47102's.

## Desire 2

When multiple implementations of an algorithm may be available, allow the user 
to configure data length thresholds for when each one is triggered. Without 
meaningfully slowing most things down by adding such logic.  Different 
implementations have different setup and finalization time which can make them 
more useful for large data rather than tiny.

---

I'm marking this low priority as it veers towards over-optimization. :)  
Creating benchmarks and a thing to live in Tools/ that people could run on 
their target platform to provide a tuning suggestion of what thresholds work 
best for their needs.

Related inspiring work: OSes often benchmark several algorithm implementations 
up front to pick a "best" to use for a given platform (ex: see what the Linux 
kernel does for hashes and raid algorithms).  This extends that idea and 
acknowledges latency as important, not exclusively thru-put.

--
messages: 416401
nosy: gregory.p.smith
priority: low
severity: normal
stage: needs patch
status: open
title: Allow applications to tune the condition that triggers a GIL release and 
implementation choice in hashlib
type: enhancement

___
Python tracker 

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

[issue22260] Rearrange tkinter tests, use test discovery

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> out of date
stage: patch review -> 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

[issue17733] Add tests to test__header_value_parser for RFC 2231 parsing code

[Irit Katriel]

Change by Irit Katriel :


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

[issue32754] feature request: asyncio.gather/wait cancel children on first exception

[Irit Katriel]

Change by Irit Katriel :


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

[issue47173] test_launcher fails on win-arm64 buildbot

[Steve Dower]

Steve Dower  added the comment:

Looks like that probably fixed it. Will let the buildbot run again to be sure:

https://buildbot.python.org/all/#/builders/729/builds/1191
https://buildbot.python.org/all/#/builders/730/builds/4322

--

___
Python tracker 

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

[issue47171] Enable py.exe install in Windows ARM64 installer

[Steve Dower]

Change by Steve Dower :


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

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

[Steve Dower]

Steve Dower  added the comment:


New changeset f3d5715492195fd2532fc1a5d73be07923cdf2e1 by Steve Dower in branch 
'main':
bpo-46566: Make test_launcher more robust to a variety of installs (GH-32204)
https://github.com/python/cpython/commit/f3d5715492195fd2532fc1a5d73be07923cdf2e1


--

___
Python tracker 

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

[issue47148] sys.path.append before import the module causing module don't have doc-string?

[Zachary Ware]

Zachary Ware  added the comment:

Also cannot reproduce on Windows:

D:\issue47148_test\parent\another folder>type ..\a.py
def multiply():
"""multiply stuff"""
return 2 * 4

D:\issue47148_test\parent\another folder>type b.py
import sys
sys.path.append('..')
import a
print(a.multiply.__doc__)

D:\issue47148_test\parent\another folder>py b.py
multiply stuff


My best advice would be to try to reproduce it again yourself in a clean 
directory, and/or remove all `*.pyc` files and `__pycache__` directories from 
your project and try again, making sure you have no environment variables 
starting with `PYTHON` set.  If you still find you're having trouble, please 
reach out in the Users category of discuss.python.org.

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

[issue47171] Enable py.exe install in Windows ARM64 installer

[Steve Dower]

Steve Dower  added the comment:


New changeset 2ab609dd614045f3b112ede0b0883339de784f2a by Steve Dower in branch 
'main':
bpo-47171: Enable installing the py.exe launcher on Windows ARM64 (GH-32203)
https://github.com/python/cpython/commit/2ab609dd614045f3b112ede0b0883339de784f2a


--

___
Python tracker 

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

[issue47146] PR check "Check if generated files are up to date" failing intermittently

[Christian Heimes]

Christian Heimes  added the comment:

The problem is likely a recursive make call "$(MAKE)" in combination with 
parallel execution. As far as I understand it, GNU make cannot track 
dependencies properly, which can lead to partial or invalid dependency graphs. 
One make process can modify a file while another uses the file. The permission 
error or ETXTBSY error are manifestation of one process creating an executable 
while another process is attempting to execve() it.

The paper https://accu.org/journals/overload/14/71/miller_2004/ explains the 
issues with recursion in great detail.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue47173] test_launcher fails on win-arm64 buildbot

[Steve Dower]

Steve Dower  added the comment:

The fix in PR 32204 also clears out VIRTUAL_ENV, so that may be enough. It's 
running on buildbots to see whether it helps.

--

___
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

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +30279
pull_request: https://github.com/python/cpython/pull/32204

___
Python tracker 

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

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi

30.03.2022 21:44, Larry Martell пишет:

On Wed, Mar 30, 2022 at 2:40 PM Kirill Ratkin via Python-list
  wrote:

Hi again,

I changed a bit your example and it works as you expected I hope.

import asyncio


async def long():
  for i in range(100):
  await asyncio.sleep(10)
  print("long is done")


loop = asyncio.get_event_loop()

task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))


But how I wrote before ... if you are in big Django project just look at
existent django libraries for long task running. One of it I sent you.
There is 'celery' as well.

It's more pragmatic way ...

Appreciate the reply. I did not know about django-background-tasks -
thanks. I've been trying to make use of that. I do not get the errors
I was getting before but it does not appear that my long running task
is running at all. Still debugging. But concerting asyncio - doesn't
run_until_complete block until long() completes?


Yes, It runs until the /future/ has completed.

In example above 'gather' is not necessary because you create one async 
task only.


You can pass 'task' to run_until_complete directly.

But if you create several tasks, all of it need to be run concurently 
and 'gather' does it.


import asyncio
import random


async def long(x):
    duration = random.randint(2, 5)
    await asyncio.sleep(duration)
    print(f"long is done {x} slept for {duration} seconds")


loop = asyncio.get_event_loop()

task1 = loop.create_task(long(1))
task2 = loop.create_task(long(2))
task3 = loop.create_task(long(3))

print('after asyncio.run')

loop.run_until_complete(asyncio.gather(task1, task2, task3))

So here run_until_complete will wait untill all three tasks complete  or 
cancel for some reasons (then exception happens. btw we don't handle it 
in example).



In your example you use 'asyncio.run'. Internally it does things like to 
this


def run(ft)
loop = asyncio.get_event_loop()
task = loop.create_task(ft())
loop.run_until_complete(asyncio.gather(task))

Of course real asyncio.run is much more complicated but model is same, i 
think.


It creates loop and future and 'run_until_complete' for future/task in 
the loop.


That's why you never get 'print' before asyncio.run finishes.


You also can split run_until_complete and gather.

s = asyncio.gather(task1, task2, task3)
print('after asyncio.run')
loop.run_until_complete(s)

Then 'gather' starts schedule all tasks before 'print' executes. For 
example, if you have some network IO operations instead this 'print' ... 
maybe few of your async tasks are done during this time.






30.03.2022 19:10, Larry Martell пишет:

import asyncio
import time

async def long():
  for i in range(100):
 time.sleep(10)

asyncio.run(long())
print('after asyncio.run')

--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

[issue47162] Add call trampoline to work around bad fpcasts on Emscripten

[miss-islington]

miss-islington  added the comment:


New changeset 581c4434de62d9d36392f10e65866c081fb18d71 by Christian Heimes in 
branch 'main':
bpo-47162: Add call trampoline to mitigate bad fpcasts on Emscripten (GH-32189)
https://github.com/python/cpython/commit/581c4434de62d9d36392f10e65866c081fb18d71


--
nosy: +miss-islington

___
Python tracker 

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

[issue47162] Add call trampoline to work around bad fpcasts on Emscripten

[Christian Heimes]

Change by Christian Heimes :


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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[Steve Dower]

Steve Dower  added the comment:

I'm still not convinced we should backport. Has anyone looked through to see 
whether this will actually affect any high valued error codes today?

--

___
Python tracker 

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

[issue47174] Define behavior of descriptor-typed fields on dataclasses

[Erik De Bonte]

New submission from Erik De Bonte :

Recent discussions about PEP 681 (dataclass_transform) have focused on support 
for descriptor-typed fields. See the email thread here: 
https://mail.python.org/archives/list/typing-...@python.org/thread/BW6CB6URC4BCN54QSG2STINU2M7V4TQQ/

Initially we were thinking that dataclass_transform needed a new parameter to 
switch between two modes. In one mode, it would use the default behavior of 
dataclass. In the other mode, it would be smarter about how descriptor-typed 
fields are handled. For example, __init__ would pass the value for a 
descriptor-typed field to the descriptor's __set__ method. However, Carl Meyer 
found that dataclass already has the desired behavior at runtime! We missed 
this because mypy and Pyright do not correctly mirror this runtime behavior.

Although this is the current behavior of dataclass, I haven't found it 
documented anywhere and the behavior is not covered by unit tests. Since 
dataclass_transform wants to rely on this behavior and the behavior seems 
desirable for dataclass as well, I'm proposing that we add additional dataclass 
unit tests to ensure that this behavior does not change in the future.

Specifically, we would like to document (and add unit tests for) the following 
behavior given a field whose default value is a descriptor:

1. The value passed to __init__ for that field is passed to the descriptor’s 
__set__ method, rather than overwriting the descriptor object.

2. Getting/setting the value of that field goes through __get__/__set__, rather 
than getting/overwriting the descriptor object.

Here's an example:

class Descriptor(Generic[T]):
def __get__(self, __obj: object | None, __owner: Any) -> T:
return getattr(__obj, "_x")

def __set__(self, __obj: object | None, __value: T) -> None:
setattr(__obj, "_x", __value)

@dataclass
class InventoryItem:
quantity_on_hand: Descriptor[int] = Descriptor[int]()

i = InventoryItem(13) # calls __set__ with 13
print(i.quantity_on_hand) # 13 -- obtained via call to __get__
i.quantity_on_hand = 29   # calls __set__ with 29
print(i.quantity_on_hand) # 29 -- obtained via call to __get__

I took a first stab at unit tests here: 
https://github.com/debonte/cpython/commit/c583e7c91c78c4aef65a1ac69241fc06ad95d436

We are aware of two other descriptor-related behaviors that may also be worth 
documenting:

First, if a field is annotated with a descriptor type but is *not* assigned a 
descriptor object as its default value, it acts like a non-descriptor field. 
Here's an example:

@dataclass
class InventoryItem:
quantity_on_hand: Descriptor[int] # No default value

i = InventoryItem(13)  # Sets quantity_on_hand to 13 -- No call to 
Descriptor.__set__
print(i.quantity_on_hand)  # 13 -- No call to Descriptor.__get__

And second, when a field with a descriptor object as its default value is 
initialized (when the code for the dataclass is initially executed), __get__ is 
called with a None instance and the return value is used as the field's default 
value. See the example below. Note that if __get__ doesn't handle this None 
instance case (for example, in the initial definition of Descriptor above), a 
call to InventoryItem() fails with "TypeError: InventoryItem.__init__() missing 
1 required positional argument: 'quantity_on_hand'".

I'm less sure about documenting this second behavior, since I'm not sure what 
causes it to work, and therefore I'm not sure how intentional it is.

class Descriptor(Generic[T]):
def __init__(self, *, default: T):
self._default = default

def __get__(self, __obj: object | None, __owner: Any) -> T:
if __obj is None:
return self._default

return getattr(__obj, "_x")

def __set__(self, __obj: object | None, __value: T) -> None:
if __obj is not None:
setattr(__obj, "_x", __value)

# When this code is executed, __get__ is called with __obj=None and the
# returned value is used as the default value of quantity_on_hand.
@dataclass
class InventoryItem:
quantity_on_hand: Descriptor[int] = Descriptor[int](default=100)

i = InventoryItem()   # calls __set__ with 100
print(i.quantity_on_hand) # 100 -- obtained via call to __get__

--
components: Library (Lib)
messages: 416392
nosy: JelleZijlstra, debonte, eric.smith
priority: normal
severity: normal
status: open
title: Define behavior of descriptor-typed fields on dataclasses
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

[issue47171] Enable py.exe install in Windows ARM64 installer

[Steve Dower]

Change by Steve Dower :


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

___
Python tracker 

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

Re: calling a function asynchronously

[Larry Martell]

On Wed, Mar 30, 2022 at 2:40 PM Kirill Ratkin via Python-list
 wrote:
>
> Hi again,
>
> I changed a bit your example and it works as you expected I hope.
>
> import asyncio
>
>
> async def long():
>  for i in range(100):
>  await asyncio.sleep(10)
>  print("long is done")
>
>
> loop = asyncio.get_event_loop()
>
> task = loop.create_task(long())
> print('after asyncio.run')
> loop.run_until_complete(asyncio.gather(task))
>
>
> But how I wrote before ... if you are in big Django project just look at
> existent django libraries for long task running. One of it I sent you.
> There is 'celery' as well.
>
> It's more pragmatic way ...

Appreciate the reply. I did not know about django-background-tasks -
thanks. I've been trying to make use of that. I do not get the errors
I was getting before but it does not appear that my long running task
is running at all. Still debugging. But concerting asyncio - doesn't
run_until_complete block until long() completes?

>
> 30.03.2022 19:10, Larry Martell пишет:
> > import asyncio
> > import time
> >
> > async def long():
> >  for i in range(100):
> > time.sleep(10)
> >
> > asyncio.run(long())
> > print('after asyncio.run')
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi again,

I changed a bit your example and it works as you expected I hope.

import asyncio


async def long():
    for i in range(100):
    await asyncio.sleep(10)
    print("long is done")


loop = asyncio.get_event_loop()

task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))


But how I wrote before ... if you are in big Django project just look at 
existent django libraries for long task running. One of it I sent you. 
There is 'celery' as well.


It's more pragmatic way ...

30.03.2022 19:10, Larry Martell пишет:

import asyncio
import time

async def long():
 for i in range(100):
time.sleep(10)

asyncio.run(long())
print('after asyncio.run')

--
https://mail.python.org/mailman/listinfo/python-list

Re: Add a method to list the current named logging levels

[Mats Wichmann]

On 3/30/22 10:39, Chris Angelico wrote:

> New in 3.11:
> 
> https://docs.python.org/3.11/library/logging.html#logging.getLevelNamesMapping
> 
> I'd say it's reasonable to use this, and then to backport it to older
> versions by monkeypatching it in (by referencing the internal). You
> potentially might have issues with other Python implementations, but
> I'm pretty sure CPython has logging._nameToLevel with the same
> semantics for quite a while.

since 2013, it looks like.


-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

[Guido van Rossum]

Guido van Rossum  added the comment:

Yeah, I see no description of what you can do with an unbound super object in 
the docs (https://docs.python.org/3/library/functions.html#super), and 
experimentation with it does not reveal any useful functionality.

You may want to open a new issue for this, and we'll probably have to propose a 
2-release deprecation period and start issuing a deprecation warning, in case 
there are nevertheless users (like autosuper clones).

--

___
Python tracker 

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

[issue47172] Make virtual opcodes in the compiler > 256 and is_jump() identify only proper jumps

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue47173] test_launcher fails on win-arm64 buildbot

[Steve Dower]

Steve Dower  added the comment:

Oh, I wonder if the VIRTUAL_ENV environment variable is interfering with search 
(as it's meant to, but the tests weren't written expecting to be run inside a 
venv).

--

___
Python tracker 

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

[issue47173] test_launcher fails on win-arm64 buildbot

[Steve Dower]

New submission from Steve Dower :

Test failures: https://buildbot.python.org/all/#/builders/730/builds/4307

==
FAIL: test_filter_to_company (test.test_launcher.TestLauncher)
--
Traceback (most recent call last):
  File 
"C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py",
 line 311, in test_filter_to_company
self.assertEqual("X.Y.exe", data["LaunchCommand"])
^^
AssertionError: 'X.Y.exe' != 
'C:\\Workspace\\buildarea\\venv_310\\Scripts\\python.exe'
- X.Y.exe
+ C:\Workspace\buildarea\venv_310\Scripts\python.exe
==
FAIL: test_py_default (test.test_launcher.TestLauncher)
--
Traceback (most recent call last):
  File 
"C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py",
 line 370, in test_py_default
self.assertEqual("PythonTestSuite", data["SearchInfo.company"])
^^^
AssertionError: 'PythonTestSuite' != '(null)'
- PythonTestSuite
+ (null)
==
FAIL: test_py_shebang (test.test_launcher.TestLauncher)
--
Traceback (most recent call last):
  File 
"C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py",
 line 392, in test_py_shebang
self.assertEqual("PythonTestSuite", data["SearchInfo.company"])
^^^
AssertionError: 'PythonTestSuite' != '(null)'
- PythonTestSuite
+ (null)

--
components: Windows
messages: 416389
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_launcher fails on win-arm64 buildbot
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

[issue47172] Make virtual opcodes in the compiler > 256 and is_jump() identify only proper jumps

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue47168] Improvements for stable ABI definition files

[Oleg Iarygin]

Oleg Iarygin  added the comment:

Probably, `regen-limited-abi` needs to be called from `regen-all` so 'Check if 
generated files are up to date' CI job will become aware of it.

--

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[miss-islington]

Change by miss-islington :


--
pull_requests: +30276
pull_request: https://github.com/python/cpython/pull/32199

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +30275
pull_request: https://github.com/python/cpython/pull/32198

___
Python tracker 

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

[issue46775] [Windows] OSError should unconditionally call winerror_to_errno

[Steve Dower]

Steve Dower  added the comment:


New changeset d0c67ea0645b7ad37b867c167882a346a24de641 by Dong-hee Na in branch 
'main':
bpo-46775: OSError should call winerror_to_errno unconditionally on Windows 
(GH-32179)
https://github.com/python/cpython/commit/d0c67ea0645b7ad37b867c167882a346a24de641


--

___
Python tracker 

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

[issue47172] Make virtual opcodes in the compiler > 256 and is_jump() identify only proper jumps

[Irit Katriel]

New submission from Irit Katriel :

There are a few "virtual opcodes" which are internal to the compiler. They can 
have values > 256. This way we don't waste any valid opcodes on them, and it is 
easier to detect when one of them escapes the compiler into the assemble stage.

In addition, there is an is_jump() function that treats the exception handling 
opcodes as jumps (and also assumes that any opcode >= SETUP_WITH is a jump):

static inline int
 is_jump(struct instr *i)
 {
return i->i_opcode >= SETUP_WITH || is_bit_set_in_table(_PyOpcode_Jump, 
i->i_opcode);
 }

Then there is is_block_push just for the three virtual exception block opcodes:

static inline int
is_block_push(struct instr *instr)
{
int opcode = instr->i_opcode;
return opcode == SETUP_FINALLY || opcode == SETUP_WITH || opcode == 
SETUP_CLEANUP;
}

We can make is_jump return true just for jumps, and call is_block_push as well 
when it is needed (currently sometimes we call is_jump when there cannot be 
virtual opcodes anymore so we can assert that instead, and in one place we call 
is_jump and then exclude the virtual opcodes. Both of these will become clearer 
after we make this change).

--
assignee: iritkatriel
components: Interpreter Core
messages: 416386
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Make virtual opcodes in the compiler > 256 and is_jump() identify only 
proper jumps
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

Re: Add a method to list the current named logging levels

[Tim Chase]

On 2022-03-30 16:37, Barry wrote:
> Is logging.getLevelNamesMapping() what you are looking for?

Is this in some version newer than the 3.8 that comes stock on my
machine?

  $ python3 -q
  >>> import logging
  >>> logging.getLevelNamesMapping()
  Traceback (most recent call last):
File "", line 1, in 
  AttributeError: module 'logging' has no attribute 'getLevelNamesMapping'

-tkc
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47168] Improvements for stable ABI definition files

[Oleg Iarygin]

Change by Oleg Iarygin :


--
nosy: +arhadthedev

___
Python tracker 

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

[issue47171] Enable py.exe install in Windows ARM64 installer

[Steve Dower]

New submission from Steve Dower :

Currently the launcher is not installed by the installer. We need to reenable 
it.

--
assignee: steve.dower
components: Windows
messages: 416385
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Enable py.exe install in Windows ARM64 installer
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

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Christian Ascia]

Christian Ascia  added the comment:

Thanks, it works now!

--
resolution:  -> fixed
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

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Paul Moore]

Paul Moore  added the comment:

This is Windows (shell) behaviour. To avoid this, you need to add the .py 
extension to the PATHEXT environment variable.

--

___
Python tracker 

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

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Christian Ascia]

Christian Ascia  added the comment:

It happens when i run "my-script.py".
I checked all terminal emulators on my system, it happens on PowerShell 7, in 
all Windows Terminal profiles (including cmd profile), in integrated terminals 
on vscode but not in cmd.

--

___
Python tracker 

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

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Steve Dower]

Steve Dower  added the comment:

Are you saying this happens when you run "py.exe my-script.py"? Or only when 
you run "my-script.py" (without the py.exe)?

--

___
Python tracker 

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

Re: Add a method to list the current named logging levels

[Chris Angelico]

On Thu, 31 Mar 2022 at 03:33, Edward Spencer  wrote:
>
> 在 2022年3月30日星期三 UTC+1 16:38:26， 写道：
> > > On 30 Mar 2022, at 16:11, Edward Spencer  wrote:
> > >
> > > 在 2021年9月3日星期五 UTC+1 18:50:51， 写道：
> >  On 2 Sep 2021, at 23:38, Dieter Maurer  wrote:
> > >>>
> > >>> Edward Spencer wrote at 2021-9-2 10:02 -0700:
> >  Sometimes I like to pass the logging level up to the command line 
> >  params so my user can specific what level of logging they want. 
> >  However there is no easy method for pulling the named logging level 
> >  names.
> > 
> >  Looking into the code, it would actually be incredibly easy to 
> >  implement;
> > 
> >  in `logging.__init__.py`;
> > 
> >  def listLevelNames():
> >  return _nameToLevel.keys()
> > 
> >  You could obviously add some other features, like listing only the 
> >  defaults, sorted by numerical level or alphabetically, etc. But really 
> >  this basic implementation would be enough to expose the internal 
> >  variables which shouldn't be accessed because they change (and in 
> >  fact, between python 2 and 3, they did).
> > 
> >  Any thoughts?
> > >>>
> > >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING",
> > >>> "ERROR" and "CRITICAL".
> > >>> No need to provide a special function listing those levels.
> > >> I add my own levels, but then I know I did it.
> > >>
> > >> Barry
> > >>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Dieter
> > >>> --
> > >>> https://mail.python.org/mailman/listinfo/python-list
> > >>>
> > >
> > > Yes, the names are already well defined. But every software project 
> > > anyone has that needs to use logging then has to define that list, which 
> > > is a waste of time since they're already defined inside the logging repo. 
> > > But no-one can access them unless they use protected variables. If it's a 
> > > case of not wanting users to be able to modify the defaults, then just 
> > > define that list of log levels as a tuple. Hiding it is unnecessary.
> > Is logging.getLevelNamesMapping() what you are looking for?
> >
> > Barry
> >
> >
> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
>
> Hi Barry,
>
> What version for python / logging are you seeing that method in? I don't 
> appear to be able to find it.
> I vaguely remember seeing something similar to it though, did it return a 
> dict of {: } only or did it also include the reverse of 
> int to str?
>

New in 3.11:

https://docs.python.org/3.11/library/logging.html#logging.getLevelNamesMapping

I'd say it's reasonable to use this, and then to backport it to older
versions by monkeypatching it in (by referencing the internal). You
potentially might have issues with other Python implementations, but
I'm pretty sure CPython has logging._nameToLevel with the same
semantics for quite a while.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Add a method to list the current named logging levels

[Edward Spencer]

在 2022年3月30日星期三 UTC+1 16:38:26， 写道：
> > On 30 Mar 2022, at 16:11, Edward Spencer  wrote:
> > 
> > 在 2021年9月3日星期五 UTC+1 18:50:51， 写道： 
>  On 2 Sep 2021, at 23:38, Dieter Maurer  wrote: 
> >>> 
> >>> Edward Spencer wrote at 2021-9-2 10:02 -0700: 
>  Sometimes I like to pass the logging level up to the command line params 
>  so my user can specific what level of logging they want. However there 
>  is no easy method for pulling the named logging level names. 
>  
>  Looking into the code, it would actually be incredibly easy to 
>  implement; 
>  
>  in `logging.__init__.py`; 
>  
>  def listLevelNames(): 
>  return _nameToLevel.keys() 
>  
>  You could obviously add some other features, like listing only the 
>  defaults, sorted by numerical level or alphabetically, etc. But really 
>  this basic implementation would be enough to expose the internal 
>  variables which shouldn't be accessed because they change (and in fact, 
>  between python 2 and 3, they did). 
>  
>  Any thoughts? 
> >>> 
> >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", 
> >>> "ERROR" and "CRITICAL". 
> >>> No need to provide a special function listing those levels. 
> >> I add my own levels, but then I know I did it. 
> >> 
> >> Barry 
> >> 
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Dieter 
> >>> -- 
> >>> https://mail.python.org/mailman/listinfo/python-list 
> >>> 
> > 
> > Yes, the names are already well defined. But every software project anyone 
> > has that needs to use logging then has to define that list, which is a 
> > waste of time since they're already defined inside the logging repo. But 
> > no-one can access them unless they use protected variables. If it's a case 
> > of not wanting users to be able to modify the defaults, then just define 
> > that list of log levels as a tuple. Hiding it is unnecessary.
> Is logging.getLevelNamesMapping() what you are looking for? 
> 
> Barry 
> 
> 
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list

Hi Barry,

What version for python / logging are you seeing that method in? I don't appear 
to be able to find it.
I vaguely remember seeing something similar to it though, did it return a dict 
of {: } only or did it also include the reverse of int to 
str?

Thanks,
Ed
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Christian Ascia]

New submission from Christian Ascia :

Hi, as the title describes, i noticed this unfornutate behavior preventing me 
to run directly python scripts in terminal without using the py command. I 
searched in the documentation but i couldn't find flags to prevent py launcher 
from opening a new window.

--
components: Windows
messages: 416380
nosy: asciachristian, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py launcher on windows opens new terminal window when parsing python 
script with shebang
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

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi,

You can use asyncio.create_task and gather results. See docs -
https://docs.python.org/3/library/asyncio-task.html

But think twice what you want to do in async task. Do you use synchronous
requests to database? If yes it will blocks eventloop...

If you use Django it makes sense to use something like
'django-background-tasks'

It just saves your time possibly.

// BR

ср, 30 мар. 2022 г., 19:14 Larry Martell :

> I have a django app, and for a certain request I need to kick off a
> long running task. I want to do this asynchronously and immediately
> return a response. I tried using subprocess.Process() but the forked
> process does not have a django database connection. I then tried
> posting a request using ajax but that does not have a django session
> so it's not authorized. Tried using asyncio but I am finding the
> caller of the async function does not return until the async function
> returns - maybe I am doing something wrong, as it does appear to be
> actually asynchronous. I tried this test:
>
> import asyncio
> import time
>
> async def long():
> for i in range(100):
>time.sleep(10)
>
> asyncio.run(long())
> print('after asyncio.run')
>
> The final print does not come out until after long() completes.
>
> Is there any way to do this?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47146] PR check "Check if generated files are up to date" failing intermittently

[Eric Snow]

Eric Snow  added the comment:

Looks like this is still an intermittent problem:

* https://github.com/python/cpython/pull/32195
  + failed: https://github.com/python/cpython/runs/5756616733
  + failed: https://github.com/python/cpython/runs/5753267869
  + failed: https://github.com/python/cpython/runs/5757169625
* https://github.com/python/cpython/pull/32114
  + failed: https://github.com/python/cpython/runs/5756616733
  + passed: https://github.com/python/cpython/runs/5757213346
* https://github.com/python/cpython/pull/32186
  + failed: ...
  + passed: https://github.com/python/cpython/runs/5757178754


Per Mark Shannon (on discord):

The "Check if generated files are up to date" is still failing consistently. It 
looks like the makefile is missing a dependency on the 
./Programs/_freeze_module for targets that require /Programs/_freeze_module

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

___
Python tracker 

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

calling a function asynchronously

[Larry Martell]

I have a django app, and for a certain request I need to kick off a
long running task. I want to do this asynchronously and immediately
return a response. I tried using subprocess.Process() but the forked
process does not have a django database connection. I then tried
posting a request using ajax but that does not have a django session
so it's not authorized. Tried using asyncio but I am finding the
caller of the async function does not return until the async function
returns - maybe I am doing something wrong, as it does appear to be
actually asynchronous. I tried this test:

import asyncio
import time

async def long():
for i in range(100):
   time.sleep(10)

asyncio.run(long())
print('after asyncio.run')

The final print does not come out until after long() completes.

Is there any way to do this?
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Petr Viktorin]

Petr Viktorin  added the comment:

> Ah, sorry, I could have described the issue better. It's not a problem with 
> exporting, PyThread_get_thread_native_id() isn't available on Solaris (and 
> possibly other platforms) at all.

Jakub, does this mean test_stable_abi_ctypes fails on Solaris?
Are there any other missing functions?
I opened bpo-47169 to improve the situation.

--

___
Python tracker 

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

[issue47169] Stable ABI: Some optional (#ifdef'd) functions aren't handled correctly

[Petr Viktorin]

New submission from Petr Viktorin :

- PyThread_get_thread_native_id is only available when PY_HAVE_THREAD_NATIVE_ID 
is defined. The test currently always expects it to be available.
- PyOS_CheckStack is only available when USE_STACKCHECK is defined (i.e. on 
Windows). It should be exported from the DLL.

I plan to:
- add the appropriate metadata
- improve handling & testing of such optional functions in general

--
components: C API
messages: 416377
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Stable ABI: Some optional (#ifdef'd) functions aren't handled correctly

___
Python tracker 

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

[issue47168] Improvements for stable ABI definition files

[Petr Viktorin]

New submission from Petr Viktorin :

This issue groups together a few changes I'd like to make:

- Rename Doc/data/stable_abi.dat to *.csv, so it gets syntax highlighting. (The 
only user of that file should be the Sphinx extension)
- Mark autogenerated files as such in .gitattributes
- Convert Misc/stable_abi.txt to TOML, and change the parser to match (this 
will need a heads-up on python-dev)

--
messages: 416376
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Improvements for stable ABI definition files

___
Python tracker 

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

[issue24837] await process.wait() does not work with a new_event_loop

[Guido van Rossum]

Guido van Rossum  added the comment:

Okay let's close it then. :-)

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

Re: Add a method to list the current named logging levels

[Barry]

> On 30 Mar 2022, at 16:11, Edward Spencer  wrote:
> 
> 在 2021年9月3日星期五 UTC+1 18:50:51， 写道：
 On 2 Sep 2021, at 23:38, Dieter Maurer  wrote:
>>> 
>>> Edward Spencer wrote at 2021-9-2 10:02 -0700: 
 Sometimes I like to pass the logging level up to the command line params 
 so my user can specific what level of logging they want. However there is 
 no easy method for pulling the named logging level names. 
 
 Looking into the code, it would actually be incredibly easy to implement; 
 
 in `logging.__init__.py`; 
 
 def listLevelNames(): 
 return _nameToLevel.keys() 
 
 You could obviously add some other features, like listing only the 
 defaults, sorted by numerical level or alphabetically, etc. But really 
 this basic implementation would be enough to expose the internal variables 
 which shouldn't be accessed because they change (and in fact, between 
 python 2 and 3, they did). 
 
 Any thoughts? 
>>> 
>>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", 
>>> "ERROR" and "CRITICAL". 
>>> No need to provide a special function listing those levels.
>> I add my own levels, but then I know I did it. 
>> 
>> Barry 
>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dieter 
>>> -- 
>>> https://mail.python.org/mailman/listinfo/python-list 
>>> 
> 
> Yes, the names are already well defined. But every software project anyone 
> has that needs to use logging then has to define that list, which is a waste 
> of time since they're already defined inside the logging repo. But no-one can 
> access them unless they use protected variables. If it's a case of not 
> wanting users to be able to modify the defaults, then just define that list 
> of log levels as a tuple. Hiding it is unnecessary.

Is logging.getLevelNamesMapping() what you are looking for?

Barry


> -- 
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47168] Improvements for stable ABI definition files

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

[issue47167] Allow overriding future-task compliance check in asyncio

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue47167] Allow overriding future-task compliance check in asyncio

[Andrew Svetlov]

New submission from Andrew Svetlov :

Now asyncio.Task has a strict hardcoded check for futures processes on task's 
step.
Sometimes third-party library [1] wants to replace it with custom logic.
Currently it is impossible without implementing the full asyncio.Task 
replacement from scratch.
`asyncio.Task` is a non-trivial highly optimized part of async, keeping a 
third-party version in sync with the reference implementation takes more time 
and effort than it should be.

This issue proposes adding `Task._check_future(future)` method that could be 
overridden in subclasses.  The default C implementation uses a fast path that 
has no performance penalty.

1. https://github.com/aio-libs/aioloop-proxy implements nested loop proxies 
that are very useful for writing tests. A proxy can work in parallel with 
ancestors but checks all own acquired resources cleanup on 
the proxy closing.

--
components: asyncio
messages: 416374
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Allow overriding future-task compliance check in  asyncio
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

Re: Python Qualification?

[Barry]

> On 30 Mar 2022, at 15:40, alister.ware  wrote:
> 
> OK
> 
> where do you work & are there any vacancies (a junior position would suffice)

At the moment we are only hiring in India and for senior rolls.

Barry

> 
>> On 30/03/2022 14:52, Barry wrote:
>> 
 On 29 Mar 2022, at 20:37, alister via Python-list  
 wrote:
>>> 
>>> I'm currently considering a career change (not much choice actually just
>>> been made redundant).
>>> I'd like to be able to turn my interest in python to my advantage, What
>>> qualifications do employers look for?
>> Where I work we use python in the product and look for expertise in
>> object oriented design and python expertise. But will take people with
>> no python expertise if they are willing the learn python and have experience
>> of other OO languages, C+c, Java, etc.
>> 
>> We do not look for formal qualifications.
>> 
>> Barry
>> 
>>> 
>>> 
>>> -- 
>>> I'm reporting for duty as a modern person.  I want to do the Latin Hustle
>>> now!
>>> -- 
>>> https://mail.python.org/mailman/listinfo/python-list
>>> 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46964] The global config should not be stored on each interpreter

[STINNER Victor]

STINNER Victor  added the comment:

> If the invariant bits are moved out, then it clearly indicates when code can 
> safely assume that every interpreter will be seeing the same value.

What is the benefit of that? Do you have an example?

--

___
Python tracker 

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

[issue47115] Documentation inconsistency with the stable ABI

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

Re: Python Qualification?

[alister via Python-list]

On Tue, 29 Mar 2022 20:49:53 -0400, Dennis Lee Bieber wrote:

> On Tue, 29 Mar 2022 19:26:03 - (UTC), alister
>  declaimed the following:
> 
>>I'm currently considering a career change (not much choice actually just
>>been made redundant).
>>I'd like to be able to turn my interest in python to my advantage, What
>>qualifications do employers look for?
> 
>   Strangely -- knowledge of Python was never a consideration in my
> history... Having a familiarity with multiple languages, software
> engineering principles, and requirements/design analysis were larger
> factors.
> 
>   Python was something I used in support of the primary task, but 
was not
> the end-product itself (for example, an evaluation of various secure
> network filtering hardware, by sending serial numbered packets out one
> NIC,
> through the filter, and in through a second NIC; capturing both out
> via Wireshark; later merging the two captures into a single file of time
> delays, and plotting the timing of the packets intended to pass through
> and verifying that "classified" contents were blocked or sanitized).

Pretty much where I am (only less so) I have used python & flask to make a 
reasonably sucsessfull web app for my fellow engineers at work, lots of 
stuff with home Raspberry pi robotics but no formal qualifications in the 
field.



-- 
Earth is a beta site.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47099] Replace with_traceback() with exception chaining and reraising

[Oleg Iarygin]

Change by Oleg Iarygin :


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

Re: Add a method to list the current named logging levels

[Edward Spencer]

在 2021年9月3日星期五 UTC+1 18:50:51， 写道：
> > On 2 Sep 2021, at 23:38, Dieter Maurer  wrote:
> > 
> > Edward Spencer wrote at 2021-9-2 10:02 -0700: 
> >> Sometimes I like to pass the logging level up to the command line params 
> >> so my user can specific what level of logging they want. However there is 
> >> no easy method for pulling the named logging level names. 
> >> 
> >> Looking into the code, it would actually be incredibly easy to implement; 
> >> 
> >> in `logging.__init__.py`; 
> >> 
> >> def listLevelNames(): 
> >> return _nameToLevel.keys() 
> >> 
> >> You could obviously add some other features, like listing only the 
> >> defaults, sorted by numerical level or alphabetically, etc. But really 
> >> this basic implementation would be enough to expose the internal variables 
> >> which shouldn't be accessed because they change (and in fact, between 
> >> python 2 and 3, they did). 
> >> 
> >> Any thoughts? 
> > 
> > Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", 
> > "ERROR" and "CRITICAL". 
> > No need to provide a special function listing those levels.
> I add my own levels, but then I know I did it. 
> 
> Barry 
> 
> > 
> > 
> > 
> > -- 
> > Dieter 
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list 
> >

Yes, the names are already well defined. But every software project anyone has 
that needs to use logging then has to define that list, which is a waste of 
time since they're already defined inside the logging repo. But no-one can 
access them unless they use protected variables. If it's a case of not wanting 
users to be able to modify the defaults, then just define that list of log 
levels as a tuple. Hiding it is unnecessary.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47164] [C API] Add private "CAST" macros to clean up casts in C code

[STINNER Victor]

STINNER Victor  added the comment:

> I've had to debug a segfault before only because the inline function 
> implicitly cast its arguments, and it was accessing a non-existent member. If 
> it were a macro it would access the struct member directly, and the compiler 
> would be able to catch that and warn me before runtime.

This is part of Python C API legacy and as I wrote, it's not going to change 
soon. The minor enhancement that we can do is to inject an assertion when 
Python is built in debug mode.

--

___
Python tracker 

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

[issue47092] [C API] Add PyFrame_GetVar(frame, name) function

[Nick Coghlan]

Nick Coghlan  added the comment:

Mark's suggested frame stack API makes sense to me, but being able to get/set 
specific values through the full frame API seems like it would be useful even 
if the lower level API existed - if we don't get one of the proxy PEPs in shape 
to land in 3.11, trace functions written in C could still use this to avoid 
materialising the locals dict if they only needed to manipulate specific values.

Even after a fast locals proxy is defined, there would still be some saving in 
skipping creating the proxy object when only accessing known keys.

We'd need the name-to-index mapping on the code objects to implement this API 
efficiently, but that isn't a PEP level change in its own right (the proxy PEPs 
only mention it because they need it)

--

___
Python tracker 

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

[issue47115] Documentation inconsistency with the stable ABI

[Petr Viktorin]

Petr Viktorin  added the comment:

So. According to PEP 384 (which added all structs in the stable ABI, except 
Py_buffer), some structs are opaque and others have a few members exposed:
https://peps.python.org/pep-0384/#structures

I will split the latter into 1) structs that have a few fields exposed mainly 
for backwards compatibility (which, of course, is very important here). Best 
practice is to treat them as opaque (use getters/setters):

- PyObject (ob_refcnt, ob_type)
- PyVarObject (ob_base, ob_size)

... and 2) structs for which all fields are part of the ABI (and the struct's 
size as well: for most of these as users are expected to provide arrays):

- PyMethodDef
- PyMemberDef
- PyGetSetDef
- PyModuleDefBase
- PyModuleDef
- PyStructSequence_Field
- PyStructSequence_Desc
- PyType_Slot
- PyType_Spec
- Py_buffer (new in 3.11)

The opaque structs continue to be:

- PyThreadState
- PyInterpreterState
- PyFrameObject
- symtable
- PyWeakReference
- PyLongObject
- PyTypeObject

--
nosy: +vstinner

___
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

[Ethan Furman]

Ethan Furman  added the comment:

Éric Araujo wrote on PR30520:

> No, we should not redefine the behavior of urlparse.
> 
> I was always talking about adding another function. Yes it can be a one-liner,
> but my point is that I don’t see the usefulness of having the separate flags 
> to
> pick and choose parts of standard parsing.

I suspect the usefulness comes from error checking -- if a scheme doesn't 
support parameters, then having what looks like parameters converted would not 
be helpful.

Further, while a new function is definitely safer, how many parse options do we 
need?  Anyone else remember `os.popen()`, `os.popen2`, `os.popen3`, and, 
finally, `os.popen4()`?

Assuming we just enhance the existing function, would it be more palatable if 
there was a `SchemeFlag.ALL`, so universal parsing was just 
`urlparse(uri_string, flags=SchemeFlag.ALL)`?  To be really user-friendly, we 
could have:

class SchemeFlag(Flag):
RELATIVE = auto()
NETLOC = auto()
PARAMS = auto()
UNIVERSAL = RELATIVE | NETLOC | PARAMS
#
def __repr__(self):
return f"{self.module}.{self._name_}"
__str__ = __repr__
RELATIVE, NETLOC, PARAMS, UNIVERSAL = SchemeFlag

Then the above call becomes:

urlparse(uri_string, flags=UNIVERSAL)

--

___
Python tracker 

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

[issue47161] pathlib method relative_to doesnt work with // in paths

[Oleg Iarygin]

Change by Oleg Iarygin :


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

___
Python tracker 

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

[issue47166] Dataclass transform should ignore TypeAlias variables

[Thomas MK]

New submission from Thomas MK :

The dataclass transformation ignores attributes that are annotated as ClassVar. 
I think it should also ignore attributes that are annotated as TypeAlias.

Specifically, I have this usecase in mind:


class RunMode(Enum):
release = auto()
debug = auto()

@dataclass
class Run:
Mode: TypeAlias = RunMode
mode: Mode = Mode.release

--
components: Library (Lib)
messages: 416368
nosy: thomkeh
priority: normal
severity: normal
status: open
title: Dataclass transform should ignore TypeAlias variables
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue36692] Unexpected stderr output from test_sys_settrace

[Nick Coghlan]

Nick Coghlan  added the comment:

I'm not, so I assume this got cleaned up somewhere along the way.

--
resolution:  -> out of date
stage: needs patch -> 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

[issue46964] The global config should not be stored on each interpreter

[Nick Coghlan]

Nick Coghlan  added the comment:

I agree the status quo has its benefits. However, it has the distinct downside 
that because each interpreter has its own storage for copied settings, other 
code has to assume the settings *might* be different in each interpreter, even 
if they're currently always the same.

If the invariant bits are moved out, then it clearly indicates when code can 
safely assume that every interpreter will be seeing the same value.

--

___
Python tracker 

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

[issue47164] [C API] Add private "CAST" macros to clean up casts in C code

[Ken Jin]

Ken Jin  added the comment:

@Victor,

I'm not against (A) or any of the PRs you proposed. They look fine to me. My 
concern was with certain static inline functions (there are none here :). The 
_CAST macros have genuinely helped me debug code before.

--

___
Python tracker 

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

[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes

[Nick Coghlan]

Nick Coghlan  added the comment:

Seems reasonable to me, but I think a full implementation would want to throw 
an error for keyword args that don't already exist as context attributes 
(otherwise typos would fail silently)

--

___
Python tracker 

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

[issue47164] [C API] Add private "CAST" macros to clean up casts in C code

[STINNER Victor]

STINNER Victor  added the comment:

GH-32192 "Add _PyCFunction_CAST() macro" is special. It's used to define 
functions in PyTypeObject.tp_methods or PyModuleDef.m_methods.

Casting a function pointer can cause issues with Control Flow Integrity (CFI) 
implemented in LLVM. The _thread module has an undefined behavior fixed by the 
commit 9eea6eaf23067880f4af3a130e3f67c9812e2f30 of bpo-33015. Previously, a 
cast ignored that the callback has no return value, whereas pthread_create() 
requires a function which as a void* return value.

To fix compiler warnings, the (PyCFunction)func cast was replaced with the 
(PyCFunction)(void(*)(void))func cast to fix bpo-bpo-33012 GCC 8 compiler 
warning:

warning: cast between incompatible function types (...)

--

___
Python tracker 

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

[issue47164] [C API] Add private "CAST" macros to clean up casts in C code

[STINNER Victor]

STINNER Victor  added the comment:

Hum, there are two things and maybe we are not talking about the same thing.

* (A) Modifying macros defined in the Python C API (Include/ header files) 
doing cast on their arguments to use CAST macros
* (B) Modify C code doing casts to use CAST macros

I created this issue for (A). I propose to do (B), but this part is optional.

Mark, Ken: are you fine with (A)? Is your concern about (B)?

But modifying macros to remove the cast of their argument is out of the scope 
of this issue. As I wrote, it would add compiler warnings, something that I 
would like to avoid. See:
https://peps.python.org/pep-0670/#cast-pointer-arguments

--

___
Python tracker 

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

[issue47164] [C API] Add private "CAST" macros to clean up casts in C code

[STINNER Victor]

STINNER Victor  added the comment:

> By the way, the current Python C API is not fully compatible with C++. (...)

I created bpo-47165 "[C API] Test that the Python C API is compatible with C++".

--

___
Python tracker 

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

[issue39355] The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword

[STINNER Victor]

STINNER Victor  added the comment:

Follow-up issue: bpo-47165 "[C API] Test that the Python C API is compatible 
with C++".

--

___
Python tracker 

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

[issue47165] [C API] Test that the Python C API is compatible with C++

[STINNER Victor]

New submission from STINNER Victor :

There are more and more popular projects using the Python C API. The first big 
player is pybind11:
"Seamless operability between C++11 and Python"
https://pybind11.readthedocs.io/

Recently, I proposed a PR to add Python 3.11 support to the datatable project:
https://github.com/h2oai/datatable/pull/3231

My PR uses pythoncapi_compat.h header file which provides recent C API 
functions to old Python functions. The header file implements these functions 
as static inline function.

Problem: a static inline function implemented in a C header file used in a C++ 
code file can emit C++ compiler warnings.

In datatable, I got two kinds of C++ compiler warnings:

* Usage of the C NULL constant: C++ prefers nullptr
* "Old-style" cast like (PyObject*)obj: C++ prefers static_cast, 
reinterpret_cast, etc.

It seems like these compiler warnings are not enabled by default. The datatable 
project seems enabling them in its CI and I was asked to fix these warnings.

In the pythoncapi-compat project (*), I chose to use nullptr and 
reinterpret_cast if the "__cplusplus" macro is defined. Example:

---
// C++ compatibility
#ifdef __cplusplus
#  define PYCAPI_COMPAT_CAST(TYPE, EXPR) reinterpret_cast(EXPR)
#  define PYCAPI_COMPAT_NULL nullptr
#else
#  define PYCAPI_COMPAT_CAST(TYPE, EXPR) ((TYPE)(EXPR))
#  define PYCAPI_COMPAT_NULL NULL
#endif

// Cast argument to PyObject* type.
#ifndef _PyObject_CAST
#  define _PyObject_CAST(op) PYCAPI_COMPAT_CAST(PyObject*, op)
#endif
---

(*) https://github.com/python/pythoncapi_compat


It's unclear to me if the Python C API has or has not the same issue than 
pythoncapi_compat.h.


Last years, some old macros of the Python C API have been converted to static 
inline functions, like Py_INCREF(). It's unclear to me if these compiler 
warnings happen on Py_INCREF(). I don't understand why, but static inline 
macros from Python.h didn't emit compiler warnings in datatable, whereas 
similar static inline functions of pythoncapi_compat.h emitted compiler 
warnings.

Maybe there is a difference between  and "Python.h". Or maybe it 
depends if the header file is a "local" file, or a "system" header file (ex: 
installed in /usr/include/ on Linux).


A first step would be to build a C++ extension as part of the Python test suite 
and check that there is no compiler warning. My GH-32175 PR is a 
proof-of-concept of that.

I don't know which C++ version we should target. pybind11 targets C++11. See 
bpo-39355 for a discussion about C++20: usage of the C++20 "module" keyword... 
which is a "contextual keyword" in practice.

--
components: C API
messages: 416359
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Test that the Python C API is compatible with C++
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