[issue37242] sub-process would be terminated when registered finalizer are working

[mrqianjinsi]

New submission from mrqianjinsi :

Hi guys.
I'm using multiprocessing module to accelerate my program. and I want to do 
some cleanup work when sub-process exit. 
but I found that sub-process would be terminated when registered finalizer are 
working.

Is this behavior designed intentionally?

code example:

import multiprocessing as mp
from multiprocessing.util import Finalize
import os
import time

def finalizer():
time.sleep(0.2) # some time consuming work
print('do cleanup work: {}'.format(os.getpid()))

def worker(_):
print('do some work: {}'.format(os.getpid()))

def initializer():
# ref: 
https://github.com/python/cpython/blob/master/Lib/multiprocessing/util.py#L147
Finalize(None, finalizer, exitpriority=1)

# atexit module don't work along with multiprocessing module
# because sub-process exit via os._exit()
# ref: https://docs.python.org/3/library/atexit.html
# atexit.register(finalizer)  # don't work

print('main process ID: {}'.format(os.getpid()))
with mp.Pool(4, initializer=initializer) as executor:
executor.map(worker, range(20))


gist link: https://gist.github.com/MrQianJinSi/2daf5b6a9ef08b00facdfbea5200dd28

--
components: Library (Lib)
messages: 345310
nosy: mrqianjinsi
priority: normal
severity: normal
status: open
title: sub-process  would be terminated when registered finalizer are working
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue37242] sub-process would be terminated when registered finalizers are working

[mrqianjinsi]

Change by mrqianjinsi :


--
title: sub-process  would be terminated when registered finalizer are working 
-> sub-process  would be terminated when registered finalizers are working

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Adding Petr, that was involved with the "tp_print" to "tp_vectorcall" renaming.

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue37087] Adding native id support for openbsd

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +13872
pull_request: https://github.com/python/cpython/pull/13624

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Technically, tp_print was replaced by tp_vectorcall_offset.

But that doesn't answer the question how we should deal with tp_print backwards 
compatibility. Cython does

FooType.tp_print = 0;

With this in mind, simply replacing tp_print by tp_vectorcall_offset is unsafe 
as it would break types that actually use vectorcall (there aren't many for 
now, but who knows how this will change in the future).

It would be safer to replace tp_print by tp_vectorcall since setting that to 0 
won't break anything (neither for now, nor when PR 13930 is merged).

--

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Jeroen Demeyer]

Change by Jeroen Demeyer :


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

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

PR 14009 deals with tp_print

--

___
Python tracker 

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

[issue37243] test_sendfile in asyncio crashes when os.sendfile() is not supported

[Michael Felt]

New submission from Michael Felt :

issue34655 added sendfile support to asyncio. However, the `test_sendfile` 
fails when called if there is no os.sendfile support.

This patch will skip the test when 

@unittest.skipUnless(hasattr(os, 'sendfile'), 'test needs os.sendfile()')

--
messages: 345314
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_sendfile in asyncio crashes when os.sendfile() is not supported

___
Python tracker 

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

[issue26219] implement per-opcode cache in ceval

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 996e52623af3854552d41751e0c2522bc0a7e84f by Victor Stinner (Miss 
Islington (bot)) in branch '3.8':
bpo-26219: Fix compiler warning in _PyCode_InitOpcache() (GH-13997) (GH-14000)
https://github.com/python/cpython/commit/996e52623af3854552d41751e0c2522bc0a7e84f


--

___
Python tracker 

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

[issue37242] sub-process would be terminated when registered finalizers are still running

[mrqianjinsi]

Change by mrqianjinsi :


--
title: sub-process  would be terminated when registered finalizers are working 
-> sub-process  would be terminated when registered finalizers are still running

___
Python tracker 

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

[issue37243] test_sendfile in asyncio crashes when os.sendfile() is not supported

[Michael Felt]

Change by Michael Felt :


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

___
Python tracker 

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

[issue37226] Asyncio Fatal Error on SSL Transport - IndexError Deque Index Out Of Range

[Ben Brown]

Ben Brown  added the comment:

I have created a minimal example if that helps to show the issue 
https://gist.github.com/bobthemac/031213b8e37960ee805f2ae1e6990b60

--

___
Python tracker 

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

[issue37226] Asyncio Fatal Error on SSL Transport - IndexError Deque Index Out Of Range

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Thank you!
Yuri, you might be interested too

--

___
Python tracker 

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +13875
pull_request: https://github.com/python/cpython/pull/14011

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[STINNER Victor]

STINNER Victor  added the comment:

> Note that PyCode_New() is not the only change in 3.8 beta1 that breaks Cython 
> generated code. The renaming of "tp_print" to "tp_vectorcall" is equally 
> disruptive, because Cython has (or had) a work-around for CPython 
> (mis-)behaviour that reset the field explicitly to NULL after calling 
> PyType_Ready(), which could set it arbitrarily without good reason.

Can someone please open a separated issue to discuss tp_print backward 
incompatible change? This issue is about PyCode_New().

--

___
Python tracker 

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

[issue37087] Adding native id support for openbsd

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests:  -13872

___
Python tracker 

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

[issue37111] Logging - Inconsistent behaviour when handling unicode

[Inada Naoki]

Inada Naoki  added the comment:

Hmm,, about encoding, I agree that default encoding of open() should be used.
If we change it, encoding of log files are changed unexpectedly after upgrading 
Python.

On the other hand, couldn't we use different default error handler?
"replace" or "backslashescape" seems better default error handler for the 
logging.
Is this change affects too many users?

--
nosy: +inada.naoki

___
Python tracker 

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

[issue36888] Create a way to check that the parent process is alive for deamonized processes

[STINNER Victor]

STINNER Victor  added the comment:

This new test is not reliable, it failed on x86 Gentoo Refleaks 3.8:
https://buildbot.python.org/all/#/builders/223/builds/9

Please fix the test or revert the change. The CI must remain green ;-)


running: test_multiprocessing_spawn (31 min 51 sec), 
test_multiprocessing_forkserver (3 min 7 ms)
3:20:42 load avg: 6.89 [415/423/1] test_multiprocessing_spawn failed (31 min 30 
sec) -- running: test_multiprocessing_forkserver (3 min 7 sec)
beginning 6 repetitions
123456
Process Process-1588:1:
Traceback (most recent call last):
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/process.py",
 line 313, in _bootstrap
self.run()
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/process.py",
 line 108, in run
self._target(*self._args, **self._kwargs)
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py",
 line 326, in _test_report_parent_status
wconn.send("alive" if parent_process().is_alive() else "not alive")
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/connection.py",
 line 206, in send
self._send_bytes(_ForkingPickler.dumps(obj))
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/connection.py",
 line 411, in _send_bytes
self._send(header + buf)
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/connection.py",
 line 368, in _send
n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
Warning -- Dangling processes: {}
Warning -- Dangling processes: {}
Warning -- multiprocessing.process._dangling was modified by 
test_multiprocessing_spawn
  Before: set()
  After:  {} 
test test_multiprocessing_spawn failed -- Traceback (most recent call last):
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py",
 line 305, in test_parent_process
raise AssertionError("Could not communicate with child process")
AssertionError: Could not communicate with child process

/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/resource_tracker.py:203:
 UserWarning: resource_tracker: There appear to be 1 leaked shared_memory 
objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/resource_tracker.py:216:
 UserWarning: resource_tracker: '//psm_b32d1a2f': [Errno 2] No such file or 
directory: '//psm_b32d1a2f'
  warnings.warn('resource_tracker: %r: %s' % (name, e))

(...)

Re-running test_multiprocessing_spawn in verbose mode

==
FAIL: test_parent_process 
(test.test_multiprocessing_spawn.WithProcessesTestProcess)
--
Traceback (most recent call last):
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py",
 line 305, in test_parent_process
raise AssertionError("Could not communicate with child process")
AssertionError: Could not communicate with child process

--
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue37244] test_multiprocessing_forkserver: test_resource_tracker() failed on x86 Gentoo Refleaks 3.8

[STINNER Victor]

New submission from STINNER Victor :

x86 Gentoo Refleaks 3.8:
https://buildbot.python.org/all/#/builders/223/builds/9

3:22:46 load avg: 5.83 [423/423/2] test_multiprocessing_forkserver failed (5 
min 10 sec)
beginning 6 repetitions
123456
./buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py:5002:
 ResourceWarning: unclosed file <_io.BufferedReader name=10>
  p = subprocess.Popen([sys.executable,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
test test_multiprocessing_forkserver failed -- Traceback (most recent call 
last):
  File 
"/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py",
 line 5015, in test_resource_tracker
_resource_unlink(name2, rtype)
AssertionError: OSError not raised

/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/resource_tracker.py:203:
 UserWarning: resource_tracker: There appear to be 1 leaked shared_memory 
objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/buildbot/buildarea/cpython/3.8.ware-gentoo-x86.refleak/build/Lib/multiprocessing/resource_tracker.py:216:
 UserWarning: resource_tracker: '//psm_dfd85228': [Errno 2] No such file or 
directory: '//psm_dfd85228'
  warnings.warn('resource_tracker: %r: %s' % (name, e))

---

Test added by:

commit f22cc69b012f52882d434a5c44a004bc3aa5c33c
Author: Pierre Glaser 
Date:   Fri May 10 22:59:08 2019 +0200

bpo-36867: Make semaphore_tracker track other system resources (GH-13222)

The multiprocessing.resource_tracker replaces the 
multiprocessing.semaphore_tracker module. Other than semaphores, 
resource_tracker also tracks shared_memory segment
s. Patch by Pierre Glaser.

--
components: Tests
messages: 345320
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_forkserver: test_resource_tracker() failed on  x86 
Gentoo Refleaks 3.8
versions: Python 3.8

___
Python tracker 

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

[issue36867] Make semaphore_tracker track other system resources

[STINNER Victor]

STINNER Victor  added the comment:

The new test is not reliable, see: bpo-37244 "test_multiprocessing_forkserver: 
test_resource_tracker() failed on  x86 Gentoo Refleaks 3.8".

--

___
Python tracker 

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

[issue37244] test_multiprocessing_forkserver: test_resource_tracker() failed on x86 Gentoo Refleaks 3.8

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +pablogsal, pierreglaser, pitrou

___
Python tracker 

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

[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io

[Erik Bray]

Erik Bray  added the comment:

I think this issue can probably be closed.  It refers to a very old version of 
Cygwin as well as old versions of Python.  I don't have any problem building 
the _curses or _io modules on recent versions of Cygwin (>=2.9) and with 
current cpython master (3.9.0a0).

--
nosy: +erik.bray

___
Python tracker 

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

[issue31829] Portability issues with pickle

[miss-islington]

miss-islington  added the comment:


New changeset d561f848b235f2011a43b705d112055b92fa2366 by Miss Islington (bot) 
in branch '3.7':
bpo-31829: Make protocol 0 pickles be loadable in text mode in Python 2. 
(GH-11859)
https://github.com/python/cpython/commit/d561f848b235f2011a43b705d112055b92fa2366


--
nosy: +miss-islington

___
Python tracker 

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

[issue37245] Azure Pipeline: sick macOS job on Python 3.8?

[STINNER Victor]

New submission from STINNER Victor :

I backported a change to 3.8:
https://github.com/python/cpython/pull/14000

The macOS job of Azure Pipelines failed badly:
https://dev.azure.com/Python/cpython/_build/results?buildId=45071&view=results

* test_importlib/test_locks.py: test_deadlock() => TIMEOUT
* test_multiprocessing_spawn: test_thread_safety() => TIMEOUT
* test_concurrent_futures: test_pending_calls_race() => TIMEOUT
* test_functools: test_threaded() => TIMEOUT
* test_multiprocessing_forkserver: test_thread_safety() => TIMEOUT
* test_threading: test_is_alive_after_fork() => TIMEOUT



0:20:21 load avg: 4.55 [155/423/1] test_importlib crashed (Exit code 1) -- 
running: test_concurrent_futures (16 min 12 sec), test_functools (13 min 30 
sec), test_multiprocessing_spawn (18 min 51 sec)
Timeout (0:20:00)!
Thread 0x74627000 (most recent call first):

Thread 0x7fff96f1a380 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/test/lock_tests.py", line 49 in 
__init__
  File 
"/Users/vsts/agent/2.152.1/work/1/s/Lib/test/test_importlib/test_locks.py", 
line 84 in run_deadlock_avoidance_test
  File 
"/Users/vsts/agent/2.152.1/work/1/s/Lib/test/test_importlib/test_locks.py", 
line 89 in test_deadlock
  ...

0:21:30 load avg: 4.76 [160/423/2] test_multiprocessing_spawn crashed (Exit 
code 1) -- running: test_concurrent_futures (17 min 21 sec), test_functools (14 
min 39 sec), test_threading (35 sec 923 ms)
Timeout (0:20:00)!
Thread 0x70ff1000 (most recent call first):

Thread 0x7fff96f1a380 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 847 in start
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/test/support/__init__.py", line 
2299 in start_threads
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/contextlib.py", line 113 in 
__enter__
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/test/_test_multiprocessing.py", 
line 4138 in test_thread_safety
  ...

0:24:09 load avg: 4.11 [207/423/3] test_concurrent_futures crashed (Exit code 
1) -- running: test_functools (17 min 18 sec), test_timeout (34 sec 14 ms), 
test_threading (3 min 14 sec)
Timeout (0:20:00)!
Thread 0x76644000 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/thread.py", 
line 78 in _worker
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 865 in run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 923 in 
_bootstrap_inner
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 885 in 
_bootstrap

Thread 0x76141000 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/thread.py", 
line 78 in _worker
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 865 in run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 923 in 
_bootstrap_inner
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 885 in 
_bootstrap

Thread 0x75c3e000 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/thread.py", 
line 78 in _worker
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 865 in run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 923 in 
_bootstrap_inner
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 885 in 
_bootstrap

Thread 0x7573b000 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/thread.py", 
line 78 in _worker
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 865 in run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 923 in 
_bootstrap_inner
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 885 in 
_bootstrap

Thread 0x75238000 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/thread.py", 
line 78 in _worker
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 865 in run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 923 in 
_bootstrap_inner
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/threading.py", line 885 in 
_bootstrap

Thread 0x7fff96f1a380 (most recent call first):
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/test/libregrtest/setup.py", line 
92 in _test_audit_hook
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/_base.py", 
line 146 in __init__
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/concurrent/futures/_base.py", 
line 288 in wait
  File 
"/Users/vsts/agent/2.152.1/work/1/s/Lib/test/test_concurrent_futures.py", line 
565 in test_pending_calls_race
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/unittest/case.py", line 628 in 
_callTestMethod
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/unittest/case.py", line 671 in 
run
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/unittest/case.py", line 731 in 
__call__
  File "/Users/vsts/agent/2.152.1/work/1/s/Lib/unittest/

[issue37245] Azure Pipeline: sick macOS job on Python 3.8?

[STINNER Victor]

STINNER Victor  added the comment:

os.uname: posix.uname_result(sysname='Darwin', nodename='Mac-483.local', 
release='17.7.0', version='Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 
PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64', machine='x86_64')

--

___
Python tracker 

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

[issue37246] http.cookiejar.DefaultCookiePolicy should use current timestamp instead of last updated timestamp value for checking expiry

[Karthikeyan Singaravelan]

New submission from Karthikeyan Singaravelan :

In http.cookiejar module's DefaultCookiePolicy checking for cookie expiry uses 
the last updated value for _now [0] which is in three actions below. So if the 
cookies are extracted using the policy and the policy is used for expiry check 
later it could give incorrect values for expiry check. Like in below example I 
create a cookie with 1 second from now as expiry date. Sleeping for 1 second 
and using the same policy causing is_expired to work correctly but return_ok 
uses self._now with the older value returning the cookie. I propose using 
time.time() and update self._now or to change cookie.is_expired(self._now) to 
cookie.is_expired() where is_expired uses time.time() internally

I think it's better to use the current time while using return_ok to compare 
the cookie expiry. One another error is that self._now is set only when one of 
the methods is called so evaluating a new policy against a cookie with expiry 
causes AttributeError since self._now is not yet set.

Actions where self._now is updated

* add_cookie_header
* extract_cookies
* set_cookie_if_ok

import time
from http.cookiejar import CookieJar, DefaultCookiePolicy, time2netscape
from test.test_http_cookiejar import FakeResponse
from urllib.request import Request

delay = 1
now = time.time() + delay
future = time2netscape(now)

req = Request("https://example.com";)

headers = [f"Set-Cookie: a=b; expires={future};"]
res = FakeResponse(headers, "https://example.com/";)

policy = DefaultCookiePolicy()
jar = CookieJar(policy=policy)
jar.extract_cookies(res, req)
cookie = jar.make_cookies(res, req)[0]

print(f"{cookie.expires = }")
print(f"{policy.return_ok(cookie, req) = }")

time.sleep(delay + 1)

# Check for cookie expiry where is_expired() returns true
print(f"Current time : {int(time.time())}")
print(f"{cookie.is_expired() = }") # is_expired uses current timestamp so it 
returns True
print(f"{policy.return_ok(cookie, req) = }") # Return now uses older timestamp 
and still returns the cookie as valid cookie

# Output

cookie.expires = 1560339939
policy.return_ok(cookie, req) = True
Current time : 1560339940
cookie.is_expired() = True
policy.return_ok(cookie, req) = True

# Using above cookie variable against a new policy would throw AttributeError 
since self._now is not yet set

req = Request("https://example.com";)
policy1 = DefaultCookiePolicy()
print(policy1.return_ok(cookie, req))

# Output

Traceback (most recent call last):
  File "/tmp/bar.py", line 31, in 
print(policy1.return_ok(cookie, req))
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py", 
line 1096, in return_ok
if not fn(cookie, request):
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py", 
line 1128, in return_ok_expires
if cookie.is_expired(self._now):
AttributeError: 'DefaultCookiePolicy' object has no attribute '_now'


[0] 
https://github.com/python/cpython/blob/a6e190e94b47324f14e22a09200c68b722d55699/Lib/http/cookiejar.py#L1128

--
components: Library (Lib)
messages: 345327
nosy: martin.panter, orsenthil, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: http.cookiejar.DefaultCookiePolicy should use current timestamp instead 
of last updated timestamp value for checking expiry
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

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

[Alejandro Gonzalez]

Alejandro Gonzalez  added the comment:

>I think we can proceed with option A, but only if doesn't cause visible 
>slow-down for creating ABCs (which is already slower that normal classes). 
>TBH, I don't want to document A as "official" recipe (maybe however mention 
>the problem in the `pickle` module docs).

I'll try using the same approach used in namedtuple, and see if there is any 
visible slow-down.

Regarding the documentation, I see your point. Perhaps adding some section like 
"Notes on pickling dynamically-defined classes" in the `pickle` module would be 
more appropriate? That section would mention that you have to make sure to set 
the `__module__` attribute.

>Note that other "class factories" in stdlib (like collections.namedtuple) do 
>almost exactly option A.

Thanks for the tip. Indeed it does. In fact, the API defines a module argument. 
Its documentation could be improved, though. It should mention why would you 
want to pass that argument (pickling seems to be the reason that argument was 
added in the first place).

--

___
Python tracker 

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[miss-islington]

Change by miss-islington :


--
pull_requests: +13876
pull_request: https://github.com/python/cpython/pull/14012

___
Python tracker 

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[miss-islington]

miss-islington  added the comment:


New changeset 32dda263e4e8c8e0fadc2bb29b9856e2f177dde9 by Miss Islington (bot) 
(Michael Felt) in branch 'master':
bpo-35545: Skip `test_asyncio.test_create_connection_ipv6_scope` on AIX 
(GH-14011)
https://github.com/python/cpython/commit/32dda263e4e8c8e0fadc2bb29b9856e2f177dde9


--

___
Python tracker 

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

[issue37247] swap distutils build_ext and build_py commands to allow proper SWIG extension installation

[Jeroen van den Hout]

New submission from Jeroen van den Hout :

Currently when building an extension which lists a SWIG interface (.i) file as 
a source file, SWIG creates the files correctly in the build_ext command. 
Unfortunately this command is run after the build_py command, so the python 
files (.py) created in the build_ext command are never copied to the 
installation.
To fix this, swap build_ext and build_py commands in the sub_commands attribute 
of the build command.

--
components: Distutils
messages: 345330
nosy: Jeroen van den Hout, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: swap distutils build_ext and build_py commands to allow proper SWIG 
extension installation
type: behavior
versions: 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

[issue37248] support conversion of `func(**{} if a else b)`

[Shen Han]

Change by Shen Han :


--
components: 2to3 (2.x to 3.x conversion tool)
nosy: Shen Han
priority: normal
severity: normal
status: open
title: support conversion of `func(**{} if a else b)`
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, 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

[issue28459] _pyio module broken on Cygwin / setmode not usable

[Erik Bray]

Change by Erik Bray :


--
pull_requests: +13877
pull_request: https://github.com/python/cpython/pull/14013

___
Python tracker 

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[miss-islington]

miss-islington  added the comment:


New changeset 70a4178ec47154fdcc3ff06c13149e178d014581 by Miss Islington (bot) 
in branch '3.8':
bpo-35545: Skip `test_asyncio.test_create_connection_ipv6_scope` on AIX 
(GH-14011)
https://github.com/python/cpython/commit/70a4178ec47154fdcc3ff06c13149e178d014581


--

___
Python tracker 

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

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Perhaps adding some section like "Notes on pickling dynamically-defined 
> classes" in the `pickle` module would be more appropriate?

I think just a note with few sentences would be enough.

--

___
Python tracker 

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

[issue37247] swap distutils build_ext and build_py commands to allow proper SWIG extension installation

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue37247] swap distutils build_ext and build_py commands to allow proper SWIG extension installation

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> SWIG creates the files correctly in the build_ext command

One could argue that running SWIG should be an entirely different step, not 
part of build_ext.

I'm afraid that your idea of swapping build_ext and build_py will be rejected 
because it has a high chance of breaking stuff: we have always done build_py 
before build_ext and packages probably rely on this order.

--
nosy: +jdemeyer

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I think that the PyCode_New() compatibility problem and tp_print are 
sufficiently closely related that they can be discussed together.

In any case, I agree that it makes little sense to fix just one.

--

___
Python tracker 

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

[issue26110] Speedup method calls 1.2x

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Note that this idea has been generalized by PEP 590: any type can support this 
optimization by setting the Py_TPFLAGS_METHOD_DESCRIPTOR flag.

--
nosy: +jdemeyer

___
Python tracker 

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

[issue37249] Missing declaration of _PyObject_GetMethod

[Jeroen Demeyer]

New submission from Jeroen Demeyer :

The function _PyObject_GetMethod is internal and private, but it should still 
be declared properly. Currently, it is "manually" declared in two .c files 
where it's used.

--
components: Interpreter Core
messages: 345336
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Missing declaration of _PyObject_GetMethod
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

[issue37249] Missing declaration of _PyObject_GetMethod

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
nosy: +yselivanov

___
Python tracker 

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

[issue37249] Missing declaration of _PyObject_GetMethod

[Jeroen Demeyer]

Change by Jeroen Demeyer :


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

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL

[STINNER Victor]

New submission from STINNER Victor :

Copy of Stefan Behnel's msg345305 in bpo-37221:
"""
Note that PyCode_New() is not the only change in 3.8 beta1 that breaks Cython 
generated code. The renaming of "tp_print" to "tp_vectorcall" is equally 
disruptive, because Cython has (or had) a work-around for CPython 
(mis-)behaviour that reset the field explicitly to NULL after calling 
PyType_Ready(), which could set it arbitrarily without good reason.

So, either revert that field renaming, too, or ignore Cython generated modules 
for the reasoning about the change in this ticket.

I'm fine with keeping things as they are now in beta-1, but we could obviously 
adapt to whatever beta-2 wants to change again.
"""

There are 2 problems:

* source compatibility
* ABI compatibility

The following change removed PyTypeObject.tp_print and replaced it with 
PyTypeObject.tp_vectorcall_offset:

commit aacc77fbd77640a8f03638216fa09372cc21673d
Author: Jeroen Demeyer 
Date:   Wed May 29 20:31:52 2019 +0200

bpo-36974: implement PEP 590 (GH-13185)


Co-authored-by: Jeroen Demeyer 
Co-authored-by: Mark Shannon 


== ABI compatibility ==

In term of ABI, it means that C extensions using static type ("static 
PyTypeObject mytype = {  };") is broken by this change.

Honestly, I'm not sure if we ever provided any forward compatibility for static 
types. bpo-32388 removed "cross-version binary compatibility" on purpose in 
Python 3.8. It's an on-going topic, see also my notes about ABI and 
PyTypeObject:
https://pythoncapi.readthedocs.io/type_object.html

Maybe we can simply ignore this part of the problem.


== Source compatibility ==

Cython generates C code setting tp_print explicitly to NULL.

To avoid depending on Cython at installation, most (if not all) projects using 
Cython include C files generated by Cython in files they distribute (like 
tarballs). Because of that, the commit aacc77fbd77640a8f03638216fa09372cc21673d 
requires all these projects to regenerate their C files using Cython.

In Fedora, we fixed many Python packages to always re-run Cython to regenerate 
all C files. But Fedora is just one way to distribute packages, it doesn't 
solve the problem of files distributed on PyPI, nor other Linux distribution 
(for example).

Jeroen Demeyer proposed PR 14009 to fix the source compatibility:

   #define tp_print tp_vectorcall

--
components: Interpreter Core
messages: 345337
nosy: vstinner
priority: normal
severity: normal
status: open
title: C files generated by Cython set tp_print to NULL
versions: Python 3.8

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[STINNER Victor]

STINNER Victor  added the comment:

Jeroen Demeyer:
> I think that the PyCode_New() compatibility problem and tp_print are 
> sufficiently closely related that they can be discussed together.

IMHO these problems are different enough to justify to have a separated issue: 
I created https://bugs.python.org/issue37250 Please discuss tp_print issue 
there.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL

[Jeroen Demeyer]

Change by Jeroen Demeyer :


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

___
Python tracker 

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

[issue32388] Remove cross-version binary compatibility

[STINNER Victor]

STINNER Victor  added the comment:

About ABI "foward compatibility", Python 3.8 introduced another backward 
incompatible change: bpo-37250 "C files generated by Cython set tp_print to 
NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset".

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

Change by STINNER Victor :


--
title: C files generated by Cython set tp_print to NULL -> C files generated by 
Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with 
tp_vectorcall_offset

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

"printfunc tp_print;" has been replaced with "Py_ssize_t 
tp_vectorcall_offset;": the type was basically a pointer and has been replaced 
with an integer.

With "#define tp_print tp_vectorcall", "type->tp_print = NULL;" becomes 
"type->tp_vectorcall = NULL;".

If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a compilation 
error, since NULL is not exactly an integer, no? I'm not sure that it's an 
issue, I'm just thinking aloud.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Actually, Cython generates code setting tp_print to 0 (not NULL).

--
nosy: +jdemeyer

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

inherit_slots() uses:

/* Inherit tp_vectorcall_offset only if tp_call is not overridden */
if (!type->tp_call) {
COPYSLOT(tp_vectorcall_offset);
}

PyType_Ready() contains the following assertion:

/* Consistency checks for PEP 590:
 * - Py_TPFLAGS_METHOD_DESCRIPTOR requires tp_descr_get
 * - _Py_TPFLAGS_HAVE_VECTORCALL requires tp_call and
 *   tp_vectorcall_offset > 0
 * To avoid mistakes, we require this before inheriting.
 */
if (type->tp_flags & Py_TPFLAGS_METHOD_DESCRIPTOR) {
_PyObject_ASSERT((PyObject *)type, type->tp_descr_get != NULL);
}
if (type->tp_flags & _Py_TPFLAGS_HAVE_VECTORCALL) {
_PyObject_ASSERT((PyObject *)type, type->tp_vectorcall_offset > 0);
_PyObject_ASSERT((PyObject *)type, type->tp_call != NULL);
}

I understand that tp_vectorcall_offset=0 is fine and the expected value for a 
type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a 
> compilation error, since NULL is not exactly an integer, no?

No because tp_vectorcall is a function pointer. You're confusing with 
tp_vectorcall_offset which is an integer.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

IMHO the simplest and safest option for this issue is to revert tp_print 
removal and move tp_vectorcall_offset at the end of PyTypeObject.

Is PEP 590 fully public in Python 3.8? It seems like 
_Py_TPFLAGS_HAVE_VECTORCALL at least is private.

Maybe we can attempt again to remove tp_print from Python 3.9? Once Cython will 
handle tp_print removal? Or even keep it in Python 3.9?

Python 3 had unused tp_print for 10 years and nobody complained. There are a 
few PyTypeObject instances in a Python process. A single pointer isn't a giant 
waste of memory.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +petr.viktorin, scoder

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

> No because tp_vectorcall is a function pointer. You're confusing with 
> tp_vectorcall_offset which is an integer.

Oh. I didn't notice that your PR makes tp_print an alias to tp_vectorcall 
rather than tp_vectorcall_offset. Ok.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

If we decide to not reintroduce tp_print, tp_print removal must be documented 
at:
https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> I understand that tp_vectorcall_offset=0 is fine and the expected value for a 
> type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL.

Not necessarily. There are subtleties involved when subclassing: there are 
cases where tp_vectorcall_offset needs to be non-zero despite 
_Py_TPFLAGS_HAVE_VECTORCALL not being set. See also PR 13858.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

Cython issue: https://github.com/cython/cython/issues/2976

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> IMHO the simplest and safest option for this issue is to revert tp_print 
> removal and move tp_vectorcall_offset at the end of PyTypeObject.

That's a drastic solution to a rather simple problem. PR 14009 would fix Cython 
just fine.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

me:
> I understand that tp_vectorcall_offset=0 is fine and the expected value for a 
> type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL.

Jeroen Demeyer:
> Not necessarily. There are subtleties involved when subclassing: there are 
> cases where tp_vectorcall_offset needs to be non-zero despite 
> _Py_TPFLAGS_HAVE_VECTORCALL not being set. See also PR 13858.

Cython generates C code which looks like:

if (PyType_Ready(type) < 0) { ... handle error ... }
type->tp_print = 0;

This code can cause subtle and annoying issue if PR 13858 is merged. So that's 
another argument in favor of reintroducing tp_print in Python 3.8.

--

Cython has already been fixed to no longer set tp_print to 0 on Python 3.8:

https://github.com/cython/cython/commit/f10a0a391edef10bd37095af87f521808cb362f7

But again, this problem is not about correctness, but more about practical 
backward compatibility issues (see my first message).

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

https://github.com/cython/cython/commit/f10a0a391edef10bd37095af87f521808cb362f7

Note for myself: this fix is already part of Cython 0.29.10 released at June 2 
(10 days ago).

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> This code can cause subtle and annoying issue if PR 13858 is merged.

I don't see how this is related to PR 13858 at all. Please explain.

--

___
Python tracker 

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

[issue37248] support conversion of `func(**{} if a else b)`

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

Please, can you add some text with an explanation ?

--
nosy: +pablogsal

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> If we decide to not reintroduce tp_print, tp_print removal must be documented 
> at:
https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api

I'll add that to PR 13844.

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> This code can cause subtle and annoying issue if PR 13858 is merged.

Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again?

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[STINNER Victor]

STINNER Victor  added the comment:

> Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again?

The two are related, no?

Honestly, reintroducing tp_print looks simple and safe enough. I'm in favor of 
doing that. Is there any drawback? (as I wrote, I don't think that the size of 
PyTypeObject really matters in practice)

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Honestly, reintroducing tp_print looks simple and safe enough. Is there any 
> drawback?

1. The one-time effort to change the code and documentation back.

2. Stefan Behnel wanted to use tp_print for backporting vectorcall in Cython to 
earlier Python versions.

3. Stable ABI incompatibility (the complaint that you incorrectly added to PR 
13858 would become correct).

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> The two are related, no?

Related in the same way that tp_dictoffset and tp_dict are related (i.e. not 
that much).

--

___
Python tracker 

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Jeremy Cline]

New submission from Jeremy Cline :

This is related to the new AsyncMock[0] class in Python 3.8b1. A simple 
reproducer is:

from unittest import mock

mock_obj = mock.MagicMock()
mock_obj.mock_func = mock.MagicMock(spec=lambda x: x)

with mock.patch.object(mock_obj, "mock_func") as nested:
print(type(nested))


Instead of a MagicMock (the behavior in Python 3.7) in Python 3.8b1 this 
results in an AsyncMock.

[0]https://github.com/python/cpython/pull/9296

--
components: Library (Lib)
messages: 345358
nosy: jcline
priority: normal
severity: normal
status: open
title: Mocking a MagicMock with a function spec results in an AsyncMock
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue37210] Pure Python pickle module should not depend on _pickle.PickleBuffer

[STINNER Victor]

STINNER Victor  added the comment:

FYI pyperformance is affected by this issue:

vstinner@apu$ env/bin/python 
~/prog/python/pyperformance/pyperformance/benchmarks/bm_pickle.py unpickle 
--pure-python -v -p3  
Traceback (most recent call last):
  File 
"/home/vstinner/prog/python/pyperformance/pyperformance/benchmarks/bm_pickle.py",
 line 287, in 
import pickle
  File "/home/vstinner/prog/python/master/Lib/pickle.py", line 39, in 
from _pickle import PickleBuffer
ModuleNotFoundError: import of _pickle halted; None in sys.modules

It is no longer possible to benchmark the pure Python implement of pickle.

--pure-python uses this code path:

def is_module_accelerated(module):
return getattr(pickle.Pickler, '__module__', '') == 'pickle'

(...)

if six.PY3:
sys.modules['_pickle'] = None
import pickle
if not is_module_accelerated(pickle):
raise RuntimeError("Unexpected C accelerators for pickle")

Should I remove the benchmark?

--
nosy: +vstinner

___
Python tracker 

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +lisroach, xtreak

___
Python tracker 

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

[issue37248] support conversion of `func(**{} if a else b)`

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

>From the title is this similar to the PR 
>https://github.com/python/cpython/pull/12703

--
nosy: +xtreak

___
Python tracker 

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Mario Corchero]

Change by Mario Corchero :


--
nosy: +mariocj89

___
Python tracker 

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

[issue37210] Pure Python pickle module should not depend on _pickle.PickleBuffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13881
pull_request: https://github.com/python/cpython/pull/14016

___
Python tracker 

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

[issue37210] Pure Python pickle module should not depend on _pickle.PickleBuffer

[STINNER Victor]

STINNER Victor  added the comment:

I wrote a simple PR, PR 14016, to fix the pure Python implementation of pickle: 
simply restrict pickle to protocol 4 if PickleBuffer is missing.

--

___
Python tracker 

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

[issue37210] Pure Python pickle module should not depend on _pickle.PickleBuffer

[STINNER Victor]

Change by STINNER Victor :


--
resolution: wont fix -> 
status: closed -> open

___
Python tracker 

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

[issue34058] Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/

[Cooper Lees]

Cooper Lees  added the comment:

I also have the same problem with _socket that was Fixed on the latest version 
of CentOS 7 building with gcc 4.8.5.

Adding:
sudo ln -s /usr/local/lib64/python3.7/lib-dynload/ 
/usr/local/lib/python3.7/lib-dynload

Allowed the .so to be found and the import to work.

--
nosy: +cooperlees

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b2fd32b2f041402bb9fc8607f01566c055aafed9 by Victor Stinner in 
branch '3.8':
bpo-35766: compile(): rename feature_version parameter (GH-13994) (GH-14001)
https://github.com/python/cpython/commit/b2fd32b2f041402bb9fc8607f01566c055aafed9


--

___
Python tracker 

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

[issue37252] devpoll test failures on Solaris

[Jakub Kulik]

New submission from Jakub Kulik :

test_devpoll currently ends with two failures with Python 3.8 on Solaris.

First one is wrong number of arguments to devpoll.register function (which 
thrown the same error as expected in 3.7 but now acts differently).

Second one is that register and modify no longer throw OverflowError when 
negative number is given as second argument, but rather a ValueError. I am not 
sure whether this is just a small semantics change or some bigger problem 
(documentation doesn't mention what error should be thrown).

So I fixed it in attached pull request by changing the expected thrown error 
but there might be other problem as well.

--
components: Extension Modules
messages: 345365
nosy: kulikjak
priority: normal
severity: normal
status: open
title: devpoll test failures on Solaris
versions: Python 3.8

___
Python tracker 

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

[issue37252] devpoll test failures on Solaris

[Jakub Kulik]

Change by Jakub Kulik :


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

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks for taking care of this!
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

[Erik Bray]

Erik Bray  added the comment:

FWIW (unsurprisingly) the new test added here is broken on Cygwin, whose libc's 
(newlib) behavior in this undefined case.  So I get:

>>> from datetime import date
>>> t = date(2005, 1, 1)
>>> t.strftime("%Y")  # ok
'2005'
>>> t.strftime("%%")  # ok
'%'
>>> t.strftime("%")  # undefined behavior
''
>>> t.strftime("%Y %")  # undefined behavior; discards the whole format string
''
>>> t.strftime("%Y%Q")  # undefined format; discards the whole format string
''

This behavior is user-hostile I think; it should raise a ValueError instead of 
just return an empty string.  I would have suggested the same for the trailing 
'%' case, though I understand the goal of this issue was consistency.

Also worth noting that both before and after this patch:

>>> import time
>>> time.strftime('%')
''

So the question of consistency between the interfaces, which was the main point 
of this issue, was already resolved in this case, and the *inconsistency* 
observed was dependent on system-dependent behavior.

For now I might propose doing away with this test in its current form, and just 
test

assert t.strftime('%') == time.strftime('%')

or something like that.

I agree with Victor that trying to make the strftime experience consistent 
across system-dependent quirks is a worthy goal, but that goes deeper than just 
this trailing '%' case.

--
nosy: +erik.bray

___
Python tracker 

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Miro Hrončok]

Change by Miro Hrončok :


--
nosy: +hroncok

___
Python tracker 

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

[issue37253] PyCompilerFlags got a new cf_feature_version field

[STINNER Victor]

New submission from STINNER Victor :

The commit dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c of bpo-35766 added a new 
cf_feature_version field to PyCompilerFlags. Each PyCompilerFlags variable must 
properly initialize this new field to PY_MINOR_VERSION. I propose to add a new 
_PyCompilerFlags_INIT macro to statically initialize such variable. I'm not 
sure if it should be public or not.

The PyCompilerFlags structure is excluded from the stable ABI (PEP 384), but 
it's documented in the "The Very High Level Layer" C API documentation:
https://docs.python.org/dev/c-api/veryhigh.html#c.PyCompilerFlags

Structure fields are documented there:

struct PyCompilerFlags {
int cf_flags;
}

The doc is outdated. I'm not sure if it's on purpose or not.

Moreover, the new PyCompilerFlags.cf_feature_version field is not documented in 
https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api whereas C 
extensions using PyCompilerFlags should initialize cf_feature_version to 
PY_MINOR_VERSION?

I'm not sure if C extensions really *must* initialize cf_feature_version, since 
the field is only used if PyCF_ONLY_AST flag is set in the cf_flags field.

Something else, ast.parse() has been modified to use a (major, minor) version 
tuple rather an integer to specify the Python version in feature_version, but 
PyCompilerFlags still only uses the minor major. This API will be broken once 
the Python major version will be increased to 4, no? Would it make sense to use 
PY_VERSION_HEX format which includes the major version instead?

Or cf_feature_version could be a structure with major and minor fields, but 
that might be overkill?

--
components: Interpreter Core
messages: 345368
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyCompilerFlags got a new cf_feature_version field
versions: 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

[issue37253] PyCompilerFlags got a new cf_feature_version field

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Jesse Bacon  added the comment:

I am missing keys, when extracting the data back out with todays NVD pull.
---
KeyError  Traceback (most recent call last)
~/anaconda3/lib/python3.6/shelve.py in __getitem__(self, key)
110 try:
--> 111 value = self.cache[key]
112 except KeyError:

KeyError: 'CVE-2019-1842'

During handling of the above exception, another exception occurred:

KeyError  Traceback (most recent call last)
 in 
  1 results = []
  2 for x in raw_cves:
> 3 results.append(db[x])

~/anaconda3/lib/python3.6/shelve.py in __getitem__(self, key)
111 value = self.cache[key]
112 except KeyError:
--> 113 f = BytesIO(self.dict[key.encode(self.keyencoding)])
114 value = Unpickler(f).load()
115 if self.writeback:

KeyError: b'CVE-2019-1842'

--

___
Python tracker 

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

[issue37253] PyCompilerFlags got a new cf_feature_version field

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13884
pull_request: https://github.com/python/cpython/pull/14019

___
Python tracker 

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

[issue37254] POST large file to server (using http.server.CGIHTTPRequestHandler), always reset by server.

[shajianrui]

New submission from shajianrui :

Windows 10, python 3.7 

I met a problem when using the http.server module. I set up a base server with 
class HTTPServer and CGIHTTPRequestHandler(Not using thread or fork) and tried 
to POST a large file (>2MB), then I find the server always reset the 
connection. In some very rare situation the post operation could be 
finished(Very slow) but the CGI script I'm posting to always show that an 
incomplete file is received(Called "incomplete file issue").

==First Try===

At first I think (Actually a misunderstanding but lead to a passable 
walkaround) that "self.rfile.read(nbytes) " at LINE 1199 is not blocking, so it 
finish receiving just before the POST operation finished. Then I modify the 
line like this below:

1198if self.command.lower() == "post" and nbytes > 0:
1199#data = self.rfile.read(nbytes) 【The original line, I 
comment out it.】
databuf = bytearray(nbytes)
datacount = 0
while datacount + 1 < nbytes:
buf = 
self.rfile.read(self.request.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)
#print("Get " + str(len(buf)) + " bytes.")
for i in range(len(buf)):
databuf[datacount] = buf[i]
datacount += 1
if datacount == nbytes:
#print("Done.")
break
data = bytes(databuf)   【Now get the data.】

In this modification I just try to repeatedly read 65536(Default number of 
socket) bytes from rfile until I get nbytes of bytes. Now it works well(Correct 
file received), and is much faster then the POSTing process when using the 
original http.server module(If "incomplete file issue" appear).

==Second Try==

However, now I know that there is no problem with "whether it is blocking" 
because "self.rfile.read()" should be blocked if the file is not POSTed 
completely. 

I check the tcp stream with wireshark and find that in the middle of the 
transfer, the recv window of server is always 256, so I think that the problem 
is at the variable "rbufsize", which is transfered to makefile() when the rfile 
of the XXXRequestHandler Object is created. At least it is the problem of the 
low speed. But I dont know whether it lead to the reset operation and the 
incomplete file issue.

I go back to the original version of the http.server module. Then I make a 
subclass of socketserver.StreamRequestHandler, override its setup() 
method(firstly I copy the codes of setup() from StreamRequestHandler, and 
modify Line770)(770 is the line number in socketserver module, but I create the 
new subclass in a new file.):

770 #self.rfile = self.connection.makefile('rb', self.rbufsize)
self.rfile = self.connection.makefile('rb', 65536)

Then the POST process become much faster(Then my first modification)!

But the server print Error:

File 
"c:\Users\Administrator\Desktop\cgi-server-test\modified_http_server_bad.py", 
line 1204, in run_cgi【A copy of http.server module】
while select.select([self.rfile._sock], [], [], 0)[0]:  【at 
line 1204】
AttributeError: '_io.BufferedReader' object has no attribute '_sock'

Because I know it want to get the socket of the current RequestHandler, I just 
modify http.server module and change "self.rfile._sock" into 
"self.connection"(I dont know if it would cause problem, it is just a 
walkaround). 

OK, It now work well again. The CGI script can get the correct file(return the 
correct SHA1 of the file uploaded), and the POST process is REALLY MUCH FASTER!

= Question =

So here is the problem:
1- What cause the server resetting the connection? Seem it is because the 
default buffer size of the rfile is too small.
2- What cause the cgi script getting the incomplete file? I really have no idea 
about it. Seems this problem also disappear if I enlarge the buffer.

Other information:
1- The "incomplete file issue" usually appear at the first POST to the server, 
and almost all of the other POST connections are reset.
2- If the server start resetting connections, another "incomplete file issue" 
will never appear anymore (Actually it happen, but Chrome only show a RESET 
page, see 4- below.).
3- If the server start resetting connections, it take a long time to terminate 
the server with Ctrl+C.
4- When the connection is reset, the response printed by the cgi script is 
received correctly and it show that cgi script receive an incomplete file, the 
byte count is much fewer than correct number.(I use Chrome to do the POST, so 
it just show a reset message and the real response is ignored)

Please help.

--
components: Library (Lib)
messages: 345370
nosy: shajianrui
priority: normal
severity: normal
status: open
title: POST large file to server (using http.server.CGIHTTPRequestHandler), 
always reset by s

[issue37241] Item Count Error in Shelf

[Jesse Bacon]

Change by Jesse Bacon :


Added file: https://bugs.python.org/file48413/ShelfKeys.png

___
Python tracker 

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

[issue37253] PyCompilerFlags got a new cf_feature_version field

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +13885
pull_request: https://github.com/python/cpython/pull/14020

___
Python tracker 

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

[issue37253] PyCompilerFlags got a new cf_feature_version field

[STINNER Victor]

STINNER Victor  added the comment:

> Something else, ast.parse() has been modified to use a (major, minor) version 
> tuple rather an integer to specify the Python version in feature_version, but 
> PyCompilerFlags still only uses the minor major. This API will be broken once 
> the Python major version will be increased to 4, no? Would it make sense to 
> use PY_VERSION_HEX format which includes the major version instead?

I can work on a PR to change cf_feature_version format, but I would prefer to 
agree here on what is the best format ;-)

Note: compile() has a private keyword-only _feature_version which is also the 
Python minor version (int): don't include the major version. If we change 
cf_feature_version, we may also change compile(_feature_version=N) format.

--

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-37253: "PyCompilerFlags got a new cf_feature_version field".

--

___
Python tracker 

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

[issue37160] thread native id netbsd support

[STINNER Victor]

New submission from STINNER Victor :


New changeset 5287022eeeb3c017d49fc8580b52e18377bf23f3 by Victor Stinner (David 
Carlier) in branch 'master':
bpo-37160: Thread native ID NetBSD support (GH-13835)
https://github.com/python/cpython/commit/5287022eeeb3c017d49fc8580b52e18377bf23f3


--
nosy: +vstinner

___
Python tracker 

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

[issue37160] thread native id netbsd support

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue37160] thread native id netbsd support

[STINNER Victor]

STINNER Victor  added the comment:

Since threading.get_native_id() is a new feature in Python 3.8 and the PR is 
small enough, IMHO it's fine to backport the change to 3.8.

--
versions: +Python 3.8

___
Python tracker 

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

[issue37160] thread native id netbsd support

[miss-islington]

miss-islington  added the comment:


New changeset c9ca96dd968176580a011e852066c95a48aab7e0 by Miss Islington (bot) 
in branch '3.8':
bpo-37160: Thread native ID NetBSD support (GH-13835)
https://github.com/python/cpython/commit/c9ca96dd968176580a011e852066c95a48aab7e0


--
nosy: +miss-islington

___
Python tracker 

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

[issue37160] thread native id netbsd support

[STINNER Victor]

STINNER Victor  added the comment:

Thanks David Carlier! It's now merged into 3.8 and master.

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Lisa Roach]

Lisa Roach  added the comment:

Following up from xtreak's proposal 
(https://github.com/python/cpython/pull/9296) I think checking if __code__ is 
actually a CodeType is a good idea. It's simple and doesn't change any other 
functionality in an unwanted way.

--

___
Python tracker 

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

[issue37176] super() docs don't say what super() does

[Carlos André Dantas de Lima]

Carlos André Dantas de Lima  added the comment:

The method says who you will use some recursion.

--
nosy: +Carlos André Dantas de Lima

___
Python tracker 

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

[issue37255] Pathlib: Add an expandUserPath method or argument

[Andrea Moro]

New submission from Andrea Moro :

Assuming the given path contains a '~' character, it would be nice to have a 
function to expand the given path so any further calls to an .exists doesn't 
fail.

A prototype of the function could be

# Expand the home path in *ix based systems if any
if '~' in s:
x = [x for x in Path(s).parts if x not in '~']
p = Path.home()
for item in x:
p = p.joinpath(item)

--
components: Library (Lib)
messages: 345379
nosy: Andrea Moro
priority: normal
severity: normal
status: open
title: Pathlib: Add an expandUserPath method or argument
type: enhancement

___
Python tracker 

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

[issue36607] asyncio.all_tasks() crashes if asyncio is used in multiple threads

[Łukasz Langa]

Łukasz Langa  added the comment:

Note: there's a discussion on GitHub on PR 13971 being a bad solution: 
https://github.com/python/cpython/pull/13971#issuecomment-500908198

They should be reverted (or fixed forward) for 3.8 and 3.9.  I'm OK with this 
modifying the AbstractEventLoop API if need be for 3.8.  Just have a PR ready 
in the next two weeks.

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue37241] Item Count Error in Shelf

[Eric V. Smith]

Eric V. Smith  added the comment:

This still isn't an example we can copy and paste to reproduce, so I'm going to 
be unable to help you. Sorry.

Again: please don't post images, for the reasons I previously stated.

--

___
Python tracker 

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