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

[Ned Deily]

Ned Deily  added the comment:

I don't think we have ever claimed to support building on an older system with 
a newer SDK, as in building on 10.15 with an 11 SDK. I am sure there have been 
problems with trying to do this in the past for some releases.  It *may* work 
but there are no guarantees. If you want to build on an older system you should 
use the SDK for that system even if a newer version of Xcode / Command Line 
Tools is released that provides the newer SDK.  That said, I have no objection 
to trying to fix this issue but I think we should avoid claiming to support 
such configurations and I don't see this issue as needing to make a new 
release. I am willing to be convinced otherwise :)

--

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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

1. self.hashvalue == other.hashvalue is not enough. Different tuples can have 
the same hash value, so you steel need to compare their context.

2. _HashedSeq is only used as a key in a dictionary. When you look up a key in 
dictionary, it compares hashes first. __eq__ is only called when hashes match.

--
nosy: +rhettinger, serhiy.storchaka

___
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

[Inada Naoki]

Change by Inada Naoki :


Added file: https://bugs.python.org/file50255/unused_trimmed.txt

___
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

[Inada Naoki]

Change by Inada Naoki :


Added file: https://bugs.python.org/file50254/unused_310rc1.txt

___
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

[Inada Naoki]

Change by Inada Naoki :


Added file: https://bugs.python.org/file50253/unused_39.txt

___
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

[Inada Naoki]

Change by Inada Naoki :


Added file: https://bugs.python.org/file50252/dump_unused_consts.py

___
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

[Gregory Szorc]

Gregory Szorc  added the comment:

I spoke too soon: you can reproduce this with CPython's build system and I 
think this is a legit regression.

I think the function sniffing logic is subtly wrong.

Here is the logic as written:

#ifdef __APPLE__
  #ifdef HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH
#define HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME \
  __builtin_available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *)
  #else
static bool (*_dyld_shared_cache_contains_path)(const char *path);

  #define HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME \
  _dyld_shared_cache_contains_path != NULL
  #endif
#endif

The fundamental problem is that HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH comes from 
configure. Configure is using the target settings to probe for function 
presence. If I set the deployment target to 10.9, it says `checking for 
_dyld_shared_cache_contains_path... no`. But if I set the deployment target to 
11.0, it says `checking for _dyld_shared_cache_contains_path... yes`. Because 
we may be targeting a macOS without the function, the function appears as not 
available to configure. It may exist in the SDK, but it is masked behind 
availability checks for the test compile.

The logic as written assumes that !HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH means 
the SDK doesn't contain the function at all. This just isn't true for SDKs >= 
11.0.

If you look at posixmodule.c, the logic for checking for function availability 
is typically this pattern:

#ifdef __APPLE__
  #ifdef HAVE_BUILTIN_AVAILABLE
#define HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME \
  __builtin_available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *)
  #else
#ifdef HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH 
  #define HAVE_DYLD_SHARED_CACHE_CONTAINS_PATH_RUNTIME 
(_dyld_shared_cache_contains_path != NULL)
#endif
  #endif
#endif

This other pattern also reveals another regression with this patch: 
__builtin_available() may not be available on older compilers. See issue42692. 
I'm unsure what "older compilers" actually is. But someone is bound to complain 
about this (if they haven't already).

Do these build regressions warrant an unplanned 3.9.8 release?

--

___
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

[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

[issue45067] Failed to build _curses on CentOS 7

[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, , , ) == 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, , ) == 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 from 644 

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

[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

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

[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

[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

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

[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

[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

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

[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

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

[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

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

[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

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

[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

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

[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] Incorrect exception output in C

[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

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

[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

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

[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

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

[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

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

[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

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

[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

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

[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

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

[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

[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

[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

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

[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

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

[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

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

[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

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

[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

[issue39353] Deprecate the binhex module

[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

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

[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

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

[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

[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

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

[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

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

[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

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

[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

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

[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

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

[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

[issue45083] Incorrect exception output in C

[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

[issue45076] open "r+" problem

[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

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

[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

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

[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

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

[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

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

[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

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

[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

[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

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

[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

[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

[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

[issue34561] Replace list sorting merge_collapse()?

[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

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

[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

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

[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

[issue45075] confusion between frame and frame_summary in traceback module

[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

[issue45075] confusion between frame and frame_summary in traceback module

[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

[Python-announce] Wing Python IDE 8.0.3 has been released

[Wingware]

Wing 8.0.3 allows specifying the Django settings module for unit tests 
with --settings= in Run Args on the Testing page of Project 
Properties, fixes using an Activated Env that contains spaces in its 
path, prevents failure to reformat code on remote hosts and containers, 
fixes searching in files with non-ascii characters, and makes several 
other improvements.


Details:  https://wingware.com/news/2021-08-31
Downloads:   https://wingware.com/downloads

== About Wing ==

Wing is a light-weight but full-featured Python IDE designed 
specifically for Python, with powerful editing, code inspection, 
testing, and debugging capabilities. Wing's deep code analysis provides 
auto-completion, auto-editing, and refactoring that speed up 
development. Its top notch debugger works with any Python code, locally 
or on a remote host, container, or cluster. Wing also supports 
test-driven development, version control, UI color and layout 
customization, and includes extensive documentation and support.


Wing is available in three product levels:  Wing Pro is the 
full-featured Python IDE for professional developers, Wing Personal is a 
free Python IDE for students and hobbyists (omits some features), and 
Wing 101 is a very simplified free Python IDE for beginners (omits many 
features).


Learn more at https://wingware.com/

___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

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

[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

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

[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

[issue45080] functools._HashedSeq implements __hash__ but not __eq__

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

[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

Re: Trouble propagating logging configuration

[Dieter Maurer]

Loris Bennett wrote at 2021-9-1 13:48 +0200:
> ...
>Yes, but to quote from 
>https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:
>
>  A good convention to use when naming loggers is to use a module-level
>  logger, in each module which uses logging, named as follows:
>
>logger = logging.getLogger(__name__)
>
>  This means that logger names track the package/module hierarchy, and
>  it’s intuitively obvious where events are logged just from the logger
>  name.
>
>so in this case the source layout is relevant, isn't it?

Relevant in this case is the package/module hierarchy.

Often the package/module hierarchy follows the source layout
**BUT** this is not necessarily the case.

In particular, the "start" module of a script is called `__main__`
indepently of its location.
Furthermore, so called "namespace packages" consist of
decentralized (i.e. located at different places in the file system)
subpackages.

Thus, in general, the connection between pachage/module hierarchy
and the source layout is loose.


>> Furthermore, the place of the configuration (and where in the
>> code it is activated) is completely irrelevant for the "inheritance".
>
>OK, so one issue is that I was getting confused by the *order* in which
>modules are being called.  If I have two modules, 'foo' and 'bar', in
>the same directory, configure the logging just in 'foo' and then call
>
>
>  foo.some_method()
>  bar.some_method()
>
>then both methods will be logged.   If I do
>
>  bar.some_method()
>  foo.some_method()
>
>then only the method in 'foo' will be logged.

Usually, log configuration is considered a (global) application
(not a (local) package/module) concern:
The components (modules) decide what to log at what level
and global configuration decides what to do with those messages.

Thus, typically, you configure the complete logging in
your main application module and then start to import modules
and call their functions.

> ...
>If I have
>
>  [loggers]
>  keys=root,main,log_test
>
>in my logging configuration and initialise  the logging in run.py  ...

This logging configuration is obviously not complete (thus, I cannot
check what happens in your case).
You may have made errors at other places in your configuration
which may explain your observations.

At your place, I would look at the `logging` source code
to find out where you can see (in an interactive Python session)
which loggers have been created by your configuration and
how they are configured. For the last part you use "vars(logger)".



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

[issue44895] refleak test failure in test_exceptions

[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

[issue45020] Freeze all modules imported during startup.

[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

[issue45020] Freeze all modules imported during startup.

[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

ANN: Wing Python IDE 8.0.3 has been released

[Wingware]

Wing 8.0.3 allows specifying the Django settings module for unit tests 
with --settings= in Run Args on the Testing page of Project 
Properties, fixes using an Activated Env that contains spaces in its 
path, prevents failure to reformat code on remote hosts and containers, 
fixes searching in files with non-ascii characters, and makes several 
other improvements.


Details:  https://wingware.com/news/2021-08-31
Downloads:   https://wingware.com/downloads

== About Wing ==

Wing is a light-weight but full-featured Python IDE designed 
specifically for Python, with powerful editing, code inspection, 
testing, and debugging capabilities. Wing's deep code analysis provides 
auto-completion, auto-editing, and refactoring that speed up 
development. Its top notch debugger works with any Python code, locally 
or on a remote host, container, or cluster. Wing also supports 
test-driven development, version control, UI color and layout 
customization, and includes extensive documentation and support.


Wing is available in three product levels:  Wing Pro is the 
full-featured Python IDE for professional developers, Wing Personal is a 
free Python IDE for students and hobbyists (omits some features), and 
Wing 101 is a very simplified free Python IDE for beginners (omits many 
features).


Learn more at https://wingware.com/



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

[issue44895] refleak test failure in test_exceptions

[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

[issue44895] refleak test failure in test_exceptions

[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

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

[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

[issue44771] Adopt changes from importlib_resources 5.2

[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

[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

[issue45075] confusion between frame and frame_summary in traceback module

[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

[issue44895] refleak test failure in test_exceptions

[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

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

[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

[issue39326] Python-3.8.1 "test_importlib" failed

[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

[issue31962] test_importlib double free or corruption

[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

[issue44895] refleak test failure in test_exceptions

[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

[issue44895] refleak test failure in test_exceptions

[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

[issue45076] open "r+" problem

[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

[issue45075] confusion between frame and frame_summary in traceback module

[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

Re: Mutually exclusive options with argparse.

[Lee Congdon]

Does a mutually exclusive group, as described in "Mutual exclusion" at
https://docs.python.org/3/library/argparse.html meet your needs?

On Wed, Sep 1, 2021 at 9:48 AM hongy...@gmail.com 
wrote:

> See the following code snippets [1] for implementation of the exclusive
> options with argparse:
>
> def query_builder(args):
> if args.r and args.s:
> sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' +
> Term.ENDC)
> sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
> if sum_status > 1:
> sys.exit(Term.FAIL + ('Only one of --failure and --code has to be
> set') + Term.ENDC)
>
> [1]
> https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391
>
> It seems that the above method is awkward, but I'm out of idea to work out
> more graceful solutions. Any comment/suggestion/enhancement will be highly
> appreciated.
>
> Regards,
> HY
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
+1-202-507-9867, Twitter @lcongdon
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45075] confusion between frame and frame_summary in traceback module

[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

[issue44895] refleak test failure in test_exceptions

[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

Re: Request for argmax(list) and argmin(list)

[Calvin Spealman]

If only there were a library that already provides exactly the functions
you're asking for... 樂

On Wed, Sep 1, 2021 at 9:54 AM ABCCDE921 
wrote:

> Because that does 2 passes over the entire array when you only need one
> and there is no option to specify if you want the leftmost or rightmost
> element
>
>
> On Wednesday, September 1, 2021 at 12:02:29 PM UTC+5:30, Paul Bryan wrote:
> > Why not:
> >
> > >>> l = [1, 3, 5, 9, 2, 7]
> > >>> l.index(max(l))
> > 3
> > >>> l.index(min(l))
> > 0
> > On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote:
> > > I dont want to import numpy
> > >
> > > argmax(list)
> > > returns index of (left most) max element
> > >
> > > argmin(list)
> > > returns index of (left most) min element
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Peter Otten]

On 01/09/2021 13:48, Loris Bennett wrote:

"Dieter Maurer"  writes:


Loris Bennett wrote at 2021-8-31 15:25 +0200:

I am having difficulty getting the my logging configuration passed on
to imported modules.

My initial structure was as follows:

  $ tree blorp/
  blorp/
  |-- blorp
  |   |-- __init__.py
  |   |-- bar.py
  |   |-- foo.py
  |   `-- main.py
  `-- pyproject.toml

whereby the logging configuration is done in main.py.

After thinking about it, I decided maybe the inheritance wasn't working
because main.py is in the same directory as the other files.


Should you speak about Python's `logging` module, then
the "inheritance" does not depend on the source layout.
Instead, it is based on the hierarchy of dotted names.
It is completely up to you which dotted names you are using
in your `getLogger` calls.


Yes, but to quote from 
https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:

   A good convention to use when naming loggers is to use a module-level
   logger, in each module which uses logging, named as follows:

 logger = logging.getLogger(__name__)

   This means that logger names track the package/module hierarchy, and
   it’s intuitively obvious where events are logged just from the logger
   name.

so in this case the source layout is relevant, isn't it?


In most cases you will only add handlers to the root logger. If you want 
special treatment of a specific logger you need to know its name 
including its package, i. e. log_test.first, not first. If you have the 
log_test directory in your path and use


import first

instead of

import log_test.first

then not only the __name__ will be wrong/unexpected, relative imports 
will fail, too.

In other words, this is generally a bad idea.


Furthermore, the place of the configuration (and where in the
code it is activated) is completely irrelevant for the "inheritance".


OK, so one issue is that I was getting confused by the *order* in which
modules are being called.  If I have two modules, 'foo' and 'bar', in
the same directory, configure the logging just in 'foo' and then call


   foo.some_method()
   bar.some_method()

then both methods will be logged.   If I do

   bar.some_method()
   foo.some_method()

then only the method in 'foo' will be logged.

However, I still have the following problem.  With the structure

   $ tree .
   .
   |-- log_test
   |   |-- __init__.py
   |   |-- first.py
   |   `-- second.py
   |-- pyproject.toml
   |-- README.rst
   |-- run.py
   `-- tests
   |-- __init__.py
   |-- config
   `-- test_log_test.py

I have __name__ variables as follows:

   __file__: /home/loris/log_test/log_test/first.py, __name__: log_test.first
   __file__: /home/loris/log_test/log_test/second.py, __name__: log_test.second
   __file__: ./run.py, __name__: __main__

If I have

   [loggers]
   keys=root,main,log_test

in my logging configuration and initialise  the logging in run.py with

   logging.config.fileConfig("/home/loris/log_test/tests/config")
   logger = logging.getLogger()

or

   logging.config.fileConfig("/home/loris/log_test/tests/config")
   logger = logging.getLogger("log_test")

then only calls in 'run.py' are logged.

I can obviously initialise the logging within the subordinate package,
i.e. in 'log_test/__init__.py', but that seems wrong to me.

So what is the correct way to initialise logging from a top-level script
such that logging is activated in all modules requested in the logging
configuration?


For details, read the Python documentation for the `logging` module.


If they were sufficient, I wouldn't need the newsgroup :-)

Thanks for the help,


Perhaps you can start with logging.basicConfig() in run.py. If the 
imported modules contain module-level logging messages you have to put 
the import statements after the basicConfig() invocation.


You should see that simple changes like setting the logging level affect 
messages from all loggers. If that's not enough to get the granularity 
you want give your loggers fixed names


# in test_log/first.py
logger = logging.getLogger("test_log.first")

or make sure that __name__ is what you expect

# in test_log/first.py
assert __name__ == "test_log.first"

during the debugging phase.


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

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

[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

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

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

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

[Ł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()

[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()

[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

my python progress

[songbird]

  i've had some fun recently when i've had a chance to work
on it.  i needed some kind of project that would encourage
me to learn more python.  i still consider myself very new
to the language and a long ways to go (and i don't consider
the code as a great example, but it is progress to me in my
own understanding of python).

  pyglet the opengl graphics modules have been providing some
fun too.


  here is my recent update to this project:

  https://github.com/flowerbug/npath

  which took the following code and then changes it into a more
general framework and then as a practical result i was able to use
this framework to create and test the first version of the class 
(posted at the bottom).

  https://github.com/flowerbug/ngfp


  one thing i would like to have is a version of the GIMP
button border code converted from the GIMP version of lisp
to python.  i used to be fluent enough in lisp that i can
actually figure out most of what the code does but i am
not familiar enough with GIMP and graphics to fully understand
the code to be able to convert it.  if you are up for the
challenge i would appreciate it.


=
; GIMP - The GNU Image Manipulation Program
; Copyright (C) 1995 Spencer Kimball and Peter Mattis
;
; This program is free software: you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation; either version 3 of the License, or
; (at your option) any later version.
;
; This program is distributed in the hope that it will be useful,
; but WITHOUT ANY WARRANTY; without even the implied warranty of
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
; GNU General Public License for more details.
;
; You should have received a copy of the GNU General Public License
; along with this program.  If not, see .
;
; Copyright (C) 1997 Andy Thomas a...@picnic.demon.co.uk
;
; Version 0.2 10.6.97 Changed to new script-fu interface in 0.99.10

; Delta the color by the given amount. Check for boundary conditions
; If < 0 set to zero
; If > 255 set to 255
; Return the new value

(define (script-fu-addborder aimg adraw xsize ysize color dvalue)

  (define (deltacolor col delta)
(let* ((newcol (+ col delta)))
  (if (< newcol 0) (set! newcol 0))
  (if (> newcol 255) (set! newcol 255))
  newcol
)
  )

  (define (adjcolor col delta)
(mapcar (lambda (x) (deltacolor x delta)) col)
  )

  (define (gen_top_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 0 )
  (aset n_array 2 xsize)
  (aset n_array 3 ysize)
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 ysize)
  (aset n_array 6 width)
  (aset n_array 7 0 )
  (aset n_array 8 0 )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_left_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 0 )
  (aset n_array 2 xsize)
  (aset n_array 3 ysize)
  (aset n_array 4 xsize)
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 0 )
  (aset n_array 7 height )
  (aset n_array 8 0 )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_right_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 width )
  (aset n_array 1 0 )
  (aset n_array 2 (+ xsize owidth))
  (aset n_array 3 ysize)
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 width)
  (aset n_array 7 height)
  (aset n_array 8 width )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_bottom_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 height)
  (aset n_array 2 xsize)
  (aset n_array 3 (+ ysize oheight))
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 width)
  (aset n_array 7 height)
  (aset n_array 8 0 )
  (aset n_array 9 height)
  n_array)
  )

  (let* ((img (car (gimp-item-get-image adraw)))
 (owidth (car (gimp-image-get-width img)))
 (oheight (car (gimp-image-get-height img)))
 (width (+ owidth (* 2 xsize)))
 (height (+ oheight (* 2 ysize)))
 (layer (car (gimp-layer-new img
 width height
 (car (gimp-drawable-type-with-alpha adraw))
 _"Border Layer" 100 LAYER-MODE-NORMAL

(gimp-context-push)
(gimp-context-set-paint-mode LAYER-MODE-NORMAL)
(gimp-context-set-opacity 100.0)
(gimp-context-set-antialias FALSE)
(gimp-context-set-feather FALSE)

(gimp-image-undo-group-start img)

(gimp-image-resize img
   width
  

Re: Request for argmax(list) and argmin(list)

[ABCCDE921]

Because that does 2 passes over the entire array when you only need one and 
there is no option to specify if you want the leftmost or rightmost element 


On Wednesday, September 1, 2021 at 12:02:29 PM UTC+5:30, Paul Bryan wrote:
> Why not: 
> 
> >>> l = [1, 3, 5, 9, 2, 7] 
> >>> l.index(max(l)) 
> 3 
> >>> l.index(min(l)) 
> 0
> On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote: 
> > I dont want to import numpy 
> > 
> > argmax(list) 
> > returns index of (left most) max element 
> > 
> > argmin(list) 
> > returns index of (left most) min element
-- 
https://mail.python.org/mailman/listinfo/python-list

Mutually exclusive options with argparse.

[hongy...@gmail.com]

See the following code snippets [1] for implementation of the exclusive options 
with argparse:

def query_builder(args):
if args.r and args.s:
sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' + 
Term.ENDC)
sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
if sum_status > 1:
sys.exit(Term.FAIL + ('Only one of --failure and --code has to be set') 
+ Term.ENDC)

[1] 
https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391

It seems that the above method is awkward, but I'm out of idea to work out more 
graceful solutions. Any comment/suggestion/enhancement will be highly 
appreciated.

Regards,
HY
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Loris Bennett]

"Dieter Maurer"  writes:

> Loris Bennett wrote at 2021-8-31 15:25 +0200:
>>I am having difficulty getting the my logging configuration passed on
>>to imported modules.
>>
>>My initial structure was as follows:
>>
>>  $ tree blorp/
>>  blorp/
>>  |-- blorp
>>  |   |-- __init__.py
>>  |   |-- bar.py
>>  |   |-- foo.py
>>  |   `-- main.py
>>  `-- pyproject.toml
>>
>>whereby the logging configuration is done in main.py.
>>
>>After thinking about it, I decided maybe the inheritance wasn't working
>>because main.py is in the same directory as the other files.
>
> Should you speak about Python's `logging` module, then
> the "inheritance" does not depend on the source layout.
> Instead, it is based on the hierarchy of dotted names.
> It is completely up to you which dotted names you are using
> in your `getLogger` calls.

Yes, but to quote from 
https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:

  A good convention to use when naming loggers is to use a module-level
  logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

  This means that logger names track the package/module hierarchy, and
  it’s intuitively obvious where events are logged just from the logger
  name.

so in this case the source layout is relevant, isn't it?

> Furthermore, the place of the configuration (and where in the
> code it is activated) is completely irrelevant for the "inheritance".

OK, so one issue is that I was getting confused by the *order* in which
modules are being called.  If I have two modules, 'foo' and 'bar', in
the same directory, configure the logging just in 'foo' and then call


  foo.some_method()  
  bar.some_method()  

then both methods will be logged.   If I do

  bar.some_method()  
  foo.some_method()  

then only the method in 'foo' will be logged.

However, I still have the following problem.  With the structure

  $ tree .
  .
  |-- log_test
  |   |-- __init__.py
  |   |-- first.py
  |   `-- second.py
  |-- pyproject.toml
  |-- README.rst
  |-- run.py
  `-- tests
  |-- __init__.py
  |-- config
  `-- test_log_test.py

I have __name__ variables as follows:

  __file__: /home/loris/log_test/log_test/first.py, __name__: log_test.first
  __file__: /home/loris/log_test/log_test/second.py, __name__: log_test.second
  __file__: ./run.py, __name__: __main__

If I have

  [loggers]
  keys=root,main,log_test   

in my logging configuration and initialise  the logging in run.py with

  logging.config.fileConfig("/home/loris/log_test/tests/config")
  logger = logging.getLogger()

or

  logging.config.fileConfig("/home/loris/log_test/tests/config")
  logger = logging.getLogger("log_test")

then only calls in 'run.py' are logged.

I can obviously initialise the logging within the subordinate package,
i.e. in 'log_test/__init__.py', but that seems wrong to me.

So what is the correct way to initialise logging from a top-level script
such that logging is activated in all modules requested in the logging
configuration?

> For details, read the Python documentation for the `logging` module.

If they were sufficient, I wouldn't need the newsgroup :-)

Thanks for the help,

Loris
-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[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

Re: PEP Idea: Real private attribute

[Calvin Spealman]

On Tue, Aug 31, 2021 at 1:19 PM Mehrzad Saremi 
wrote:

> Calvin, even if the language offered truly private members?
>

I'm saying I don't think they're necessary, especially not for the use case
posited here. Private members in other languages are about things internal
to the class of the object itself. If we *did* have them in Python, you
couldn't use private members of an object from a decorator on it because
the decorator is external to the target class.


> On Tue, 31 Aug 2021 at 17:31, Calvin Spealman  wrote:
>
>> The right way for those decorators to hold some private information,
>> imho, isn't to put anything on the decorated object at all, but to use a
>> weak-ref dictionary using the target object as a key.
>>
>> On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi 
>> wrote:
>>
>>> Python currently uses name mangling for double-underscore attributes.
>>> Name
>>> mangling is not an ideal method to avoid name conflicting. There are
>>> various normal programming patterns that can simply cause name
>>> conflicting
>>> in double-underscore members. A typical example is when a class is
>>> re-decorated using the same decorator. The decorator can not take
>>> double-underscore members without name conflicts. For example:
>>>
>>> ```
>>> @custom_decorator("a")
>>> @custom_decorator("b")
>>> class C:
>>> pass
>>> ```
>>>
>>> The `@custom_decorator` wrapper may need to hold private members, but
>>> Python's current name conflict resolution does not provide any solution
>>> and
>>> the decorator cannot hold private members without applying tricky
>>> programming methods.
>>>
>>> Another example is when a class inherits from a base class of the same
>>> name.
>>>
>>> ```
>>> class View:
>>> """A class representing a view of an object; similar to
>>> numpy.ndarray.view"""
>>> pass
>>>
>>> class Object:
>>> class View(View):
>>> """A view class costumized for objects of type Object"""
>>> pass
>>> ```
>>>
>>> Again, in this example, class `Object.View` can't take double-underscore
>>> names without conflicting with `View`'s.
>>>
>>> My idea is to introduce real private members (by which I do not mean to
>>> be
>>> inaccessible from outside the class, but to be guaranteed not to conflict
>>> with other private members of the same object). These private members are
>>> started with triple underscores and are stored in a separate dictionary
>>> named `__privs__`. Unlike `__dict__` that takes 'str' keys, `__privs__`
>>> will be a double layer dictionary that takes 'type' keys in the first
>>> level, and 'str' keys in the second level.
>>>
>>> For example, assume that the user runs the following code:
>>> ```
>>> class C:
>>> def __init__(self, value):
>>> self.___member = value
>>>
>>> c = C("my value")
>>> ```
>>>
>>> On the last line, Python's attribute setter creates a new entry in the
>>> dictionary with key `C`, adds the value "my value" to a new entry with
>>> the
>>> key 'member'.
>>>
>>> The user can then retrieve `c.___member` by invoking the `__privs__`
>>> dictionary:
>>>
>>> ```
>>> print(c.__privs__[C]['member'])  # prints 'my value'
>>> ```
>>>
>>> Note that, unlike class names, class objects are unique and there will
>>> not
>>> be any conflicts. Python classes are hashable and can be dictionary keys.
>>> Personally, I do not see any disadvantage of using __privs__ over name
>>> mangling/double-underscores. While name mangling does not truly guarantee
>>> conflict resolution, __privs__ does.
>>>
>>> Please discuss the idea, let me know what you think about it, whether
>>> there
>>> are possible disadvantages, and if you think it will be approved as a
>>> PEP.
>>>
>>> Thanks,
>>> Mehrzad Saremi
>>>
>>> AI M.Sc. grad. from AUT
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>>
>>
>> --
>>
>> CALVIN SPEALMAN
>>
>> SENIOR QUALITY ENGINEER
>>
>> calvin.speal...@redhat.com  M: +1.336.210.5107
>> [image: https://red.ht/sig] 
>> TRIED. TESTED. TRUSTED. 
>>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[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

[issue45075] confusion between frame and frame_summary in traceback module

[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

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

[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