[issue42328] ttk style.map function incorrectly handles the default state for element options.

[miss-islington]

Change by miss-islington :


--
pull_requests: +22493
pull_request: https://github.com/python/cpython/pull/23625

___
Python tracker 

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

[issue42328] ttk style.map function incorrectly handles the default state for element options.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset f3c3ea91a76526edff928c95b9c6767e077b7448 by Serhiy Storchaka in 
branch 'master':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 
(GH-23612)
https://github.com/python/cpython/commit/f3c3ea91a76526edff928c95b9c6767e077b7448


--

___
Python tracker 

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

[issue42328] ttk style.map function incorrectly handles the default state for element options.

[miss-islington]

Change by miss-islington :


--
pull_requests: +22492
pull_request: https://github.com/python/cpython/pull/23624

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Why there are cycles at all? In normal case there should not be cycle and the 
result tuple should be destroyed when the iteration ends.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[STINNER Victor]

STINNER Victor  added the comment:

Extract of Brandt's PR:

// The GC may have untracked this result tuple if its elements were all
// untracked. Since we're recycling it, make sure it's tracked again:
if (!_PyObject_GC_IS_TRACKED(result)) {
_PyObject_GC_TRACK(result);
}

I would like to understand why the tuple is no longer tracked, whereas 
PyTuple_New() creates a newly created tuple which is tracked.

Using gdb, I found that gc_collect_main() calls untrack_tuples(young) which 
untracks all tuples of the young generation.

I understand that (when the issue happens):

* a zip() object is created with lz->result = (None, None)
* A GC collection happens
* The GC untracks (None, None) tuple
* next(zip) is called: lz->result has a reference count of 1 and so can be 
reused.

Problem: the tuple is no longer tracked, whereas its content changed and so the 
newly filled tuple might be part of a reference cycle. Since the tuple is not 
tracked, the GC can no longer break the reference cycle involving the zip 
object internal tuple.

Example of code where the zip tuple is untracked before zip_next() is called on 
the zip object:

def test_product(self):
gc.set_threshold(5)
pools = [(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12),
 ('a', 'b', 'c'),
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12),
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)]
indices = [0, 2, 10, 11]
print(indices)
print(pools)
list(None for a, b in zip(pools, indices))

--

___
Python tracker 

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

[issue42328] ttk style.map function incorrectly handles the default state for element options.

[miss-islington]

miss-islington  added the comment:


New changeset 12d2306a1db48f71b15ceaecf3d5ce06dbbe06c1 by Miss Islington (bot) 
in branch '3.8':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 
(GH-23612)
https://github.com/python/cpython/commit/12d2306a1db48f71b15ceaecf3d5ce06dbbe06c1


--

___
Python tracker 

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

[issue42328] ttk style.map function incorrectly handles the default state for element options.

[miss-islington]

miss-islington  added the comment:


New changeset ae67db6b314e297a1b67ed15c0bb560b8ce5b856 by Miss Islington (bot) 
in branch '3.9':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 
(GH-23612)
https://github.com/python/cpython/commit/ae67db6b314e297a1b67ed15c0bb560b8ce5b856


--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[STINNER Victor]

STINNER Victor  added the comment:

test_zip_leak2.py: simplified example to trigger the GC issue.

Copy it to Lib/test/ and reproduce the leak with:

./python -m test -R 3:3 test_zip_leak2

Extract of the code:
---
container = []
iterator = zip([container], [container])

# untrack the internal zip->result=(None, None)
gc.collect()

# create a reference cycle: container -> iterator -> container
container.append(iterator)

next(iterator)
# zip->result=(container, container)

del container, iterator

# Try to break the reference cycle
gc.collect()
---

--
Added file: https://bugs.python.org/file49651/test_zip_leak2.py

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[STINNER Victor]

STINNER Victor  added the comment:

Serhiy Storchaka:
> Why there are cycles at all? In normal case there should not be cycle and the 
> result tuple should be destroyed when the iteration ends.

test_itertools creates a reference cycle *on purpose*. See test_zip_leak2.py  
simplified code, it comes from test_itertools.

--

___
Python tracker 

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

[issue31990] Pickling deadlocks in thread with python -m

[Werner Smidt]

Werner Smidt  added the comment:

Thanks for going to the trouble, Sara. 


Curiosity remains, but I'll mark this as closed.

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

[issue42525] Optimize class/module level annotation

[Yurii Karabas]

Yurii Karabas <1998uri...@gmail.com> added the comment:

As all annotations are known at compilation time we can optimize annotations 
creating.

For instance, we have such code:
```
a: int
b: int
```

With the current implementation, we will have such bytecode:
```
  1   0 SETUP_ANNOTATIONS
  2 LOAD_CONST   0 ('int')
  4 LOAD_NAME0 (__annotations__)
  6 LOAD_CONST   1 ('a')
  8 STORE_SUBSCR

  2  10 LOAD_CONST   0 ('int')
 12 LOAD_NAME0 (__annotations__)
 14 LOAD_CONST   2 ('b')
 16 STORE_SUBSCR
 18 LOAD_CONST   3 (None)
 20 RETURN_VALUE
```

I would suggest using `BUILD_CONST_KEY_MAP` and bytecode will look like this:
```
 2   0 LOAD_CONST   0 ('int')
 3   2 LOAD_CONST   0 ('int')
 1   4 LOAD_CONST   1 (('a', 'b'))
 6 BUILD_CONST_KEY_MAP  2
 8 SETUP_ANNOTATIONS
 10 LOAD_CONST  2 (None)
 12 RETURN_VALUE
```

So `SETUP_ANNOTATIONS` bytecode will accept a dictionary with annotations of a 
current module/class.

I will look more like micro-optimization, I can implement this feature and run 
benchmarks to check performance boost.

I believe this optimization won't require a lot to change.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[STINNER Victor]

STINNER Victor  added the comment:

I add Pablo and Tim who love GC puzzles.

--
nosy: +pablogsal, tim.peters

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[STINNER Victor]

STINNER Victor  added the comment:

The zip bug is quite old and was already tested by test_itertools for a very 
long time. Suddenly, it started to fail on more and more Refleaks buildbots. It 
may be because the GC must be triggered at a very specific point, and the 
default GC threshold triggers the issue with latest test_itertools changes.

--

___
Python tracker 

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

[issue38630] subprocess.Popen.send_signal() should poll the process

[STINNER Victor]

STINNER Victor  added the comment:

On Linux, a pidfd file descriptor can be created with os.pidfd_open() (added to 
Python 3.9). It would avoid even more race conditions. The best would be to 
request a pidfd file descriptor directly when we spawn the process which is 
possible on recent Linux kernel versions.

> we should probably document it clearly in Popen.send_signal() and all of its 
> callers that these functions might reap the child.

Feel free to propose a PR to document the behavior.

I'm not sure of what you mean by send_signal() which "reaps" the child process.

See also bpo-40550.

Anyway, this issue and bpo-40550 are closed. I suggest to open a new issue to 
enhance the documentation.

--

___
Python tracker 

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

[issue42552] Automatically set parent thread idents on thread start

[gaborjbernat]

New submission from gaborjbernat :

I want to request automatically adding the current thread ident on the thread 
start as parent_ident. I would like this to be able to implement thread-local 
variables that inherit their values from the parent thread. See 
https://gist.github.com/gaborbernat/67b653f1d3ce4857a065a3bd81e424df#file-thread_inheritence_sol_1-py-L1
 for such an example.

--
messages: 382398
nosy: gaborjbernat
priority: normal
severity: normal
status: open
title: Automatically set parent thread idents on thread start
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

[issue42525] Optimize class/module level annotation

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

> For instance, we have such code:

But what about this, what would the bytecode will look like in this case (where 
the annotations don't exactly follow each other?)

a: int
T = TypeVar('T')
b: T
b1: Gen[T]
X = TypeVar('X')
c: X
d: str

Do you propose to build 2/3 different dicts and apply them one by one to allow 
calls to access that frame and recover the annotations?

> I will look more like micro-optimization, I can implement this feature and 
> run benchmarks to check performance boost.

What kind of optimization do you target? It would be really cool if you could 
get us some numbers with a draft patch (like comparing to test the import time 
of a module heavy with annotations, or even maybe some real-world examples. 
Here is a list of heavily-typed projects: 
https://github.com/hauntsaninja/mypy_primer/blob/2d14b20fa782896cc3d6ad2548a70c024b0f4e8a/mypy_primer.py#L900

Would love to see an import time comparison, or something similiar.

--

___
Python tracker 

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

[issue42525] Optimize class/module level annotation

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +pablogsal

___
Python tracker 

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

[issue42431] Fix outdated bytes comments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2ad93821a69e6efac3b0efe1d205d6e5ef030791 by Serhiy Storchaka in 
branch 'master':
bpo-42431: Fix outdated bytes comments (GH-23458)
https://github.com/python/cpython/commit/2ad93821a69e6efac3b0efe1d205d6e5ef030791


--

___
Python tracker 

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

[issue42431] Fix outdated bytes comments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue42537] Implement built-in shorthand b() for breakpoint()

[Qingyao Sun]

Qingyao Sun  added the comment:

See 
https://mail.python.org/archives/list/python-id...@python.org/thread/6UAJRDKVJNZ7EACXUTUCKSGAEYPJHME5/

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

[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur

[Ronald Oussoren]

Ronald Oussoren  added the comment:

FWIW I don't agree with this fix. 

sys.get_config_var('MACOSX_DEPLOYMENT_TARGET') has always resulted in a string 
value. There's bound to be someone relying on this.

As I wrote in comment on the PR a nicer fix is to teach sysconfig (and 
distutils.sysconfig) to not convert the value of this key to an integer.

--

___
Python tracker 

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

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22494
pull_request: https://github.com/python/cpython/pull/23626

___
Python tracker 

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

[issue42532] spec_arg's __bool__ is called while initializing NonCallableMock

[Idan Weiss]

New submission from Idan Weiss :

To reproduce:
import unittest.mock


class LogicInBool:
def __bool__(self):
print("In Bool!")
return True

class SomeClass:
def __init__(self):
self.logic_in_bool = LogicInBool()

obj = SomeClass()
with unittest.mock.patch.object(obj, 'logic_in_bool', autospec=True):
# "In Bool! is printed
pass

--

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[STINNER Victor]

New submission from STINNER Victor :

FAIL: test_call_later (test.test_asyncio.test_events.SelectEventLoopTests)
--
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_events.py", line 301, 
in test_call_later
self.assertTrue(0.08 <= t1-t0 <= 0.8, t1-t0)
AssertionError: False is not true : 0.077997453

https://github.com/python/cpython/pull/23626/checks?check_run_id=1492411421

--
components: Tests
messages: 382404
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_call_later() fails on Windows x64 GitHub Action
versions: Python 3.10

___
Python tracker 

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

[issue42545] Check that all symbols in the limited ABI are exported

[Igor Skochinsky]

Change by Igor Skochinsky :


--
nosy: +Igor.Skochinsky

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue42411] respect cgroups limits when trying to allocate memory

[Carlos Alexandro Becker]

Carlos Alexandro Becker  added the comment:

Any updates?

--

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22496
pull_request: https://github.com/python/cpython/pull/23628

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[miss-islington]

Change by miss-islington :


--
pull_requests: +22497
pull_request: https://github.com/python/cpython/pull/23629

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7e5e13d113798117d5ef25c5ffdbd0eb39420f98 by Victor Stinner in 
branch 'master':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/7e5e13d113798117d5ef25c5ffdbd0eb39420f98


--

___
Python tracker 

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

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8b6c4a921af6d5d0a9640211ac93d7886a55a8f3 by Victor Stinner in 
branch 'master':
bpo-42262: Py_NewRef() casts its argument to PyObject* (GH-23626)
https://github.com/python/cpython/commit/8b6c4a921af6d5d0a9640211ac93d7886a55a8f3


--

___
Python tracker 

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

[issue42554] distutils.util.get_platform() depends on minor version for macOS 11

[FX Coudert]

New submission from FX Coudert :

On macOS Big Sur (11.y.z), the return value of distutils.util.get_platform() 
records in some cases the minor version of OS. For example:

- with a Python 3.9 built on macOS 10.0.1, distutils.util.get_platform() will 
return macosx-11.0-x86_64
- with a Python 3.9 built on macOS 10.1.0, distutils.util.get_platform() will 
return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11.1 was set at build time, then 
distutils.util.get_platform() will return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11 was set at build time, then 
distutils.util.get_platform() will return macosx-11-x86_64

This has important consequences for wheel and pip, which use the return value 
to determine platform tags: https://github.com/pypa/wheel/issues/385

>From the API Reference (https://docs.python.org/3/distutils/apiref.html), it 
>is not clear what the expect return value is. Given that previously, the 
>return value of distutils.util.get_platform() was dependent only on the macOS 
>major version, I would expect this to be the case. Therefore, 
>distutils.util.get_platform() should return macosx-11-x86_64 on all Big Sur 
>(macOS 11.x.y) versions.

PS: This is not directly related to another issue with MACOSX_DEPLOYMENT_TARGET
https://bugs.python.org/issue42504

--
components: Build
messages: 382408
nosy: fxcoudert
priority: normal
severity: normal
status: open
title: distutils.util.get_platform() depends on minor version for macOS 11
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

[issue42554] distutils.util.get_platform() depends on minor version for macOS 11

[FX Coudert]

FX Coudert  added the comment:

What I think should be the logical solution to this bug:
make distutils.util.get_platform() return "macosx-11-x86_64" on all Big Sur 
(macOS 11.x.y) versions, independent of the minor OS version.

However, if the Python developers decide that this should not (for some reason) 
be the case, then this should be clearly documented. But I believe that would 
create trouble for other packages downstream.

--

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[miss-islington]

miss-islington  added the comment:


New changeset 930d5377c5877a631c3c23929e2cb6211bb0e2fb by Miss Islington (bot) 
in branch '3.8':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/930d5377c5877a631c3c23929e2cb6211bb0e2fb


--

___
Python tracker 

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

[issue38780] SysLogHandler crash atexit

[Alessio Bogon]

Change by Alessio Bogon :


--
nosy: +youtux

___
Python tracker 

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

[issue42555] math function sqrt() not working in 3.9

[mike dalrymple]

New submission from mike dalrymple :

Downloaded Python 3.9.0
Documentation indicates:
math.sqrt(x)
Return the square root of x.

When I use in IDLE shell 3.9.0, I receive error:
>>> sqrt(25)
Traceback (most recent call last):
  File "", line 1, in 
sqrt(25)
NameError: name 'sqrt' is not defined

What is the problem?

--
assignee: terry.reedy
components: IDLE
messages: 382411
nosy: mikeuser_01, terry.reedy
priority: normal
severity: normal
status: open
title: math function sqrt() not working in 3.9
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

[issue42555] math function sqrt() not working in 3.9

[Christian Heimes]

Christian Heimes  added the comment:

You have to import the math module first and then reference the sqrt function 
of the math module.

>>> import math
>>> math.sqrt(25)
5.0

--
nosy: +christian.heimes
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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[miss-islington]

miss-islington  added the comment:


New changeset 9f26833cedd33439b11059d423f599982abeb180 by Miss Islington (bot) 
in branch '3.9':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/9f26833cedd33439b11059d423f599982abeb180


--

___
Python tracker 

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

[issue42554] distutils.util.get_platform() depends on minor version for macOS 11

[Ned Deily]

Change by Ned Deily :


--
components: +Distutils, macOS
nosy: +dstufft, eric.araujo, ned.deily, ronaldoussoren

___
Python tracker 

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

[issue42553] test_asyncio: test_call_later() fails on Windows x64 GitHub Action

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue42554] distutils.util.get_platform() depends on minor version for macOS 11

[FX Coudert]

FX Coudert  added the comment:

Actually, I can find some distribution of Python where the minor version is 
returned, for example on Apple macOS 10.15.4:

/usr/bin/python3 -c 'import distutils.util; 
print(distutils.util.get_platform())' 
macosx-10.14.6-x86_64

Therefore maybe I misunderstand and there is no guarantee on the form of this 
return value

--

___
Python tracker 

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

[issue42556] unittest.mock.patch() cannot properly mock methods

[Pierre Ossman]

New submission from Pierre Ossman :

unittest.mock.patch() as it currently works cannot properly mock a method as it 
currently replaces it with something more mimicking a function. I.e. the 
descriptor magic that includes "self" isn't properly set up.

In most cases this doesn't really matter, but there are a few use cases where 
this is important:

1. Calling base classes where you need to make sure it works regardless of 
super() or direct reference to the base class.

2. Multiple objects calling the same base class using super(). Without the self 
argument you can't tell the calls apart.

3. Setting up a side_effect that needs access to the object. In some cases you 
can pass the object using some side channel, but not all. E.g. not when mocking 
a base class' __init__(). (already reported as Issue35577).

Right now you can work around this by using autospec, as that has the 
undocumented side-effect of properly setting up methods. So don't fix 
Issue41915 before this one or we lose that workaround. :)

--
components: Library (Lib)
messages: 382415
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: unittest.mock.patch() cannot properly mock methods
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue42116] Inspect library ignore comments at the end of a function (inspect.getsource)

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
nosy: +iritkatriel
nosy_count: 2.0 -> 3.0
pull_requests: +22498
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23630

___
Python tracker 

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

[issue36094] When using an SMTP SSL connection,, get ValueError.

[Roundup Robot]

Change by Roundup Robot :


--
nosy: +python-dev
nosy_count: 8.0 -> 9.0
pull_requests: +22499
pull_request: https://github.com/python/cpython/pull/23490

___
Python tracker 

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

[issue42116] Inspect library ignore comments at the end of a function (inspect.getsource)

[Irit Katriel]

Irit Katriel  added the comment:

1. For a comment line, the tokenizer emits a COMMENT token followed by an NL 
token for the newline. The inspect.BlockFinder.tokeneater increments its "last" 
field to the last line it identified as belonging to the code block. Currently 
it increments it when it sees a NEWLINE token, but not for an NL token.

2. For a comment line, the tokenizer does not emit an INDENT/DEDENT token, so 
the indentation level when it is processes is assumed to be equal to that of 
the previous line.

PR 23630 aims to include comment lines in the block if their start column is 
after the start column of the opening line of the block:

   def f():
  return 42

 # this is a part of f
   # this is not a part of f

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

[issue42116] Inspect library ignore comments at the end of a function (inspect.getsource)

[Irit Katriel]

Irit Katriel  added the comment:

For reference - this script:
-
import inspect
import tokenize
from pprint import pprint as pp

src=[
 'def f():\n',
 'return 1\n',
 '#that was fun',
 '\n',
 '#Now comes g\n',
 'def g():\n',
 'return 2\n']

pp(list(tokenize.generate_tokens(iter(src).__next__)))
-

Outputs:
-
[TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3), line='def 
f():\n'),
 TokenInfo(type=1 (NAME), string='f', start=(1, 4), end=(1, 5), line='def 
f():\n'),
 TokenInfo(type=54 (OP), string='(', start=(1, 5), end=(1, 6), line='def 
f():\n'),
 TokenInfo(type=54 (OP), string=')', start=(1, 6), end=(1, 7), line='def 
f():\n'),
 TokenInfo(type=54 (OP), string=':', start=(1, 7), end=(1, 8), line='def 
f():\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(1, 8), end=(1, 9), line='def 
f():\n'),
 TokenInfo(type=5 (INDENT), string='', start=(2, 0), end=(2, 4), line='
return 1\n'),
 TokenInfo(type=1 (NAME), string='return', start=(2, 4), end=(2, 10), line='
return 1\n'),
 TokenInfo(type=2 (NUMBER), string='1', start=(2, 11), end=(2, 12), line='
return 1\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(2, 12), end=(2, 13), line='
return 1\n'),
 TokenInfo(type=60 (COMMENT), string='#that was fun', start=(3, 4), end=(3, 
17), line='#that was fun'),
 TokenInfo(type=61 (NL), string='', start=(3, 17), end=(3, 17), line='#that 
was fun'),
 TokenInfo(type=61 (NL), string='\n', start=(4, 0), end=(4, 1), line='\n'),
 TokenInfo(type=60 (COMMENT), string='#Now comes g', start=(5, 0), end=(5, 12), 
line='#Now comes g\n'),
 TokenInfo(type=61 (NL), string='\n', start=(5, 12), end=(5, 13), line='#Now 
comes g\n'),
 TokenInfo(type=6 (DEDENT), string='', start=(6, 0), end=(6, 0), line='def 
g():\n'),
 TokenInfo(type=1 (NAME), string='def', start=(6, 0), end=(6, 3), line='def 
g():\n'),
 TokenInfo(type=1 (NAME), string='g', start=(6, 4), end=(6, 5), line='def 
g():\n'),
 TokenInfo(type=54 (OP), string='(', start=(6, 5), end=(6, 6), line='def 
g():\n'),
 TokenInfo(type=54 (OP), string=')', start=(6, 6), end=(6, 7), line='def 
g():\n'),
 TokenInfo(type=54 (OP), string=':', start=(6, 7), end=(6, 8), line='def 
g():\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(6, 8), end=(6, 9), line='def 
g():\n'),
 TokenInfo(type=5 (INDENT), string='', start=(7, 0), end=(7, 4), line='
return 2\n'),
 TokenInfo(type=1 (NAME), string='return', start=(7, 4), end=(7, 10), line='
return 2\n'),
 TokenInfo(type=2 (NUMBER), string='2', start=(7, 11), end=(7, 12), line='
return 2\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(7, 12), end=(7, 13), line='
return 2\n'),
 TokenInfo(type=6 (DEDENT), string='', start=(8, 0), end=(8, 0), line=''),
 TokenInfo(type=0 (ENDMARKER), string='', start=(8, 0), end=(8, 0), line='')]

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

> I add Pablo and Tim who love GC puzzles.

Well, I don’t think the GC is really doing anything wrong here... untracking 
these sort of tuples likely results in a noticeable reduction in collection 
times. This code is definitely testing the limits of what is “okay” for us to 
do with a tuple, and it’s breaking the GC’s (reasonable) assumptions.

I kept digging around, and it appears dict.items() is affected, too (which is a 
bit scarier). The same fix still works, though.

--

___
Python tracker 

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

[issue42557] Make asyncio.__main__ reusable, also adding a preamble feature.

[Berry Schoenmakers]

New submission from Berry Schoenmakers :

The async REPL introduced in Python 3.8 is very nice for quick tests and 
experiments, supporting top-level "await" (see 
https://bugs.python.org/issue37028). I'm using it often when developing code 
that heavily relies on Python's asyncio module.

A drawback of the basic interface when launching it with "python -m asyncio" is 
that one usually still needs to enter a couple of statements to load the 
package you're working on, etc. To overcome this I've added a __main__.py to 
the mpyc package such that entering "python -m mpyc" will launch the async REPL 
like this: 

asyncio REPL 3.10.0a2 (tags/v3.10.0a2:114ee5d, Nov  3 2020, 00:37:42) 
[MSC v.1927 64 bit (AMD64)] on win32
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> from mpyc.runtime import mpc
>>> secint = mpc.SecInt()
>>> secfxp = mpc.SecFxp()
>>> secfld256 = mpc.SecFld(256)
>>>

This enables the async REPL but also a "preamble" with some additional code is 
executed.

To program mpyc.__main__.py, however, I basically had to copy 
asyncio.__main__.py and make a few changes throughout the code. It works 
alright, but to take advantage of future improvements to asyncio.__main__.py it 
would be very convenient if asyncio.__main__.py becomes reusable. 

With the added feature for specifying a "preamble", programming something like 
mpyc.__main__.py requires just a few lines of code:

import asyncio.__main__

if __name__ == '__main__':
preamble = ('from mpyc.runtime import mpc',
'secint = mpc.SecInt()',
'secfxp = mpc.SecFxp()',
'secfld256 = mpc.SecFld(256)')
 asyncio.__main__.main(preamble)

The attachment contains the current version of mpyc.__main__.py, which to a 
large extent duplicates code from asyncio.__main__.py. A couple of, I think, 
minor changes are applied to make the code reusable, and to add the preamble 
feature.

Would be nice if asyncio.__main__.py is updated in this manner in Python 3.10 
such that package developers can tailor it to their needs?

--
components: asyncio
files: __main__.py
messages: 382419
nosy: asvetlov, lschoe, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Make asyncio.__main__ reusable, also adding a preamble feature.
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49652/__main__.py

___
Python tracker 

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

[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur

[FX Coudert]

FX Coudert  added the comment:

"It has always resulted in a string value": only MACOSX_DEPLOYMENT_TARGET 
always took the form of a non-integer. The code for sysconfig.get_config_var() 
has a pretty clear intent: it will try to cast its return value to an int.

I don't have a strong opinion whether this is fixed this way or another. I 
would think, however, that there are surely places in existing code that expect 
and rely on sysconfig.get_config_var() returning an int for integer-type values.

--

___
Python tracker 

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

[issue42541] Tkinter colours wrong on MacOS universal2

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is a duplicate of #38261.  I'm closing that other issue because this issue 
has more discussion.

--

___
Python tracker 

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

[issue38261] Tkinter CheckButton default label white in macOS dark mode

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is a duplicate of #42541.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tkinter colours wrong on MacOS universal2

___
Python tracker 

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

[issue42531] importlib.resources.path() raises TypeError for packages without __file__

[William Schwartz]

William Schwartz  added the comment:

> If the issue has been fixed on Python 3.9 but not on 3.8, then it was likely 
> a redesign that enabled the improved behavior

That appears to be the case: path() shares code with files().

> a redesign that won't be ported back to Python 3.8 and earlier.

Nor should it.

> In these situations, the best recommendation is often to just rely on 
> importlib_resources (the backport) for those older Python versions.

I do not need the files() API or anything else added in 3.9 at this time. I 
just need the existing 3.7/3.8 functionality to work as documented.

> have you considered using importlib_resources for Python 3.8 and earlier? 
> That would likely also address the issue and you could adopt it sooner.

My application is sensitive to the size of the installed site-packages both in 
bytes and in just the number of packages. Yes, importlib_resources would very 
likely solve the problem reported in the OP. However I don't need the files() 
API, so adding an extra requirement feels like a heavy solution.

> To some extent, the behavior you've described could be considered a bug or 
> could be considered a feature request (add support for path on packages that 
> have no __spec__.origin). I am not aware whether this limitation was by 
> design or incidental.

I agree there should be a high bar for patching old versions, but I posit that 
the behavior is an unintentional bug. In particular, I believe the behavior 
contradicts the documentation. Below I link and quote relevant documentation.

The function in question:

> importlib.resources.path(package, resource)¶
> ...package is either a name or a module object which conforms to the
> Package requirements.
https://docs.python.org/3.8/library/importlib.html#importlib.resources.path

So we jump to Package:

> importlib.resources.Package
> The Package type is defined as Union[str, ModuleType]. This means that
> where the function describes accepting a Package, you can pass in either a
> string or a module. Module objects must have a resolvable
> __spec__.submodule_search_locations that is not None.
https://docs.python.org/3.8/library/importlib.html#importlib.resources.Package


The Package type restricts the types of modules based on 
__spec__.submodule_search_locations. This suggests to me that the original 
author thought about which __spec__s to accept and which to reject but chose 
not to say anything about __spec__.origin, which is documented as possibly 
being None:

> class importlib.machinery.ModuleSpec(...)
> ...module.__spec__.origin == module.__file__ Normally “origin” should
> be set, but it may be None (the default) which indicates it is unspecified
> (e.g. for namespace packages).
https://docs.python.org/3.8/library/importlib.html#importlib.machinery.ModuleSpec.origin

In particular, __spec__.origin *should* be None in certain situations:

> __file__
> __file__ is optional The import system may opt to leave __file__ unset
> if it has no semantic meaning (e.g. a module loaded from a database).
https://docs.python.org/3.8/reference/import.html#__file__

Taken together, the foregoing passages describe an `import` API in which path() 
works for all modules that are packages (i.e., 
__spec__.submodule_search_locations is not None), and in which some packages' 
__spec__.origin is None. That path() fails in practice to support some packages 
is therefore a bug not a the absence of a feature.

Regardless of whether PR 23611 is accepted, the test that it adds should be 
added to Python master to guard against regressions. I can submit that as a 
separate PR. Before I do that, do I need to create a new bpo ticket, or can I 
just reference this one?

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

functools.reduce looks affected, too.

--

___
Python tracker 

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

[issue42555] math function sqrt() not working in 3.9

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Mike, please ask questions on question forums such as python-list 
(mail.python.org) or stackoverflow.com, where other beginners can see the 
answer.  Also, IDLE is not Python.  In particular, python's response to code 
you send to python usually has nothing to do with IDLE.

--
assignee: terry.reedy -> 

___
Python tracker 

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

[issue42541] Tkinter colours wrong on MacOS universal2

[E. Paine]

E. Paine  added the comment:

> we should at least opt out of dark mode for IDLE
That still leaves tkinter almost unusable when dark mode is turned on. I am 
looking into solutions but am not hopeful (maybe we should ask Marc?).

@Ned, what are the alternatives if we decide 8.6.10 is not the way to go (do we 
go back to 8.6.8/9 or forward and use an arbitrary checkpoint assuming 8.6.11 
is not happening soon)? Also, are we intending to provide a universal2 
installer for 3.9.1 (i.e. we need to sort this asap)?

--

___
Python tracker 

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions

[Jack O'Connor]

Jack O'Connor  added the comment:

I'm late to the party, but I want to explain what's going on here in case it's 
helpful to folks. The issue you're seeing here has to do with whether a child 
processs has been "reaped". (Windows is different from Unix here, because the 
parent keeps an open handle to the child, so this is mostly a Unix thing.) In 
short, when a child exits, it leaves a "zombie" process whose only job is to 
hold some metadata and keep the child's PID reserved.  When the parent calls 
wait/waitpid/waitid or similar, that zombie process is cleaned up. That means 
that waiting has important correctness properties apart from just blocking the 
parent -- signaling after wait returns is unsafe, and forgetting to wait also 
leaks kernel resources.

Here's a short example demonstrating this:

```
  import signal 

   
  import subprocess 

   
  import time   

   


   
  # Start a child process and sleep a little bit so that we know it's exited.   

   
  child = subprocess.Popen(["true"])

   
  time.sleep(1) 

   


   
  # Signal it. Even though it's definitely exited, this is not an error.

  
  os.kill(child.pid, signal.SIGKILL)

   
  print("signaling before waiting works fine")  

   


   
  # Now wait on it. We could also use os.waitpid or os.waitid here. This reaps  

   
  # the zombie child.   

   
  child.wait()  

   


   
  # Try to signal it again. This raises ProcessLookupError, because the child's 

   
  # PID has been freed. But note that Popen.kill() would be a no-op here,
  # because it knows the child has already been waited on.  

  
  os.kill(child.pid, signal.SIGKILL)

   
```

With that in mind, the original behavior with communicate() that started this 
bug is expected. The docs say that communicate() "waits for process to 
terminate and sets the returncode attribute." That means internally it calls 
waitpid, so your terminate() thread is racing against process exit. Catching 
the exception thrown by terminate() will hide the problem, but the u

[issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk 8.6.10

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The test may be correctly detecting a change in widget behavior.  This is less 
surprising to me than some keypresses acting like two keypresses a millesecond 
apart.

--

___
Python tracker 

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

[issue42558] waitpid/waitid race caused by change to Popen.send_signal in Python 3.9

[Jack O'Connor]

New submission from Jack O'Connor :

In Python 3.9, Popen.send_signal() was changed to call Popen.poll() internally 
before signaling. (Tracking bug: https://bugs.python.org/issue38630.) This is a 
best-effort check for the famous kill/wait race condition. However, because 
this can now reap an already-exited child process as a side effect, it can 
cause previously working programs to crash. Here's a simple example:

```
import os
import subprocess
import time

child = subprocess.Popen(["true"])
time.sleep(1)
child.kill()
os.waitpid(child.pid, 0)
```

The program above exits cleanly in Python 3.8 but crashes with 
ChildProcessError in Python 3.9. It's a race against child process exit, so in 
practice (without the sleep) it's a heisenbug.

There's a deeper race here that's harder to demonstrate in an example, but 
parallel to the original wait/kill issue: If the child PID happens to be reused 
by another parent thread in this same process, the call to waitpid might 
*succeed* and reap the unrelated child process. That would export the crash to 
that thread, and possibly create more kill/wait races.

In short, the question of when exactly a child process is reaped is important 
for correct signaling on Unix, and changing that behavior can break programs in 
confusing ways. This change affected the Duct library, and I might not've 
caught it if not for a lucky failing doctest: 
https://github.com/oconnor663/duct.py/commit/5dfae70cc9481051c5e53da0c48d9efa8ff71507

I haven't searched for more instances of this bug in the wild, but one way to 
find them would be to look for code that calls both os.waitpid/waitid and also 
Popen.send_signal/kill/terminate. Duct found itself in this position because it 
was using waitid(WNOWAIT) on Unix only, to solve this same race condition, and 
also using Popen.kill on both Unix and Windows.

--
messages: 382429
nosy: oconnor663
priority: normal
severity: normal
status: open
title: waitpid/waitid race caused by change to Popen.send_signal in Python 3.9
type: crash
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

[issue38630] subprocess.Popen.send_signal() should poll the process

[Jack O'Connor]

Jack O'Connor  added the comment:

Filed separately as https://bugs.python.org/issue42558.

--

___
Python tracker 

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

[issue42523] using windows doc incorrectly states version support

[Steve Dower]

Steve Dower  added the comment:


New changeset db68544122f5a0c7b80f69c0e643049efa6699c6 by Zackery Spytz in 
branch 'master':
bpo-42523: Fix supported versions in "Using Python on Windows" (GH-23603)
https://github.com/python/cpython/commit/db68544122f5a0c7b80f69c0e643049efa6699c6


--

___
Python tracker 

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

[issue42523] using windows doc incorrectly states version support

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22500
pull_request: https://github.com/python/cpython/pull/23631

___
Python tracker 

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

[issue42523] using windows doc incorrectly states version support

[Steve Dower]

Change by Steve Dower :


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

___
Python tracker 

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

[issue42523] using windows doc incorrectly states version support

[miss-islington]

miss-islington  added the comment:


New changeset 3689c25a1010c2acdb05f1b1b0229f4766b4440a by Miss Islington (bot) 
in branch '3.9':
bpo-42523: Fix supported versions in "Using Python on Windows" (GH-23603)
https://github.com/python/cpython/commit/3689c25a1010c2acdb05f1b1b0229f4766b4440a


--

___
Python tracker 

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

[issue42541] Tkinter colours wrong on MacOS universal2

[Ronald Oussoren]

Ronald Oussoren  added the comment:

It is possible to opt out of dark mode using a key in the Info.plist file. This 
can also be used in the Python.app hidden in the framework to globally disable 
support for dark mode.

I wouldn't switch back to 8.6.9, if only because that doesn't build properly on 
macOS 11 (and hence would make building the "univeral2" installer a lot 
harder). 

I'd rather use the tip of the 8.6.x branch for Tk to get the latest bug fixes 
(probably picking a specific commit to be able to reproduce the build).

--

___
Python tracker 

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

[issue42559] random.getrandbits: Should it be explicit that it returns unsigned/non-negative integer?

[Paul Sokolovsky]

New submission from Paul Sokolovsky :

Current docs for random.getrandbits() ( 
https://docs.python.org/3/library/random.html#random.getrandbits ) read 
(3.9.1rc1 at the top of the page):

Returns a Python integer with k random bits. This method is supplied with the 
MersenneTwister generator and some other generators may also provide it as an 
optional part of the API. When available, getrandbits() enables randrange() to 
handle arbitrarily large ranges.

So, based that it talks about "bits", it's easy to imagine that the result is 
unsigned. But it's interesting that it mentions "a Python integer", not even 
just "integer". And Python integers are known to be signed.

So I'd say, there's enough of ambiguity in there, and would be nice to 
explicitly specify that it's "unsigned (non-negative) Python integer".


If there's interest for the background of concern, some implementations may 
have "small" and "large" integers underlyingly (which used to be exposed at the 
user-level in Python2). "Small" integers would be cheaper, but of course, they 
would be signed. So, at certain value of getrandbits() parameter, there may be 
a temptation to use up a sign bit of a small integer, instead of going straight 
to allocating expensive large integer. It should be clear this is NOT a valid 
"optimization", and result should be always non-negative.

--
messages: 382434
nosy: pfalcon
priority: normal
severity: normal
status: open
title: random.getrandbits: Should it be explicit that it returns 
unsigned/non-negative integer?
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

[issue41915] unittest.mock.create_autospec(Obj, instance=True) has self keyword in _spec_signature if Obj implements __call__

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2 installer fails smoke test

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The new commit to PR 23577 works around the double run_module_event call.  
Removing the delay changed timings, so I instead measured the time between 
closing the errorbox and the 2nd call.  The allowed difference had to be 
increased to .015, so I selected .05 to be safer.

--

___
Python tracker 

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

[issue42543] case sensitivity in open() arguments

[Eric V. Smith]

Eric V. Smith  added the comment:

Although I'm not sure the existing message needs changing, if a change is going 
to be made I think listing the valid option characters might be more useful.

--
nosy: +eric.smith

___
Python tracker 

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

[issue42560] Improve Tkinter Documentation

[Mason Ginter]

New submission from Mason Ginter :

Online python Tkinter documentation 
(https://docs.python.org/3/library/tkinter.html) lacks many features. The main 
part I find lacking is documentation on methods, as many of them either aren't 
listed in the documentation and/or take *args as the only parameter, rather 
than defined parameters. 

Not sure how in-depth docs from effbot were, but those are not currently 
available.

Existing documentation in the source code 
(https://github.com/python/cpython/blob/3.9/Lib/tkinter/__init__.py) seems to 
be a good start to adding to the online documentation.

--
assignee: docs@python
components: Documentation
messages: 382437
nosy: docs@python, mason2
priority: normal
severity: normal
status: open
title: Improve Tkinter Documentation
type: enhancement

___
Python tracker 

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

[issue26582] asyncio documentation links to wrong CancelledError

[Irit Katriel]

Irit Katriel  added the comment:

I think this has been fixed in the docs by now. See for instance:

https://docs.python.org/3/library/asyncio-task.html#asyncio.gather
https://docs.python.org/3/library/asyncio-future.html#asyncio.Future.result

--
nosy: +iritkatriel

___
Python tracker 

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

[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The value *for this key* is a dot separated sequence of integer labels in a 
string. The limit of that is a single integer label that could be converted to 
a Python int. 

With the current patch get_config_var('MACOSX_DEPLOYMENT_TARGET') mostly 
returns a string, but sometimes an integer.  And the last part is new 
behaviour, which means existing consumers of this won't be prepared to handle a 
non-string value (other than None).

I'll probably create an alternative PR this weekend.


sysconfig converts config values that look like integers to python ints because 
that's often useful, but in this case it isn't. This part of the code base is 
old and has not very well defined semantics.

--

___
Python tracker 

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

[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur

[Ned Deily]

Ned Deily  added the comment:

I agree with Ronald that it would be safest if the sysconfigs (all of them) 
always returned deployment target as a string and I would be fine with a PR 
that did that. That doesn't mean that the already applied PR needs to be 
changed, though, right? Just extra insurance.

--

___
Python tracker 

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

[issue42116] Inspect library ignore comments at the end of a function (inspect.getsource)

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk 8.6.10

[Ned Deily]

Ned Deily  added the comment:

OK, thanks for the clarification, Terry. Considering that our tkinter tests 
make assumptions about the underlying Tk widgets behavior, assumptions not 
necessarily shared by the Tk developers :), these kind of version-dependent 
failures are a risk of and shortcoming of having extensive tests like these. 
I'm not overly concerned about the failures other than it is not good to have 
failing tests.

Serihy: "Can I get a remote access to machine with macOS?" Sorry, that's 
difficult for me to provide right now; perhaps later.  Anyone else?

--

___
Python tracker 

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

[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'd prefer to (effectively) revert the PR and treat MACOSX_DEPLOYMENT_TARGET=11 
the same as MACOSX_DEPLOYMENT_TARGET=11.0.

The same issue has crept up on the wheel and packaging repos (in the context of 
changing the platform tag in wheel names).  As I wrote there: the ship has 
sailed w.r.t. those tags, there are already "macosx_11_0_univeral2" wheels on 
PyPI.

--

___
Python tracker 

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

[issue42541] Tkinter colours wrong on MacOS universal2

[Ned Deily]

Ned Deily  added the comment:

I agree that moving forward (using an unreleased 8.6.10+ snapshot) is better 
than moving backwards (back to 8.6.9).  Perhaps Marc or Kevin can suggest Tcl 
and Tk dev heads to use.

--
nosy: +culler

___
Python tracker 

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

[issue17735] inspect.findsource raises IndexError

[Irit Katriel]

Irit Katriel  added the comment:

I'm unable to reproduce it now. Has it been fixed?

>>> import x
>>> help(x)
Help on module x:

NAME
x

FUNCTIONS
func()

FILE
c:\users\user\src\cpython\x.py


>>> from importlib import reload
>>> reload(x)

>>> help(x)
Help on module x:

NAME
x

FUNCTIONS
func()

newfunc()

FILE
c:\users\user\src\cpython\x.py

--
nosy: +iritkatriel

___
Python tracker 

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

[issue17735] inspect.findsource raises IndexError

[Irit Katriel]

Irit Katriel  added the comment:

Sorry, you're right - now the issue is when you remove functions from the 
module:

>>> reload(x)

>>> help(x)
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\User\src\cpython\\lib\_sitebuiltins.py", line 103, in __call__
return pydoc.help(*args, **kwds)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 2000, in __call__
self.help(request)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 2059, in help
else: doc(request, 'Help on %s:', output=self._output)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1779, in doc
pager(render_doc(thing, title, forceload))
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1772, in render_doc
return title % desc + '\n\n' + renderer.document(object, name)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 472, in document
if inspect.ismodule(object): return self.docmodule(*args)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1273, in docmodule
contents.append(self.document(value, key, name))
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 474, in document
if inspect.isroutine(object): return self.docroutine(*args)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1510, in docroutine
doc = getdoc(object) or ''
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 187, in getdoc
result = _getdoc(object) or inspect.getcomments(object)
  File "C:\Users\User\src\cpython\lib\inspect.py", line 882, in getcomments
lines, lnum = findsource(object)
  File "C:\Users\User\src\cpython\lib\inspect.py", line 871, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3

___
Python tracker 

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

[issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk 8.6.10

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

All these failures point not on some details of appearance, but that the widget 
is not rendered at all.

--

___
Python tracker 

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

[issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk 8.6.10

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I might be able to debug during the weekend, but my main focus will be on back 
porting the changes in #41100 to the 3.8 branch (or at least parts of it).

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I added some comments in the PR regarding the possibility of forcing the 
tracking on the visiting function to redirect the cost to gc passes instead of 
when calling next() but there is another option: not untracking tuples that 
have refcount == 1.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> not untracking tuples that have refcount == 1.

Actually, this may not be a good idea as well: running test_list shows that 
there are 14786 tuples with refcount == 1 that would have been untracked. This 
is a non-trivial workload to the gc passes that we will lose if we do this.

Performance-wise, I think the best alternative is to force the tracking before 
visiting in tp_traverse.

--

___
Python tracker 

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

[issue42561] better error reporting in ast

[sds]

New submission from sds :

ast parsing error locations are hard to pinpoint.
See https://stackoverflow.com/q/46933995/850781.

--
components: Library (Lib)
files: ast.diff
keywords: patch
messages: 382449
nosy: sam-s
priority: normal
severity: normal
status: open
title: better error reporting in ast
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49653/ast.diff

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

> I added some comments in the PR regarding the possibility of forcing the 
> tracking on the visiting function to redirect the cost to gc passes instead 
> of when calling next()...

Yep, I agree that this approach is better.

> ...but there is another option: not untracking tuples that have refcount == 1.

I do like the idea of not having to fix this in ~10 different places, but I'm 
not sure this is enough. The GC visit may happen when the refcount of the 
result tuple is > 1, but it may drop back to 1 before __next__ called again

z = zip([42, []])
item = next(zip)
gc.collect()  # Refcount of item == 2, untracked by GC.
del item  # Refcount of item == 1, ready to be recycled.
next(zip)  # This should be tracked, but won't be.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> The GC visit may happen when the refcount of the result tuple is > 1, but it 
> may drop back to 1 before __next__ called again

Good point. Also, is it possible that a more complex cycle ends having more 
than one reference to that result, so indeed that is not enough.

--

___
Python tracker 

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

[issue42562] dis failed to parse function that has only annotations

[Yurii Karabas]

New submission from Yurii Karabas <1998uri...@gmail.com>:

`dis` module failed when trying to parse function that has only annotations at 
the function body:
```
def foo():
a: int
```

Failed with stacktrace:
```
  1   0 LOAD_CONST   0 ()
  2 LOAD_CONST   1 ('foo')
  4 MAKE_FUNCTION0
  6 STORE_NAME   0 (foo)
  8 LOAD_CONST   2 (None)
 10 RETURN_VALUE

Disassembly of :
Traceback (most recent call last):
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/runpy.py", line 197, 
in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/runpy.py", line 87, in 
_run_code
exec(code, run_globals)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 536, in 

_test()
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 533, in 
_test
dis(code)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 79, in 
dis
_disassemble_recursive(x, file=file, depth=depth)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 381, in 
_disassemble_recursive
_disassemble_recursive(x, file=file, depth=depth)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 373, in 
_disassemble_recursive
disassemble(co, file=file)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 369, in 
disassemble
_disassemble_bytes(co.co_code, lasti, co.co_varnames, co.co_names,
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 389, in 
_disassemble_bytes
maxlineno = max(linestarts.values()) + line_offset
ValueError: max() arg is an empty sequence
```

--
components: Library (Lib)
messages: 382453
nosy: uriyyo
priority: normal
severity: normal
status: open
title: dis failed to parse function that has only annotations
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue42562] dis failed to parse function that has only annotations

[Yurii Karabas]

Change by Yurii Karabas <1998uri...@gmail.com>:


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

___
Python tracker 

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

[issue42562] dis failed to parse function that has only annotations

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue42541] Tkinter colours wrong on MacOS universal2

[Marc Culler]

Marc Culler  added the comment:

Yes, I can provide a good commit ID to work with.  Please give me a couple of 
days.  The current tip is almost an ideal choice.  There have been no Aqua bug 
reports for quite some time.  But now there is one new one (from Kevin) so I'd 
like to fix that, discuss with Kevin, and test.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

> I added some comments in the PR regarding the possibility of forcing the 
> tracking on the visiting function

Thinking about this more, I'm a bit hesitant to put the re-tracking code in the 
traverse function (mostly stemming from my lack of knowledge about our GC 
algorithm). I have no idea how problematic tracking and untracking objects 
*during* collections can be. Consider the following reference chain:

-> z -> r -> o -> r

Here, z is a zip iterator, r is its result tuple, and o is some object. Let's 
say r was untracked in the previous collection (I believe untrack_tuples 
happens *after* all of the traverse functions are called).

I'm worried that the GC may not be able to detect the cycle if it visits o, 
then z (which *then* starts tracking r), then r.

Or, if this group is determined to be unreachable, untrack_tuples untracks r 
*before* the cycle is cleaned up. That seems like it could be a problem.

Or, if z's refcount drops to zero and it's cleaned up, its traverse function 
may *never* be called, which leaves the untracked r -> o -> r cycle.

I guess I'm just not sure how resilient the GC is to these sorts of things. 
Re-tracking the result tuple in __next__ sidesteps all of these potential 
issues, with no significant performance impact. So I think I might slightly 
prefer that.

--

___
Python tracker 

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

[issue17735] inspect.findsource raises IndexError

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

[Jan Tojnar]

Jan Tojnar  added the comment:

One benefit of using a compile time feature over a runtime method is that the 
former allows for more predictable dedenting by first dedenting and only then 
interpolating variables.

For example, the following code does not dedent the test string at all:

```python
import textwrap

foo = "\n".join(["aaa", "bbb"])

test = textwrap.dedent(
f"""
block xxx:
{foo}
"""
)
```

It would be much nicer if we had syntactical dedents based on the leftmost 
non-whitespace column in the string, as supported by Nix language, for example.

```python
test = (
df"""
block xxx:
{textwrap.indent(foo, ' '*4)}
"""
)
```

It would be even nicer if the interpolated strings could be indented based on 
the column the interpolation occurs in but that can at least be done at runtime 
with only minor inconvenience.

--
nosy: +jtojnar

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Or, if z's refcount drops to zero and it's cleaned up, its traverse function 
> may *never* be called, which leaves the untracked r -> o -> r cycle.

This is a real problem, indeed. We would need to add the tracking to the 
tp_dealloc of the zip object as well.

> I have no idea how problematic tracking and untracking objects *during* 
> collections can be.

It is indeed tricky: the most problematic part of the "surprise tracking" is 
the validity of the pointers, but the key here is that the traverse function 
will be called BEFORE (update_refs()) the pointers start being invalid (because 
of the bit reuse).

> Or, if this group is determined to be unreachable, untrack_tuples untracks r 
> *before* the cycle is cleaned up. That seems like it could be a problem.

It is not: untrack_tuples is called over the reachable set after the gc knows 
what part of the linked list is isolated garbage. If the group is in the 
unreachable set, then untrack_tuples won't touch it. 

> I'm worried that the GC may not be able to detect the cycle if it visits o, 
> then z (which *then* starts tracking r), then r.

This is not a problem IMO: if the gc does not see the cycle in that collection, 
it will in the next ones. Wat will happen is that at the beginning the gc does 
not see r so it iterates over the linked list of the generation being 
collected, decrementing the gc refcounts. When it reaches z, it starts 
decrementing the refcounts of z and that calls the traverse function of z, that 
tracks r AND decrements its gc refcounts but also it adds "r" to the end of the 
linked list of the young generation. This means that (assuming we are 
collecting the middle generation) in this collection the cycle will not be 
seen, but in a future collection where the young generation is collected then 
"r" will be visited normally (notice that the gc can see "r" without needing to 
visit "z" before). Also, notice that untrack_tuples() is called over the 
reachable set, but "r" is in the young generation so it won't be untracked. 
Also, if we are collecting the younger generation, then the cycle will be found 
and it
  will be cleaned nicely.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I forgot to mention the conclusion: my conclusion is that although the GC is 
resilient to these shenanigans (it was also extensive validation along with the 
algorithm), I still prefer to track it on the next() call because is 
technically the right thing to do: A tuple has been mutated so it must be 
(potentially) tracked because it needs to behave "AS IF" the tuple was being 
created from scratch.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

Thanks for that detailed explanation, Pablo.

If nobody objects to the current zip fix, I'll merge it and move on to similar 
PRs for the other affected stuff:

- dict.items
- enumerate
- functools.reduce
- itertools.product
- itertools.combinations
- itertools.combinations_with_replacement
- itertools.permutations
- itertools.zip_longest

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>  I'll merge it and move on to similar PRs for the other affected stuff:

Not sure if is more ergonomic, but I would prefer to fix this in one PR so the 
buildbots don't test the partial fixes. Also is easier to revert if something 
goes wrong with the approach as that would affect all. But being said that, if 
you prefer multiple ones, I am also fine :)

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

Yeah, I'm fine with that.

--

___
Python tracker 

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

[issue42536] Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

[Brandt Bucher]

Brandt Bucher  added the comment:

Adding:

- collections.OrderedDict.items

--

___
Python tracker 

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

[issue42563] max function reports type errors in incorrect order

[Nicholas Kobald]

New submission from Nicholas Kobald :

I'm not _sure_ this is a bug, but I thought the behaviour was a bit odd. If you 
run max with a str and an int in different orders, you get this behaviour: 

>>> max(123, 'hello')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '>' not supported between instances of 'str' and 'int'
>>> max(123, 'hello')

>>> max('hello', 123)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '>' not supported between instances of 'int' and 'str'

Note that order of the error message: 'int' and 'str' is the inverse of the 
order the str and int really are. 

Did a search for max and didn't find this.

--
messages: 382463
nosy: nkobald
priority: normal
severity: normal
status: open
title: max function reports type errors in incorrect order
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Gregory Szorc]

New submission from Gregory Szorc :

(Rereporting from https://github.com/indygreg/PyOxidizer/issues/317.)

$ mkdir foo
$ cat > foo/__init__.py < test = True
> EOF
$ cat > foo/bar.py < from .__init__ import test
> EOF
$ python3.9
Python 3.9.0 (default, Nov  1 2020, 22:40:00)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo.bar
>>> import sys
>>> sys.modules['foo']

>>> sys.modules['foo.__init__']


I am surprised that `from .__init__` even works, as `__init__` isn't a valid 
module name.

What appears to be happening is the path based importer doesn't recognize the 
`__init__` as special and it falls back to its regular file probing technique 
to locate a module derive from the path. It finds the `__init__.py[c]` file and 
imports it.

A consequence of this is that the explicit `__init__` import/module exists as a 
separate module object under `sys.modules`. So you can effectively have the 
same file imported as 2 module objects living under 2 names. This could of 
course result in subtle software bugs, like module-level variables not updating 
when you expect them to. (This could also be a feature for code relying on this 
behavior, of course.)

I only attempted to reproduce with 3.9. But this behavior has likely existed 
for years.

--
components: Interpreter Core
messages: 382464
nosy: indygreg
priority: normal
severity: normal
status: open
title: "from .__init__ import ..." syntax imports a duplicate module
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