[issue45058] Undefined behavior for syntax "except AError or BError:" accepted by interpreter

2021-09-01 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Yes, it is syntactically correct. It can even make sense. But the meaning is 
different from "except (AError, BError)". If it looks confusing to you, it is a 
work of linters to warn about misleading or suspicions code.

--

___
Python tracker 

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



[issue27175] Unpickling Path objects

2021-09-01 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

It would be nice to have simple general mechanism for everloading names of 
modules, classes and functions, similar to _compat_pickle. Currently you can do 
this with creating a subclass of Unpickler and overloading find_class(), but it 
is not so convenient. There is no way to register standard replacements 
globally.

--

___
Python tracker 

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



[issue45056] compiler: Unnecessary None in co_consts

2021-09-01 Thread Inada Naoki


Inada Naoki  added the comment:

I found anther example for unused constants.

The `readall()` function.
https://github.com/python/cpython/blob/863154c9292e70c5a8a1a3f22ef4ee42e2304281/Lib/_pyio.py#L663-L675

Python 3.9.5:
co_consts = ('Read until EOF, using multiple read() call.', None)
Python 3.10rc1:
co_consts = ('Read until EOF, using multiple read() call.', True, None)

--

___
Python tracker 

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



[issue45067] Failed to build _curses on CentOS 7

2021-09-01 Thread Ronald Oussoren


Ronald Oussoren  added the comment:

You stripped too much output from the build, in particular you removed the part 
where _curses failed to build. The output you show only says that _cursus_panel 
failed verification because _cursus could not be imported.

Could you add the build failure for the _cursus module as well?  Rerunning make 
should give a more manageable output.

--
nosy: +ronaldoussoren

___
Python tracker 

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



[issue27175] Unpickling Path objects

2021-09-01 Thread Antony Lee


Antony Lee  added the comment:

I guess I could instead add some OS-dependent entries for Path classes into 
_compat_pickle (to do the remapping at load time) if you prefer?  I don't have 
a strong preference either-way.

--

___
Python tracker 

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



[issue44019] operator.call/operator.__call__

2021-09-01 Thread Antony Lee


Antony Lee  added the comment:

Python2's apply has different semantics: it takes non-unpacked arguments, i.e.

def apply(f, args, kwargs={}): return f(*args, **kwargs)

rather than

def call(f, *args, **kwargs): return f(*args, **kwargs)

I agree that both functions can be written in two (or one) line, but the same 
can be said of most functions in the operator module (def add(x, y): return x + 
y); from the module's doc ("efficient functions corresponding to the intrinsic 
operators"), I would argue that the criteria for inclusion are efficiency 
(operator.call is indeed fast, see the linked PR) and intrinsicness (I don't 
know if there's a hard definition, but function calling certainly seems 
intrinsic).

--

___
Python tracker 

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



[issue27175] Unpickling Path objects

2021-09-01 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

_compat_pickle is only used with protocol < 3.

--

___
Python tracker 

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



[issue45056] compiler: Unnecessary None in co_consts

2021-09-01 Thread Inada Naoki


Change by Inada Naoki :


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

___
Python tracker 

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



[issue45056] compiler: Unnecessary None in co_consts

2021-09-01 Thread Inada Naoki


Inada Naoki  added the comment:

@Pablo This issue seems an optimization rather than bugfix.
But since Python 3.10 produces more unused constants than 3.9, this is a 
regression.

GH-28109 removes not all unused constants, but only trailing unused constants.
I think it is enough to fix the regression.

I want to backport it to 3.10 or 3.10.1 after Mark's review.

--
nosy: +pablogsal
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



[issue45056] compiler: Unnecessary None in co_consts

2021-09-01 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

> I want to backport it to 3.10 or 3.10.1 after Mark's review.

Ok, please, add me as a reviewer to the backport once is ready.

--

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Irit Katriel


New submission from Irit Katriel :

def format_frame(frame) should be renamed to 
format_frame_summary(frame_summary) because it takes a FrameSummary obejct and 
not a frame. 

This is a new API in 3.11 so it can be changed now.

There are also local variables in traceback.py which are called frame but 
actually represent FrameSummary. This can be confusing and should be fixed at 
the same time where it doesn't break API.

--
messages: 400825
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: confusion between frame and frame_summary in traceback module

___
Python tracker 

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



[issue45076] open "r+" problem

2021-09-01 Thread otn


New submission from otn :

For opened file as "r+", even if write() then readline(), readline() is 
executed first.

When add tell() after write(), it works correctly.

==
data1 = "aa\nbb\ncc\n"
data2 = "xx\n"

with open("data.txt","w") as f:
f.write(data1)

with open("data.txt","r+") as f:
f.write(data2)
#   f.tell()
print("Line:",repr(f.readline()))

with open("data.txt") as f:
print("All:",repr(f.read()))
==
OUTPUT:
Line: 'aa\n'
All: 'aa\nbb\ncc\nxx\n'

EXPECTED:
Line: 'bb\n'
All: 'xx\nbb\ncc\n'

--
components: IO
messages: 400826
nosy: otn
priority: normal
severity: normal
status: open
title: open "r+" problem
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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

There are places where f is used for an arg or local variable which is a frame, 
so I'll try f_summary when it's a FrameSummary.

--

___
Python tracker 

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



[issue45061] [C API] Detect refcount bugs on True/False in C extensions

2021-09-01 Thread Christian Tismer


Christian Tismer  added the comment:

What about an even more flexible solution?
A debug option could memorize always the last object deallocated
and give full info (the object's repr) before the crash would happen.

--
nosy: +Christian.Tismer

___
Python tracker 

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



[issue45061] [C API] Detect refcount bugs on True/False in C extensions

2021-09-01 Thread Christian Tismer


Christian Tismer  added the comment:

Ah, that would be really much to store: every object with a refcount
going to zero would have to be memorized :/

--

___
Python tracker 

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



[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-09-01 Thread Tobias Bergkvist


Tobias Bergkvist  added the comment:

It seems like _dyld_shared_cache_contains_path exists, while the define flag 
HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH has not been set.

Essentially, the define-flags being used does not seem to agree with the SDK 
version you are using.

Could you try adding HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH like this and see if 
it builds correctly?

clang -Wno-unused-result -Wsign-compare -g -O0 -Wall -arch x86_64 
-mmacosx-version-min=10.9 -Wno-nullability-completeness 
-Wno-expansion-to-defined -Wno-undef-prefix -isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
 -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes 
-Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal 
 -I. -I./Include -arch x86_64 -mmacosx-version-min=10.9 
-Wno-nullability-completeness -Wno-expansion-to-defined -Wno-undef-prefix 
-isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/S
 DKs/MacOSX11.1.sdk -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -DMACOSX -DUSING_MALLOC_CLOSURE_DOT_C=1 
-DHAVE_FFI_PREP_CIF_VAR=1 -DHAVE_FFI_PREP_CLOSURE_LOC=1 
-DHAVE_FFI_CLOSURE_ALLOC=1 -HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH=1 
-DPy_BUILD_CORE_BUILTIN  -I_ctypes/darwin -c ./Modules/_ctypes/callproc.c -o 
Modules/callproc.o

--

___
Python tracker 

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



[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-09-01 Thread Tobias Bergkvist


Tobias Bergkvist  added the comment:

I made a typo (forgetting the -D):

clang -Wno-unused-result -Wsign-compare -g -O0 -Wall -arch x86_64 
-mmacosx-version-min=10.9 -Wno-nullability-completeness 
-Wno-expansion-to-defined -Wno-undef-prefix -isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
 -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes 
-Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal 
 -I. -I./Include -arch x86_64 -mmacosx-version-min=10.9 
-Wno-nullability-completeness -Wno-expansion-to-defined -Wno-undef-prefix 
-isysroot 
/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/S
 DKs/MacOSX11.1.sdk -fPIC 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/ncursesw
 
-I/var/folders/24/8k48jl6d249_n_qfxwsl6xvmgn/T/tmpkfji88v7/tools/deps/include/uuid
 -Werror=unguarded-availability-new   -DMACOSX -DUSING_MALLOC_CLOSURE_DOT_C=1 
-DHAVE_FFI_PREP_CIF_VAR=1 -DHAVE_FFI_PREP_CLOSURE_LOC=1 
-DHAVE_FFI_CLOSURE_ALLOC=1 -DHAVE_DYLD_SHARED_CACHE_CONTAINS_PATH=1 
-DPy_BUILD_CORE_BUILTIN  -I_ctypes/darwin -c ./Modules/_ctypes/callproc.c -o 
Modules/callproc.o

--

___
Python tracker 

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



[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

2021-09-01 Thread Benjamin Szőke

Change by Benjamin Szőke :


--
nosy: +Livius
nosy_count: 5.0 -> 6.0
pull_requests: +26552
pull_request: https://github.com/python/cpython/pull/28111

___
Python tracker 

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



[issue45077] multiprocessing.Pool(64) crashes on Windows

2021-09-01 Thread Kagami Sascha Rosylight


New submission from Kagami Sascha Rosylight :

Similar issue as the previous issue 26903.

```
Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> multiprocessing.cpu_count()
64
>>> multiprocessing.Pool(multiprocessing.cpu_count())
Exception in thread Thread-1:
Traceback (most recent call last):

  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
973, in _bootstrap_inner
>>> self.run()
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
910, in run
self._target(*self._args, **self._kwargs)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 519, in _handle_workers
cls._wait_for_updates(current_sentinels, change_notifier)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 499, in _wait_for_updates
wait(sentinels, timeout=timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 884, in wait
ready_handles = _exhaustive_wait(waithandle_to_obj.keys(), timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 66
```

--
components: Windows
messages: 400832
nosy: paul.moore, saschanaz, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: multiprocessing.Pool(64) crashes on Windows
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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Irit Katriel


Change by Irit Katriel :


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

___
Python tracker 

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



[issue43976] Allow Python distributors to add custom site install schemes

2021-09-01 Thread Filipe Laíns

Filipe Laíns  added the comment:

Matthias, can you check if bpo-44982 solves your issues related to the 
conflicts you were experiencing for the Debian patching?

If so, it would unblock this issue.

I am probably gonna discuss this proposal with the conda-forge folks next week, 
to get some feedback from the Conda perspective.
I would like to have this unblocked so that we can move forward, as far as I 
know the only issues are the ones Debian is experiencing about this proposal 
alone not being able to completely replace the downstream patching.

--

___
Python tracker 

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



[issue45077] multiprocessing.Pool(64) crashes on Windows

2021-09-01 Thread Kagami Sascha Rosylight


Kagami Sascha Rosylight  added the comment:

The argument-less instantiation also fails, which is worse.

```
>>> multiprocessing.Pool()

>>> Exception in thread Thread-1:
Traceback (most recent call last):
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
973, in _bootstrap_inner
self.run()
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\threading.py", line 
910, in run
self._target(*self._args, **self._kwargs)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 519, in _handle_workers
cls._wait_for_updates(current_sentinels, change_notifier)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\pool.py",
 line 499, in _wait_for_updates
wait(sentinels, timeout=timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 884, in wait
ready_handles = _exhaustive_wait(waithandle_to_obj.keys(), timeout)
  File 
"C:\Users\sasch\AppData\Local\Programs\Python\Python39\lib\multiprocessing\connection.py",
 line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 66
```

--

___
Python tracker 

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



[issue43592] test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

x86-64 macOS 3.10:
https://buildbot.python.org/all/#/builders/681/builds/345

==
FAIL: test_multiprocessing_pool_circular_import 
(test.test_importlib.test_threaded_import.ThreadedImportTests)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/test_importlib/test_threaded_import.py",
 line 258, in test_multiprocessing_pool_circular_import
script_helper.assert_python_ok(fn)
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/support/script_helper.py",
 line 160, in assert_python_ok
return _assert_python(True, *args, **env_vars)
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/support/script_helper.py",
 line 145, in _assert_python
res.fail(cmd_line)
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/support/script_helper.py",
 line 72, in fail
raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: 
['/Users/buildbot/buildarea/3.10.billenstein-macos/build/python.exe', '-X', 
'faulthandler', '-I', 
'/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/test_importlib/partial/pool_in_threads.py']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/test/test_importlib/partial/pool_in_threads.py",
 line 9, in t
with multiprocessing.Pool(1):
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/context.py",
 line 119, in Pool
return Pool(processes, initializer, initargs, maxtasksperchild,
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/pool.py",
 line 212, in __init__
self._repopulate_pool()
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/pool.py",
 line 303, in _repopulate_pool
return self._repopulate_pool_static(self._ctx, self.Process,
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/pool.py",
 line 326, in _repopulate_pool_static
w.start()
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/process.py",
 line 121, in start
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/context.py",
 line 284, in _Popen
return Popen(process_obj)
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/popen_spawn_posix.py",
 line 32, in __init__
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/popen_fork.py",
 line 19, in __init__
self._launch(process_obj)
  File 
"/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/popen_spawn_posix.py",
 line 53, in _launch
OSError: [Errno 24] Too many open files
/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:224:
 UserWarning: resource_tracker: There appear to be 120 leaked semaphore objects 
to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237:
 UserWarning: resource_tracker: '/mp-klnfwvgv': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/buildbot/buildarea/3.10.billenstein-macos/build/Lib/multiprocessing/resource_tracker.py:237:
 UserWarning: resource_tracker: '/mp-phgypx9f': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
---

--

___
Python tracker 

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



[issue43592] test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

> x86-64 macOS 3.10: https://buildbot.python.org/all/#/builders/681/builds/345

On this machine, RLIMIT_NOFILE soft limit is 256.

test.pythoninfo:

resource.RLIMIT_NOFILE: (256, 9223372036854775807)
platform.platform: macOS-11.5.2-x86_64-i386-64bit
socket.hostname: mattb-mbp2

All limits:

resource.RLIMIT_AS: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_CORE: (0, 9223372036854775807)
resource.RLIMIT_CPU: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_DATA: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_FSIZE: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_MEMLOCK: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_NOFILE: (256, 9223372036854775807)
resource.RLIMIT_NPROC: (2784, 4176)
resource.RLIMIT_RSS: (9223372036854775807, 9223372036854775807)
resource.RLIMIT_STACK: (67104768, 67104768)
resource.pagesize: 4096

--

___
Python tracker 

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



[issue43592] test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()

2021-09-01 Thread Łukasz Langa

Łukasz Langa  added the comment:

Try setting the following:

$ sudo sysctl -w kern.maxfiles=65536
$ sudo sysctl -w kern.maxfilesperproc=65536
$ sudo ulimit -n 65536

--
nosy: +lukasz.langa

___
Python tracker 

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



[issue43592] test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()

2021-09-01 Thread Łukasz Langa

Łukasz Langa  added the comment:

Before you do it, check the defaults with:

$ launchctl limit maxfiles

I'm curious.

--

___
Python tracker 

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



[issue45061] [C API] Detect refcount bugs on True/False in C extensions

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

Christian Tismer: "What about an even more flexible solution? A debug option 
could memorize always the last object deallocated and give full info (the 
object's repr) before the crash would happen."

Bugs in object_dealloc() are rare. Apart None, True and False, do you know 
other objects which must not be deleted?

Calling repr(obj) can crash during late Python finalization for many reasons.

It is slow and can consume significant memory. Not all object types detect 
loops (a container storing indirectly itself) and so it can fail with a 
MemoryError: repr() is not "safe".

Using gdb, it is easy to dump the object currently being deleted: go the 
object_dealloc() frame and use "print self" command.

Example using attached os_uname_refcount_bug.patch:

$ gdb ./python
(...)
(gdb) run
>>> import os; os.uname()
>>> exit()

Debug memory block at address p=0x886e60: API ''
0 bytes originally requested
The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd):
at p-7: 0x00 *** OUCH
at p-6: 0x00 *** OUCH
at p-5: 0x00 *** OUCH
at p-4: 0x00 *** OUCH
at p-3: 0x00 *** OUCH
at p-2: 0x00 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes requested
   may be bogus, and checking the trailing pad bytes may segfault.
The 8 pad bytes at tail=0x886e60 are not all FORBIDDENBYTE (0xfd):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
at tail+4: 0x00 *** OUCH
at tail+5: 0x00 *** OUCH
at tail+6: 0x00 *** OUCH
at tail+7: 0x00 *** OUCH

Enable tracemalloc to get the memory block allocation traceback

Fatal Python error: _PyMem_DebugRawFree: bad ID: Allocated using API '', 
verified using API 'o'
Python runtime state: finalizing (tstate=0x008e1a80)

Current thread 0x77c24740 (most recent call first):
  Garbage-collecting
  

Program received signal SIGABRT, Aborted.
0x77c662a2 in raise () from /lib64/libc.so.6

(...)

(gdb) frame 9
#9  0x00499dd7 in object_dealloc (self=True)
at Objects/typeobject.c:4497
4497Py_TYPE(self)->tp_free(self);

(gdb) print self
$2 = True


--

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

>  I changed dash_R_cleanup to put the sys._clear_type_cache() after 
> clear_caches() and the leak is gone

Aha! The order of function calls in dash_R_cleanup() matters.

Calling sys._clear_type_cache() at the end of dash_R_cleanup() perfectly makes 
sense. If you do that, please add a comment to explain that the order matters. 
For example, the code about ABC classes is likely to modify classes.

About the gc_collect() call, I dislike calling it in clear_caches() and then 
again in dash_R_cleanup(). I would even prefer to *remove* it from both 
functions and call it explicitly at the call site: in dash_R() and in 
runtest.py.

--

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Chris Jerdonek


Chris Jerdonek  added the comment:

It might be good to have consistency with what will be used for StackSummary so 
two different approaches to naming aren't used.

By the way, frame_sum is another possibility since I see frame_gen being used.

--
nosy: +chris.jerdonek

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

I'm not sure I follow. We don't have a similar issue with StackSummary - there 
is no interpreter type for "stack" that you can confuse it with.

--

___
Python tracker 

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



[issue45076] open "r+" problem

2021-09-01 Thread Zachary Ware


Zachary Ware  added the comment:

Usage questions like this are better suited to the Users category at 
https://discuss.python.org/c/users/7 or the python-l...@python.org mailing list.

The write is buffered.  If you want it to be written before you read, add 
`f.flush()` after the write; `f.tell()` causes an implicit flush.  See also the 
`buffering` argument to `open`.

--
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


--
keywords: +patch
pull_requests: +26554
pull_request: https://github.com/python/cpython/pull/28113

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 679cb4781ea370c3b3ce40d3334dc404d7e9d92b by Victor Stinner in 
branch 'main':
bpo-44895: libregrtest: refleak check clears types later (GH-28113)
https://github.com/python/cpython/commit/679cb4781ea370c3b3ce40d3334dc404d7e9d92b


--

___
Python tracker 

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



[issue31962] test_importlib double free or corruption

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

I close the issue as out of date, since there is no activity for 4 years. Maybe 
it was fixed in the meanwhile.

If it's not the case, please reopen the issue. If someone can still reproduce 
the issue, it would help to write a short reproducer script based on the test 
causing the crash.

--
nosy: +vstinner
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



[issue39326] Python-3.8.1 "test_importlib" failed

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

> Can you please attach the output log of the test?

Since the original reporter didn't reply, we cannot investigate the issue and I 
close it. If you still have the issue, please reopen the issue with the full 
test output (attached as a file).

--
nosy: +vstinner
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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread STINNER Victor


New submission from STINNER Victor :

Since build 305 (commit a40675c659cd8c0699f85ee9ac31660f93f8c2f5), 
test_importlib fails on AMD64 Windows8.1 Non-Debug 3.x:
https://buildbot.python.org/all/#/builders/405/builds/305

The last successful build wa the build 304 (commit 
ee03bad25e83b00ba5fc2a0265b48c6286e6b3f7).

Sadly, the test doesn't report the 'actual' variable value when the test fails.

==
FAIL: test_read_bytes (test.test_importlib.test_files.OpenNamespaceTests)
--
Traceback (most recent call last):
  File 
"D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_importlib\test_files.py",
 line 14, in test_read_bytes
assert actual == b'Hello, UTF-8 world!\n'
^
AssertionError

--
components: Tests
messages: 400847
nosy: brett.cannon, jaraco, vstinner
priority: normal
severity: normal
status: open
title: test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x
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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

With your patch I don't see a leak for refleak.py, but I still see one for 

./python.exe -m test -R 3:3 test_exceptions -m 
test_no_hang_on_context_chain_cycle2 -m 
test_recursion_normalizing_infinite_exception -m 
test_recursion_in_except_handler -m test_recursion_normalizing_with_no_memory 
-F -j1

(once I remove the @skip on test_no_hang_on_context_chain_cycle2). 


However, if I make this change it looks better:


--- a/Lib/test/libregrtest/refleak.py
+++ b/Lib/test/libregrtest/refleak.py
@@ -90,8 +90,9 @@ def get_pooled_int(value):
 for i in rep_range:
 test_func()
 
-dash_R_cleanup(fs, ps, pic, zdc, abcs)
-support.gc_collect()
+for i in range(3):
+dash_R_cleanup(fs, ps, pic, zdc, abcs)
+support.gc_collect()

--

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Chris Jerdonek


Chris Jerdonek  added the comment:

I was suggesting keeping more similarity between FrameSummary and StackSummary 
in addition to differentiating frame from FrameSummary. Since stack is used for 
StackSummary, frame_sum is more similar than f_summary while still providing 
the differentiation.

--

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

Interesting commits from:
$ git log  
ee03bad25e83b00ba5fc2a0265b48c6286e6b3f7..a40675c659cd8c0699f85ee9ac31660f93f8c2f5
  

commit aaa83cdfab6817446285e631232f64b394ac6791
Author: Jason R. Coombs 
Date:   Thu Jul 29 21:05:05 2021 -0400

bpo-44771: Apply changes from importlib_resources 5.2.1 (GH-27436)

* bpo-44771: Apply changes from importlib_resources@3b24bd6307

* Add blurb

* Exclude namespacedata01 from eol conversion.

--

___
Python tracker 

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



[issue44771] Adopt changes from importlib_resources 5.2

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

test_importlib.test_read_bytes() is failing for 1 month on AMD64 Windows8.1 
Non-Debug 3.x. Please see bpo-45078, the regression may be caused by the commit 
aaa83cdfab6817446285e631232f64b394ac6791.

--
nosy: +vstinner

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

Maybe Git does change the end of line of 
Lib/test/test_importlib/namespacedata01/utf-8.file file, even if .gitattributes 
contains:
"Lib/test/test_importlib/namespacedata01/* -text"

--

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

> (once I remove the @skip on test_no_hang_on_context_chain_cycle2). 

Oh. I forgot that the test is still skipped!


> With your patch I don't see a leak for refleak.py, but I still see one for 
> ./python.exe -m test -R 3:3 test_exceptions -m 
> test_no_hang_on_context_chain_cycle2 -m 
> test_recursion_normalizing_infinite_exception -m 
> test_recursion_in_except_handler -m test_recursion_normalizing_with_no_memory 
> -F -j1

If I apply attached strict_refleak_check.patch and I remove @unittest.skip("See 
issue 44895") of test_no_hang_on_context_chain_cycle2(), I get:

$ ./python -m test -R 3:3 test_exceptions -m 
test_no_hang_on_context_chain_cycle2 -m 
test_recursion_normalizing_infinite_exception -m 
test_recursion_in_except_handler -m test_recursion_normalizing_with_no_memory

(...)
test_exceptions leaked [6, -6, 6] references, sum=6
(...)

--

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

I changed it to 

+for i in range(2):
+dash_R_cleanup(fs, ps, pic, zdc, abcs)
+support.gc_collect()


(loop twice instead of 3 times) and that seems fine too.

--

___
Python tracker 

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



[issue45020] Freeze all modules imported during startup.

2021-09-01 Thread Eric Snow


Eric Snow  added the comment:

On Tue, Aug 31, 2021 at 10:05 PM Inada Naoki  wrote:
> I don't want all frozen header files to be committed in git repository.
> Can't we just build them during build process?

That's a good point (and an interesting one).  Only two of the frozen
modules are necessary (_frozen_importlib_external and
_frozen_importlib_external, to bootstrap the import system).  So for
those two it makes sense to have them in the git repository.

For all the rest it isn't necessary.  The only advantage is that
contributors don't have to think about them and they will be
guaranteed to be there.  However, if someone clones the repo they have
to build Python, so the frozen modules will get created anyway at that
point.

So I'm fine with not committing all those modules.  This will require
that all those files be added to the .gitignore file.  (I'll update my
PR accordingly.)

-eric

--

___
Python tracker 

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



[issue45020] Freeze all modules imported during startup.

2021-09-01 Thread Eric Snow


Eric Snow  added the comment:

On Tue, Aug 31, 2021 at 12:14 PM Brett Cannon  wrote:
> > set __file__ (and __path__) on frozen modules?
>
> See https://bugs.python.org/issue21736

Great!  I'll take a look.

--

___
Python tracker 

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



[issue44895] refleak test failure in test_exceptions

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


Added file: https://bugs.python.org/file50251/strict_refleak_check.patch

___
Python tracker 

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



[issue45079] 3.8.11 and 3.8.12 missing Windows artifacts, only tarballs - build system failed?

2021-09-01 Thread Arcadiy Ivanov


New submission from Arcadiy Ivanov :

The following versions only contain tarballs with no Windows artifacts 
available. Is the build system OK?

https://www.python.org/ftp/python/3.8.12/
https://www.python.org/ftp/python/3.8.11/

.10 is fine:
https://www.python.org/ftp/python/3.8.10/
Latest 3.9 is OK as well.

--
components: Windows
messages: 400857
nosy: arcivanov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.8.11 and 3.8.12 missing Windows artifacts, only tarballs - build 
system failed?
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



[issue45080] functools._HashedSeq implements __hash__ but not __eq__

2021-09-01 Thread Leopold Talirz


New submission from Leopold Talirz :

Disclaimer: this is my first issue on the python bug tracker. Please feel free 
to close this issue and redirect this to a specific mailing list, if more 
appropriate.


The implementation of `functools._HashedSeq` [1] does not include an 
implementation of `__eq__` that takes advantage of the hash:
```
class _HashedSeq(list):
""" This class guarantees that hash() will be called no more than once
per element.  This is important because the lru_cache() will hash
the key multiple times on a cache miss.
"""

__slots__ = 'hashvalue'

def __init__(self, tup, hash=hash):
self[:] = tup
self.hashvalue = hash(tup)

def __hash__(self):
return self.hashvalue
```
As far as I can tell, the `_HashedSeq` object is used as a key for looking up 
values in the python dictionary that holds the LRU cache, and this lookup 
mechanism relies on `__eq__` over `__hash__` (besides shortcuts for objects 
with the same id, etc.).

This can cause potentially expensive `__eq__` calls on the arguments of the 
cached function and I wonder whether this is intended?

Here is a short example code to demonstrate this:
```
from functools import _HashedSeq

class CompList(list):
"""Hashable list (please forgive)"""
def __eq__(self, other):
print("equality comparison")
return super().__eq__(other)
def __hash__(self):
return hash(tuple(self))

args1=CompList((1,2,3))  # represents function arguments passed to lru_cache
args2=CompList((1,2,3))  # identical content but different object


hs1=_HashedSeq( (args1,))
hs2=_HashedSeq( (args2,))

hs1 == hs2  # True, prints "equality comparison"

d={}
d[hs1] = "cached"
d[hs2] # "cached", prints "equality comparison"

```

Adding the following to the implementation of `_HashedSeq` gets rid of the 
calls to `__eq__`:
```
def __eq__(self, other):
return self.hashvalue == other.hashvalue
```
Happy to open a PR for this.

I'm certainly a bit out of my depth here, so apologies if that is all intended 
behavior.


[1] 
https://github.com/python/cpython/blob/679cb4781ea370c3b3ce40d3334dc404d7e9d92b/Lib/functools.py#L432-L446

--
components: Library (Lib)
messages: 400858
nosy: leopold.talirz
priority: normal
severity: normal
status: open
title: functools._HashedSeq implements __hash__ but not __eq__
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

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



[issue45079] 3.8.11 and 3.8.12 missing Windows artifacts, only tarballs - build system failed?

2021-09-01 Thread Zachary Ware


Zachary Ware  added the comment:

3.8 is in security-only maintenance mode, which means we no longer provide 
binary installers for this version.  If you need binary installers, we highly 
recommend updating to a version in bugfix maintenance mode, which currently 
means 3.9.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue45079] 3.8.11 and 3.8.12 missing Windows artifacts, only tarballs - build system failed?

2021-09-01 Thread Arcadiy Ivanov


Arcadiy Ivanov  added the comment:

Nevermind. Looks like the policy is not to build binaries once in security 
fixes only mode. I guess the build bot gets tired or something...

--
resolution: not a bug -> wont fix

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Chris Jerdonek


Chris Jerdonek  added the comment:

Or frame_info (more readable), since FrameSummary is proposed to be 
"Information about a single frame from a traceback."

--

___
Python tracker 

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



[issue45075] confusion between frame and frame_summary in traceback module

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

Yes, frame_info is good.

--

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Filipe Laíns

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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



[issue39758] StreamWriter.wait_closed() can hang indefinitely.

2021-09-01 Thread Artem


Artem  added the comment:

See this issue on 3.9.6
No SSL, but plain sockets.
This seems to appear when writer.write/writer.drain was cancelled, and 
writer.close/writer.wait_closed called after this.

--
nosy: +aeros, seer
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



[issue34561] Replace list sorting merge_collapse()?

2021-09-01 Thread Tim Peters


Tim Peters  added the comment:

I created a PR that implements the powersort merge strategy:

https://github.com/python/cpython/pull/28108

Across all the time this issue report has been open, that strategy continues to 
be the top contender. Enough already ;-) It's indeed a more difficult change to 
make to the code, but that's in relative terms. In absolute terms, it's not at 
all a hard change.

Laurent, if you find that some variant of ShiversSort actually runs faster than 
that, let us know here! I'm a big fan of Vincent's innovations too, but 
powersort seems to do somewhat better "on average" than even his 
length-adaptive ShiversSort (and implementing that too would require changing 
code outside of merge_collapse()).

--

___
Python tracker 

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



[issue45069] python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

2021-09-01 Thread Ned Deily


Ned Deily  added the comment:

What problem are you reporting here? Python 3.9.2 is no longer current nor 
supported; the most recent release is 3.9.7, which, among many other changes, 
now uses OpenSSL 1.1.1l.

https://www.python.org/downloads/
https://www.python.org/dev/peps/pep-0596/
https://www.python.org/downloads/

--
nosy: +ned.deily
resolution:  -> out of date
status: open -> pending
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



[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

While we're changing code objects, perhaps consider this as well?

--
nosy: +gvanrossum, iritkatriel

___
Python tracker 

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



[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

2021-09-01 Thread Guido van Rossum


Guido van Rossum  added the comment:

This sounds like a project requiring a considerable amount of plumbing to get 
the info from where it's available to where it's needed. For example, importlib 
reads the PYC file, checks the header, and then passes the rest of the file to 
marshal.loads(), which creates the (nested) code objects. Similarly, when 
reading the PY file, the compile() builtin is called to create the code objects 
without access to metadata other than filename.

I also question whether the software updates that fall prey to this issue are 
being done the right way -- maybe the server should be stopped before moving 
the new files in place. :-)

--

___
Python tracker 

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



[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__

2021-09-01 Thread Julian Fortune


New submission from Julian Fortune :

I believe [`bpo-44806: Fix __init__ in subclasses of 
protocols`](https://github.com/python/cpython/pull/27545) has caused a 
regression when using a Dataclass.

In Python `3.9.7`, a `dataclass` that inherits from a subclass of 
`typing.Protocol` (i.e., a user-defined protocol), does not have the correct 
`__init__`.

### Demonstration

```python
from dataclasses import dataclass
from typing import Protocol

class P(Protocol):
pass

@dataclass
class B(P):
value: str

print(B("test"))
```
In `3.9.7`:
```shell
Traceback (most recent call last):
  File "test.py", line 11, in 
print(B("test"))
TypeError: B() takes no arguments
```
In `3.9.6`:
```shell
B(value='test')
```

### Affected Projects

- [dbt](https://github.com/dbt-labs/dbt/issues/3843)

--
components: Library (Lib)
messages: 400868
nosy: julianfortune
priority: normal
severity: normal
status: open
title: dataclasses that inherit from Protocol subclasses have wrong __init__
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



[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

It's not only a software updates issue - these kinds of problems show up for 
developers when they change the code on disk while a program is running and 
some traceback or pdb show code from the disk which is confusing.

I also saw an issue about changing directory in pdb and picking up a module of 
the same name in a different path (because the filename is relative).

--

___
Python tracker 

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



[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

2021-09-01 Thread Guido van Rossum


Guido van Rossum  added the comment:

All legit cases, I agree, but are they worth the considerable work?

--

___
Python tracker 

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



[issue45082] ctypes: Deprecate c_buffer() alias to create_string_buffer()

2021-09-01 Thread STINNER Victor


New submission from STINNER Victor :

Since the ctypes module was added to the stdlib (commit 
babddfca758abe34ff12023f63b18d745fae7ca9 in 2006), ctypes.c_buffer() was an 
alias to ctypes.create_string_buffer(). The implementation contains a commented 
deprecation:

def c_buffer(init, size=None):
##"deprecated, use create_string_buffer instead"
##import warnings
##warnings.warn("c_buffer is deprecated, use create_string_buffer instead",
##  DeprecationWarning, stacklevel=2)
return create_string_buffer(init, size)

I propose to start to deprecate ctypes.c_buffer(): use 
ctypes.create_string_buffer() directly.

In older ctypes version, the function was called c_string(): it's still 
mentioned in the ctypes documentation. This legacy is confusion, and it's time 
to simplify the API to provide a single function.

--
components: ctypes
messages: 400871
nosy: vstinner
priority: normal
severity: normal
status: open
title: ctypes: Deprecate c_buffer() alias to create_string_buffer()
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



[issue45082] ctypes: Deprecate c_buffer() alias to create_string_buffer()

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


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

___
Python tracker 

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



[issue45076] open "r+" problem

2021-09-01 Thread otn


otn  added the comment:

It works correct for ver2.6, and also "rb+".
Buffering procsess should work the same as those case.

--

___
Python tracker 

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



[issue45083] Incorrect exception output in C

2021-09-01 Thread Irit Katriel


New submission from Irit Katriel :

iritkatriel@Irits-MBP cpython % cat exc.py 

class A:
  class B:
class E(Exception):
  pass

raise A.B.E()

iritkatriel@Irits-MBP cpython % cat test.py 

import exc


iritkatriel@Irits-MBP cpython % ./python.exe test.py 
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/test.py", line 2, in 
import exc
^^
  File "/Users/iritkatriel/src/cpython/exc.py", line 7, in 
raise A.B.E()
^
exc.E




==
See the last line of the output: there is no such thing as exc.E. There is 
exc.A.B.E.

The traceback module doesn't have this issue:

iritkatriel@Irits-MBP cpython % cat test.py 

import traceback

try:
  import exc
except Exception as e:
  traceback.print_exception(e)


iritkatriel@Irits-MBP cpython % ./python.exe test.py 
Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/test.py", line 5, in 
import exc
^^
  File "/Users/iritkatriel/src/cpython/exc.py", line 7, in 
raise A.B.E()
^
exc.A.B.E

--
components: Interpreter Core
messages: 400873
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Incorrect exception output in C
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



[issue39758] StreamWriter.wait_closed() can hang indefinitely.

2021-09-01 Thread Stanislav Beblo


Change by Stanislav Beblo :


--
components: +Build, C API, Parser, Tests, email
nosy: +barry, lys.nikolaou, pablogsal, r.david.murray
type: behavior -> performance
versions: +Python 3.10, Python 3.11 -Python 3.7

___
Python tracker 

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



[issue39758] StreamWriter.wait_closed() can hang indefinitely.

2021-09-01 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


--
components:  -Build, C API, Parser, Tests, email
nosy:  -pablogsal

___
Python tracker 

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



[issue45084] urllib.parse: remove deprecated functions (splittype, to_bytes, etc.)

2021-09-01 Thread STINNER Victor


New submission from STINNER Victor :

bpo-27485 deprecated the following urllib.parse undocumented functions in 
Python 3.8:

* splitattr()
* splithost()
* splitnport()
* splitpasswd()
* splitport()
* splitquery()
* splittag()
* splittype()
* splituser()
* splitvalue()
* to_bytes()

(commit 0250de48199552cdaed5a4fe44b3f9cdb5325363)

I propose to remove them. See attached PR.


Note: The Quoter class is only deprecated since Python 3.11. It should be kept 
around for 2 releases (not removed before Python 3.13): PEP 387.

--
components: Library (Lib)
messages: 400874
nosy: vstinner
priority: normal
severity: normal
status: open
title: urllib.parse: remove deprecated functions (splittype, to_bytes, etc.)
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



[issue45084] urllib.parse: remove deprecated functions (splittype, to_bytes, etc.)

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


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

___
Python tracker 

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



[issue27485] urllib.splitport -- is it official or not?

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

Follow-up: I created bpo-45084 to remove these undocumented and deprecated 
functions in Python 3.11.

--
nosy: +vstinner

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


--
nosy: +vstinner
nosy_count: 11.0 -> 12.0
pull_requests: +26557
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28116

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

I created PR 28116 to deprecate the lib2to3 package: replace 
PendingDeprecationWarning to DeprecationWarning.

In 2021, I don't think that we should keep the 2to3 tool in the stdlib. Python 
2 reached end of line 1 year ago.

For the lib2to3 *parser*, IMO it would be better to maintain it outside the 
stdlib, and collaborate with other existing forks, like the parser used by 
Black.

The change is only about *deprecating* lib2to3, not *remove* it. For the 
removal, we should check if major projects which used it moved to something 
else.

It's kind of a shame that Python stdlib (lib2to3) cannot parse valid Python 
3.10 code :-( IMO it's better to deprecate (and then remove) lib2to3.

--

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

I retarget this issue to Python 3.11, since lib2to3 is *not* deprecated in 
Python 3.10.

--
versions: +Python 3.11 -Python 3.10

___
Python tracker 

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



[issue39353] Deprecate the binhex module

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


--
title: Deprecate the binhex module, binhex4 and hexbin4 standards -> Deprecate 
the binhex module

___
Python tracker 

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



[issue39353] Deprecate the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


--
title: Deprecate the binhex module -> Deprecate the binhex module, binhex4 and 
hexbin4 standards

___
Python tracker 

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



[issue45085] Remove the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


New submission from STINNER Victor :

The binhex module was deprecated in Python 3.9 by bpo-39353 (commit 
beea26b57e8c80f1eff0f967a0f9d083a7dc3d66). I propose to remove it: see attached 
PR.

The PR also removes the following binascii functions, also deprecated in Python 
3.9:

* a2b_hqx(), b2a_hqx()
* rlecode_hqx(), rledecode_hqx()

The binascii.crc_hqx() function remains available.

--
components: Library (Lib)
messages: 400878
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove the binhex module, binhex4 and hexbin4 standards
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



[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__

2021-09-01 Thread Eric V. Smith


Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread Guido van Rossum


Guido van Rossum  added the comment:

How come the deprecation didn't happen in 3.10? Were people just not
interested?

--

___
Python tracker 

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



[issue45085] Remove the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


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

___
Python tracker 

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



[issue45085] Remove the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

See also the PEP 594: Removing dead batteries from the standard library
https://www.python.org/dev/peps/pep-0594/

--

___
Python tracker 

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



[issue45085] Remove the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

The binhex module was deprecated in Python 3.9 by bpo-39353 (commit 
beea26b57e8c80f1eff0f967a0f9d083a7dc3d66). I have been asked there to keep 
binascii.crc_hqx() (not deprecated it).

--

___
Python tracker 

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



[issue45085] Remove the binhex module, binhex4 and hexbin4 standards

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

In bpo-39353, Serhiy Storchaka proposed: "But it would be nice to create a 
separate package on PyPI that provides such functionality before removing it 
from the stdlib."

The purpose of the PEP 594 is to reduce the Python maintenance burden. 
Publishing a module on PyPI introduces a new maintenance burden, even if there 
is no plan to ever update the package.

The PEP 594 is still a draft. So far, there was no agreement on the strategy to 
remove anything from the stdlib.

In past, other stdlib modules have been removed silently and nobody complained. 
Likely because nobody used them. For example, the the Python 2 CDROM module of 
the old Lib/plat-linux2/ directory (CDROM.py, DLFCN.py, IN.py, regen, TYPES.py).

If someone uses the binhex module, I suggest users to create a new project on 
PyPI to support binhex. Users who need binhex are likely the most motivated to 
*maintain* such code. You can start by copying Python 3.10 code.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

I think we just forgot to make the change in time.  3.11 is fine.  We're not 
_maintaining_ lib2to3 or describing it as fit for any modern purpose 
regardless.  It's just code that'll sit around in the back of the 3.10 stdlib 
but not be able to parse the new syntax in 3.10.

--

___
Python tracker 

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



[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

2021-09-01 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +26559
pull_request: https://github.com/python/cpython/pull/28118

___
Python tracker 

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



[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

I reopen the issue. I created PR 28118 to try again to remove the "U" mode in 
Python 3.11.

--
resolution: fixed -> 
status: closed -> open
versions: +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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

Guido: How come the deprecation didn't happen in 3.10? Were people just not 
interested?

Well, if nobody deprecates it, it's not deprecated. It is simple as it it :-)

IMO it's ok to only deprecate it in Python 3.11, unless Pablo *really* wants to 
deprecate lib2to3 before just Python 3.10 final.

I dislike adding new warnings between a beta1 release and the final release :-( 
In my experience, it *does* break projects which care of warnings.

--

___
Python tracker 

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



[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__

2021-09-01 Thread Edgar Ramírez

Change by Edgar Ramírez :


--
nosy: +edgarrmondragon

___
Python tracker 

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



[issue45083] Incorrect exception output in C

2021-09-01 Thread Irit Katriel


Change by Irit Katriel :


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

___
Python tracker 

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



[issue45083] Need to use the exception class qualname when rendering exception (in C code)

2021-09-01 Thread Irit Katriel


Change by Irit Katriel :


--
title: Incorrect exception output in C -> Need to use the exception class 
qualname when rendering exception (in C code)

___
Python tracker 

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



[issue45083] Need to use the exception class qualname when rendering exception (in C code)

2021-09-01 Thread Irit Katriel


Irit Katriel  added the comment:

I've reproduced this on 3.9 and 3.10 as well.

--
versions: +Python 3.10, Python 3.9

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

There is an issue where that file originally got EOL conversions, so all 
Windows buildbots were failing (issue44779).

I'd thought we'd worked around the issue by pushing out a PR that deleted the 
file and ensuring it ran on the buildbots 
(https://github.com/python/cpython/pull/27436#issuecomment-890029487).

I knew it was a risk, however, that either that PR failed to checkout on the 
buildbot, checked out on a different shard, or that another PR subsequently 
managed to check out the code without the .gitattributes fix.

--

___
Python tracker 

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



[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

2021-09-01 Thread STINNER Victor


STINNER Victor  added the comment:

> This breaks Samba's build:
> https://bugzilla.samba.org/show_bug.cgi?id=14266

Samba has been updated in the meanwhile, buildtools/wafsamba/samba_utils.py:

-function_code = node.read('rU', None)
+function_code = node.read('r', None)

https://github.com/samba-team/samba/blob/1209c89dcf6371bbfa4f3929a47a573ef2916c1a/buildtools/wafsamba/samba_utils.py#L692

--

___
Python tracker 

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



[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

2021-09-01 Thread STINNER Victor

STINNER Victor  added the comment:

> docutils is already fixed in the development version. I requested a release: 
> https://sourceforge.net/p/docutils/bugs/364/

At 2019-07-22,  Günter Milde wrote: "Docutils 0.15 is released" (with the fix). 
The latest docutils version is 0.17.1.

--

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I'm going to attempt that technique again and see if it's sufficient to bypass 
the symptom.

--

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Jason R. Coombs


Change by Jason R. Coombs :


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

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I've submitted a PR that deletes the file and requested it be built by the 
buildbots, but I also see that that bot hasn't built anything in 7 days 
(https://buildbot.python.org/all/#/builders/405), so I'm not hopeful my request 
for it to build that change will have any effect on that builder.

--
stage: patch review -> 

___
Python tracker 

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



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2021-09-01 Thread Guido van Rossum


Guido van Rossum  added the comment:

We can add to the 3.10 docs that it is deprecated without any code change. And 
in 3.11 we can add a warning.

--

___
Python tracker 

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



[issue45078] test_importlib: test_read_bytes() fails on AMD64 Windows8.1 Non-Debug 3.x

2021-09-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I'm not confident that I can get the message to the buildbot, so I sent a 
message to python-buildb...@python.org requesting to run the workaround on the 
buildbot. The message was flagged for moderation. My hope is that eventually 
goes through and will address the issue.

--
status: open -> pending

___
Python tracker 

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



[issue45067] Failed to build _curses on CentOS 7

2021-09-01 Thread Senthil Kumaran

Senthil Kumaran  added the comment:

Here is the output of make with relevant lines.

 CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv 
-O3 -Wall'  _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E ./setup.py  
build
running build
running build_ext
building '_curses' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 
-Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Werror=implicit-function-declaration 
-fvisibility=hidden -I./Include/internal -DHAVE_NCURSESW=1 
-I/usr/include/ncursesw -I./Include -I. -I/usr/local/include 
-I/local/home/senthilx/cpython/Include -I/local/home/senthilx/cpython -c 
/local/home/senthilx/cpython/Modules/_cursesmodule.c -o 
build/temp.linux-x86_64-3.11/local/home/senthilx/cpython/Modules/_cursesmodule.o
 -DPy_BUILD_CORE_MODULE
/local/home/senthilx/cpython/Modules/_cursesmodule.c: In function 
‘_curses_color_content_impl’:
/local/home/senthilx/cpython/Modules/_cursesmodule.c:149:41: error: implicit 
declaration of function ‘extended_color_content’; did you mean 
‘_curses_color_content’? [-Werror=implicit-function-declaration]
 #define _COLOR_CONTENT_FUNC extended_color_content
 ^
/local/home/senthilx/cpython/Modules/_cursesmodule.c:2746:9: note: in expansion 
of macro ‘_COLOR_CONTENT_FUNC’
 if (_COLOR_CONTENT_FUNC(color_number, &r, &g, &b) == ERR) {
 ^~~
/local/home/senthilx/cpython/Modules/_cursesmodule.c: In function 
‘_curses_init_color_impl’:
/local/home/senthilx/cpython/Modules/_cursesmodule.c:147:41: error: implicit 
declaration of function ‘init_extended_color’; did you mean ‘initialize_color’? 
[-Werror=implicit-function-declaration]
 #define _CURSES_INIT_COLOR_FUNC init_extended_color
 ^
/local/home/senthilx/cpython/Modules/_cursesmodule.c:3194:29: note: in 
expansion of macro ‘_CURSES_INIT_COLOR_FUNC’
 return PyCursesCheckERR(_CURSES_INIT_COLOR_FUNC(color_number, r, g, b),
 ^~~
/local/home/senthilx/cpython/Modules/_cursesmodule.c: In function 
‘_curses_init_pair_impl’:
/local/home/senthilx/cpython/Modules/_cursesmodule.c:148:41: error: implicit 
declaration of function ‘init_extended_pair’; did you mean 
‘use_extended_names’? [-Werror=implicit-function-declaration]
 #define _CURSES_INIT_PAIR_FUNC  init_extended_pair
 ^
/local/home/senthilx/cpython/Modules/_cursesmodule.c:3222:9: note: in expansion 
of macro ‘_CURSES_INIT_PAIR_FUNC’
 if (_CURSES_INIT_PAIR_FUNC(pair_number, fg, bg) == ERR) {
 ^~
/local/home/senthilx/cpython/Modules/_cursesmodule.c: In function 
‘_curses_pair_content_impl’:
/local/home/senthilx/cpython/Modules/_cursesmodule.c:150:41: error: implicit 
declaration of function ‘extended_pair_content’; did you mean 
‘_curses_pair_content’? [-Werror=implicit-function-declaration]
 #define _CURSES_PAIR_CONTENT_FUNC   extended_pair_content
 ^
/local/home/senthilx/cpython/Modules/_cursesmodule.c:3868:9: note: in expansion 
of macro ‘_CURSES_PAIR_CONTENT_FUNC’
 if (_CURSES_PAIR_CONTENT_FUNC(pair_number, &f, &b) == ERR) {
 ^
cc1: some warnings being treated as errors
building '_curses_panel' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 
-Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Werror=implicit-function-declaration 
-fvisibility=hidden -I./Include/internal -DHAVE_NCURSESW=1 
-I/usr/include/ncursesw -I./Include -I. -I/usr/local/include 
-I/local/home/senthilx/cpython/Include -I/local/home/senthilx/cpython -c 
/local/home/senthilx/cpython/Modules/_curses_panel.c -o 
build/temp.linux-x86_64-3.11/local/home/senthilx/cpython/Modules/_curses_panel.o
gcc -pthread -shared 
build/temp.linux-x86_64-3.11/local/home/senthilx/cpython/Modules/_curses_panel.o
 -L/usr/local/lib -lpanelw -lncursesw -o 
build/lib.linux-x86_64-3.11/_curses_panel.cpython-311-x86_64-linux-gnu.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module 
named '_curses'

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc  pwd   time


Failed to build these modules:
_curses


Following modules built successfully but were removed because they could not be 
imported:
_curses_panel

running build_scripts
copying and adjusting /local/home/senthilx/cpython/Tools/scripts/pydoc3 -> 
build/scripts-3.11
copying and adjusting /local/home/senthilx/cpython/Tools/scripts/idle3 -> 
build/scripts-3.11
copying and adjusting /local/home/senthilx/cpython/Tools/scripts/2to3 -> 
build/scripts-3.11
changing mode of build/scripts-3.11/pydoc3

[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-09-01 Thread Gregory Szorc


Gregory Szorc  added the comment:

Oh, this might be my custom Modules file not passing the 
HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH define properly. I suspect I was working 
around this bug before by disabling the dyld bits. Sorry for the noise! (I 
should have reproduced with CPython's build system.)

--

___
Python tracker 

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



  1   2   >