[issue40202] Misleading grammatically of ValueError Message?

[Ammar Askar]

Ammar Askar  added the comment:

Jacob, let's skip the 2.7 part of the report since that is EOL now. For 
reference, the full error on the latest Python is:

>>> a, b, c, d = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: not enough values to unpack (expected 4, got 3)

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2)


The first example already behaves as Steven describes, it gives the expected 
and actual count. In the second example it's difficult to calculate the x for 
"expected 2, got x" in general. This is because the iterable being unpacked 
could be a generator. For example, consider:

>>> a, b = itertools.repeat(42)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2)

However, we could improve the message if the object being unpacked does expose 
a length. I've attached a PR that does this, it makes the error look like:

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2, got 3)

Hopefully showing the amounts should help clarify why the error was thrown even 
if the wording seems a bit iffy.

--
nosy: +ammar2

___
Python tracker 

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

[issue40202] Misleading grammatically of ValueError Message?

[Ammar Askar]

Change by Ammar Askar :


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

___
Python tracker 

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

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

[Daniel Holth]

Change by Daniel Holth :


--
nosy: +dholth

___
Python tracker 

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

[issue40233] Awkward to set compression on writeable ZipFile.open()

[Daniel Holth]

Daniel Holth  added the comment:

My mistake. It honors ZipInfo if passed.

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

[issue39943] Meta: Clean up various issues in C internals

[Andy Lester]

Change by Andy Lester :


--
pull_requests: +18800
pull_request: https://github.com/python/cpython/pull/19445

___
Python tracker 

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

[issue40230] Itertools.product() Out of Memory Errors

[Tim Peters]

Tim Peters  added the comment:

Possibly related:

https://bugs.python.org/issue10109

Henry, I'm not clear at all about what you're saying.  Please give at least one 
specific, concrete example of the behavior you're objecting to, and specify the 
behavior you want to see instead.

--
nosy: +tim.peters

___
Python tracker 

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

[issue40235] confusing documentation for IOBase.__exit__

[Daniel Holth]

New submission from Daniel Holth :

The io documentation says:

IOBase is also a context manager and therefore supports the with statement. In 
this example, file is closed after the with statement’s suite is finished—even 
if an exception occurs:

with open('spam.txt', 'w') as file:
file.write('Spam and eggs!')


I read this to mean that my own subclass of io.BufferedIOBase would call 
close() when used as a context manager.

Instead, it is necessary to provide an implementation of __exit__ that calls 
close() to get this behavior.

The documentation lists Mixin Methods, but I couldn't find a definition of the 
term "Mixin Methods" in the docs.

--
components: IO
messages: 366032
nosy: dholth
priority: normal
severity: normal
status: open
title: confusing documentation for IOBase.__exit__
versions: Python 3.7

___
Python tracker 

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

[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)

[Andrew Nelson]

Change by Andrew Nelson :


--
nosy: +Andrew Nelson

___
Python tracker 

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

[issue40230] Itertools.product() Out of Memory Errors

[Dennis Sweeney]

Change by Dennis Sweeney :


--
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue40230] Itertools.product() Out of Memory Errors

[Dennis Sweeney]

Dennis Sweeney  added the comment:

The trouble is that itertools.product accepts iterators, and there is no 
guaranteed way of "restarting" an arbitrary iterator in Python. Consider:

>>> a = iter([1,2,3])
>>> b = iter([4,5,6])
>>> next(a)
1
>>> next(b)
4
>>> from itertools import product
>>> list(product(a, b))
[(2, 5), (2, 6), (3, 5), (3, 6)]

Since there's no way to get back to items you've already consumed, the current 
approach is to consume all of the iterators to begin with and store their items 
in arrays, then lazily produce tuples of the items at the right indices of 
those arrays.

Perhaps one could consume lazily from the iterators, say, only filling up the 
pools as they're needed and not storing the contents of the first iterator, but 
this would mean sometimes producing a product iterator that was doomed to cause 
a memory error eventually. If you really need this behavior you could do this 
in Python:

def lazy_product(*iterables):
if not iterables:
yield ()
return
it0 = iterables[0]
for x in it0:
print(f"{x=}")
for rest in lazy_product(*iterables[1:]):
print(f"{rest=}")
yield (x,) + rest

The above could surely be optimized as maybe you're suggesting, but this would 
be a backward-incompatible change for itertools.product.

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

[Peter Lovett]

Change by Peter Lovett :


--
nosy: +PeterL777

___
Python tracker 

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

[issue37266] Daemon threads must be forbidden in subinterpreters

[Eric Snow]

Eric Snow  added the comment:

I've opened bpo-40234 to address backward incompatibility from this
change (e.g. affecting mod-wsgi).

--

___
Python tracker 

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

[issue40234] Disallow daemon threads in subinterpreters optionally.

[Eric Snow]

New submission from Eric Snow :

In bpo-37266 we strictly disallowed creation of daemon threads in 
subinterpreters.  However, this is backward-incompatible for existing users of 
the subinterpreter C-API (such as mod-wsgi).

Rather than reverting that change I suggest that we make it opt-in through the 
interpreter config.  That would preserve backward-compatibility.  It would also 
make it so we can disallow daemon threads in subinterpreters created through 
PEP 554.  We could also deprecate use of daemon threads in *all* 
subinterpreters, with the goal of dropping support after a while.

--
components: Interpreter Core
messages: 366029
nosy: eric.snow, grahamd, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Disallow daemon threads in subinterpreters optionally.
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

[issue40233] Awkward to set compression on writeable ZipFile.open()

[Daniel Holth]

New submission from Daniel Holth :

It looks like this is the current API to set compression at the individual file 
level when writing with ZipFile.open()

z.compression = zipfile.ZIP_STORED
data_writer = z.open(zip_info or filename, "w")
z.compression = saved

It would be useful to have a parameter or to honor the compression setting of 
the passed ZipInfo.

--
components: Library (Lib)
messages: 366028
nosy: alanmcintyre, dholth, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Awkward to set compression on writeable ZipFile.open()
versions: Python 3.7

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

> I close this issue with a complex history.
>
> If someone wants to continue to work on this topic, please open an issue with 
> a very clear description of what should be done and how it is supposed to be 
> used.

Yeah, there is more to do.  I'll create a new issue.

--

___
Python tracker 

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

[issue39891] [difflib] Improve get_close_matches() to better match when casing of words are different

[brian.gallagher]

brian.gallagher  added the comment:

Just giving this a bump, in case it has been forgotten about.

I've posted a patch at https://github.com/python/cpython/pull/18983.

It adds a new parameter "ignorecase" to get_close_matches() that, if set to 
True, will result in the SequenceMatcher treating any character case 
insensitively (as determined by str.lower()).

The benefit to using this keyword, as opposed to letting the application handle 
the normalization, is that it saves on memory. If the application has to 
normalize and supply a separate list to get_close_matches(), then it ends up 
having to maintain a mapping between the original string and the normalized 
string. As an example:

>>> from difflib import get_close_matches
>>> word = 'apple'
>>> possibilities = ['apPLE', 'APPLE', 'APE', 'Banana', 'Fruit', 'PEAR', 
>>> 'CoCoNuT']
>>> normalized_possibilities = {p.lower(): p for p in possibilities}
>>> result = get_close_matches(word, normalized_possibilities.keys())
>>> result
['apple', 'ape']
>>> normalized_result = [normalized_possibilities[r] for r in result]
>>> normalized_result
['APPLE', 'APE']

By letting the SequenceMatcher handle the casing on the fly, we could 
potentially save large amounts of memory if someone was providing a huge list 
to get_close_matches.

--

___
Python tracker 

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

[issue40112] AIX: xlc - default path changed and no longer recognized

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +18798
pull_request: https://github.com/python/cpython/pull/19444

___
Python tracker 

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

[issue40077] Convert static types to PyType_FromSpec()

[Eric Snow]

Eric Snow  added the comment:

> Wouldn't having less static types slow down startup time?

FWIW, I've been considering an approach where the main interpreter
keeps using static types but subinterpreters use heap types.  If it
isn't too much effort (or too hacky) then it might be a sufficient
solution for now.

--
nosy: +eric.snow

___
Python tracker 

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +18797
pull_request: https://github.com/python/cpython/pull/19443

___
Python tracker 

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 37a257c0ae0d4ba746397ae7584db887b175ab24 by Victor Stinner in 
branch '3.8':
bpo-40204: Pin Sphinx version to 1.8.2 in Doc/Makefile (GH-19442)
https://github.com/python/cpython/commit/37a257c0ae0d4ba746397ae7584db887b175ab24


--

___
Python tracker 

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

[issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

[STINNER Victor]

STINNER Victor  added the comment:

> I guess that you're talking about Doc/Makefile which uses "Sphinx" in 3.8 but 
> "Sphinx==2.2.0" in master.

I wrote PR 19442 to pin Sphinx version to 1.8.2 in Doc/Makefile.

--

___
Python tracker 

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +18796
pull_request: https://github.com/python/cpython/pull/19442

___
Python tracker 

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

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration

[STINNER Victor]

STINNER Victor  added the comment:

> Python 3.8 and Python 3.7 doesn't have Sphinx pinned to 2.2.0 while master 
> does.

In 3.8, .azure-pipelines/docs-steps.yml contains:

- script: python -m pip install sphinx==1.8.2 blurb python-docs-theme

and .travis.yml contains:

- python -m pip install sphinx==1.8.2 blurb python-docs-theme

For example, the Sphinx version was changed from 1.8.1 to 1.8.2 in the CI 
configuration by:

commit 7f4ba4afd47f21f61de9035544809fc67d136f35
Author: Julien Palard 
Date:   Sat Nov 24 11:35:21 2018 +0100

Doc: Bump sphinx. (GH-10676)

--

I guess that you're talking about Doc/Makefile which uses "Sphinx" in 3.8 but 
"Sphinx==2.2.0" in master. Code in 3.8:

venv:
$(PYTHON) -m venv $(VENVDIR)
$(VENVDIR)/bin/python3 -m pip install -U pip setuptools
$(VENVDIR)/bin/python3 -m pip install -U Sphinx blurb python-docs-theme
@echo "The venv has been created in the $(VENVDIR) directory"

--

___
Python tracker 

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

[issue40216] Support --runstatedir in configure

[STINNER Victor]

STINNER Victor  added the comment:

When a core developer updates configure.ac, they use their local version of 
autoconf. It may or may not generate --runstatedir. It doesn't seem common to 
co-install multiple versions of autoconf, and so we cannot require all core 
developers to have one specific autoconf version, or a minimum version.

I close the issue. Reopen it or open a new issue if you would like to 
experiment a different approach.

Fedora always regenerates the configure script from configure.ac. Maybe other 
Linux distributions do something similar.

The configure script is tracked by Git since it's more convenient for core 
developers. It's uncommon to update configure.ac, and it avoids a dependency on 
autoconf to quickly hack CPython.

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

This issue has a long history. A change has been applied and then reverted 
three times in a row. Pending calls are now per-interpreter.

The issue title is "Add a cross-interpreter-safe mechanism to indicate that an 
object may be destroyed." but I don't understand if pending calls are expected 
to be used to communicate between two interpreters. Why not using a UNIX pipe 
and exchange bytes through it? Py_AddPendingCall() is a weird concept. I would 
prefer to not abuse it.

Moreover, it's unclear if this issue attempts to *share* a same object between 
two interpreters. I would prefer to avoid that by any possible way.

I close this issue with a complex history.

If someone wants to continue to work on this topic, please open an issue with a 
very clear description of what should be done and how it is supposed to be used.

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

___
Python tracker 

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

[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

[STINNER Victor]

STINNER Victor  added the comment:

> I reopen the issue because of bpo-40082 "trip_signal() gets NULL tstate on 
> Windows on CTRL+C" regression.

bpo-40082 is fixed, so I close the issue again.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

> FYI, after merging that PR I realized that the COMPUTE_EVAL_BREAKER macro 
> isn't quite right.

I reworked this function in bpo-40010.

--

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

Pavel Kostyuchenko:
> (...) The error seems to be caused not by those changes, but by lack of 
> synchronization in the multiprocessing.managers.Server.

Pavel: would you mind to open a separated issue to suggest to add 
synchronization and/or avoid daemon thread in multiprocessing?

The concurrent.futures module was recently modified to avoid daemon threads in 
bpo-39812.

--

___
Python tracker 

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

[issue40232] PyOS_AfterFork_Child() should use _PyThread_at_fork_reinit()

[STINNER Victor]

New submission from STINNER Victor :

In bpo-40089, I added _PyThread_at_fork_reinit() function to reinitialize a 
lock after a lock. PyOS_AfterFork_Child() should use it rather than creating 
new locks. For example, currently _PyEval_ReInitThreads() calls:

pending->lock = PyThread_allocate_lock();

--
components: Interpreter Core
messages: 366015
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyOS_AfterFork_Child() should use _PyThread_at_fork_reinit()
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

[issue40231] Fix pending calls in subinterpreters

[STINNER Victor]

STINNER Victor  added the comment:

I modified _PyEval_AddPendingCall() to accept interp rather than tstate to fix 
bpo-40082:

New changeset b54a99d6432de93de85be2b42a63774f8b4581a0 by Victor Stinner in 
branch 'master':
bpo-40082: trip_signal() uses the main interpreter (GH-19441)
https://github.com/python/cpython/commit/b54a99d6432de93de85be2b42a63774f8b4581a0

--

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-40231: Fix pending calls in subinterpreters.

--

___
Python tracker 

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

[STINNER Victor]

STINNER Victor  added the comment:

Thanks for the bug report Alexander Riccio. I fixed bug in master. Python 3.8 
is not affected.

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b54a99d6432de93de85be2b42a63774f8b4581a0 by Victor Stinner in 
branch 'master':
bpo-40082: trip_signal() uses the main interpreter (GH-19441)
https://github.com/python/cpython/commit/b54a99d6432de93de85be2b42a63774f8b4581a0


--

___
Python tracker 

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

[issue40231] Fix pending calls in subinterpreters

[STINNER Victor]

New submission from STINNER Victor :

Currently, _Py_ThreadCanHandlePendingCalls() only returns true if the current 
thread is the Python "main thread" (_PyRuntime.main_thread).

_PyRuntime.main_thread is initialized by _PyRuntime_Initialize().

The problem is that a subinterpreter can run a separated thread which may not 
be the "main thread".

As a consequence, a subinterpreter will not run schedulded pending calls, or it 
will run them later than it could.

I modified COMPUTE_EVAL_BREAKER() of ceval.c in bpo-40010: now if 
tstate->interp->ceval.pending.calls_to_do is true, 
tstate->interp->ceval.eval_breaker is only set to 1 if 
_Py_ThreadCanHandlePendingCalls() is true.

One option would be to allow any thread to run "pending calls".

Another option is to have one "main thread" per interpreter, rather than having 
a single "main thread" for all interpreters.


I made pending calls per-interpreter in bpo-39984.


In Python 3.7, main_thread variable came from 
_PyRutimeState.ceval.pending.main_thread. It was moved into _PyRuntimeState by 
this change:

commit 5be45a6105d656c551adeee7770afdc3b806fbb5
Author: Eric Snow 
Date:   Fri Mar 8 22:47:07 2019 -0700

bpo-33608: Minor cleanup related to pending calls. (gh-12247)

--

_Py_ThreadCanHandleSignals() doesn't have to change: it must only return true 
for the main thread of the main interpreter. Currently, it's implemented as:

static inline int
_Py_ThreadCanHandleSignals(PyThreadState *tstate)
{
return (_Py_IsMainThread() && _Py_IsMainInterpreter(tstate));
}

--
components: Interpreter Core
messages: 366010
nosy: eric.snow, vstinner
priority: normal
severity: normal
status: open
title: Fix pending calls in subinterpreters
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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[David Bolen]

Change by David Bolen :


--
nosy:  -db3l

___
Python tracker 

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

[STINNER Victor]

STINNER Victor  added the comment:

> Also, someone did manage to investigate and identify a likely cause:
> https://bugs.python.org/issue33608#msg342791

I made many changes in Python internals since bpo-33608 was reported. I am not 
aware of any recent issue with pending calls and so close the issue.

If you get new crashes/hangs with pending calls during Python finalization, 
please open a new issue.

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

New changeset cfc3c2f8b34d3864717ab584c5b6c260014ba55a by Victor Stinner in 
branch 'master':
bpo-37127: Remove _pending_calls.finishing (GH-19439)
https://github.com/python/cpython/commit/cfc3c2f8b34d3864717ab584c5b6c260014ba55a

--

___
Python tracker 

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

[STINNER Victor]

STINNER Victor  added the comment:

I removed _pending_calls.finishing for multiple reasons:

* _PyEval_AddPendingCall() used the C API whereas the caller may not hold the 
GIL.
* bpo-40082: trip_signal() can be called from a thread which has no Python 
thread state. On Windows, CTRL+C calls trip_signal() in a new thread a each 
call.

I rewrote trip_signal() to only use the PyInterpreterState ("interp") and avoid 
PyThreadState ("tstate") in PR 19441 to fix bpo-40082.

trip_signal() should read and set atomtic variables: don't modify globals 
without a lock. _PyEval_AddPendingCall() is not fully async-signal safe yet :-/ 
Using a lock is unsafe in a signal handler.

--

___
Python tracker 

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue40216] Support --runstatedir in configure

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Upstream autoconf has not had a release in many years. Ubuntu packages a 
unreleased upstream version that adds runstatedir. Absent a more rigorous 
process for the regeneration of configure, this change is not useful; it will 
just get overwritten the next time someone with an older autoconf regenerates 
it.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue40230] Itertools.product() Out of Memory Errors

[Zachary Ware]

Change by Zachary Ware :


--
components: +Library (Lib) -Distutils
nosy: +rhettinger -dstufft, eric.araujo
stage:  -> test needed

___
Python tracker 

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

[issue40230] Itertools.product() Out of Memory Errors

[Henry Carscadden]

New submission from Henry Carscadden :

The product method in itertools provides an implementation of the Cartesian 
product that when run on with many arguments quickly gives out of memory 
errors. The current implementation creates a lot of unnecessary lists in this 
situation. A more appropriate implementation uses dynamic programming to avoid 
these out of memory issues.

--
components: Distutils
messages: 366005
nosy: Henry Carscadden, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Itertools.product() Out of Memory Errors
type: resource usage
versions: Python 3.7

___
Python tracker 

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

[STINNER Victor]

STINNER Victor  added the comment:


New changeset cfc3c2f8b34d3864717ab584c5b6c260014ba55a by Victor Stinner in 
branch 'master':
bpo-37127: Remove _pending_calls.finishing (GH-19439)
https://github.com/python/cpython/commit/cfc3c2f8b34d3864717ab584c5b6c260014ba55a


--

___
Python tracker 

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

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

[Kyle Stanley]

Kyle Stanley  added the comment:

Steve Dower wrote:
> It's one sample point, but compare 
> https://buildbot.python.org/all/#/builders/129/builds/708 to 
> https://github.com/python/cpython/runs/571497886

FWIW, I'd be +1 in favor for using the debug build then. A few additional 
minutes would be well worth having more thorough PR tests IMO. If it becomes an 
issue, we can always revert it back, but it seems that there's little to no 
harm in trying it out.

--

___
Python tracker 

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

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

[Rustam S.]

Rustam S.  added the comment:

Please take a look at this as well:
(ipython #12049 'Unhandled exception in event loop' (WinError 995))
https://github.com/ipython/ipython/issues/12049#issuecomment-586544339 and below

--
nosy: +Rustam S.

___
Python tracker 

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

[issue35455] Solaris thread_time doesn't work with current implementation

[Jakub Kulik]

Jakub Kulik  added the comment:

Correction: looking at the PR, I made it so that it checks for SunOS, so even 
with CLOCK_THREAD_CPUTIME_ID available, new code would be executed. 

So if you believe that this should be implemented for other SunOSes, I can do 
it ;).

--

___
Python tracker 

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

[issue35455] Solaris thread_time doesn't work with current implementation

[Jakub Kulik]

Jakub Kulik  added the comment:

I was speaking for Oracle Solaris 11.4, where CLOCK_THREAD_CPUTIME_ID is now 
implemented (and we don't need it in older releases). But you are right that 
other Solaris/SunOS versions might not have this and hence would find this 
useful.

I can rebase and reopen the original PR, but I cannot test it that well now 
that our Solaris doesn't use that part of the code (I can change the #define 
for testing, that should be sufficient).

--

___
Python tracker 

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

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

[Steve Dower]

Steve Dower  added the comment:

> Do you have a general estimate or rough idea as to how much slower it would 
> be in comparison?

It's one sample point, but compare 
https://buildbot.python.org/all/#/builders/129/builds/708 to 
https://github.com/python/cpython/runs/571497886

Compile time: 3:32 (release) -> 1:10 (debug)
Test time: 12:28 (release) -> 15:31 (debug)

Though the test timing vary wildly, as some tests cause more contention than 
others and they run in a random order.

--

___
Python tracker 

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

[issue40229] tty unblocking setraw and save-restore features

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18794
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19440

___
Python tracker 

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

[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

[STINNER Victor]

STINNER Victor  added the comment:

I reopen the issue because of bpo-40082 "trip_signal() gets NULL tstate on 
Windows on CTRL+C" regression.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue40229] tty unblocking setraw and save-restore features

[Steven Lu]

New submission from Steven Lu :

I hope to be able to set blocking or unblocking in `tty.setraw` so that I won't 
need to mess with `termios` in every of my python codes using an unblocking raw 
mode. I will personally find it useful in the situation where I want a mainloop 
that continues running even if I'm not typing into my terminal.

I also feel that a save-restore feature will make mode management a lot easier.

--
components: Library (Lib)
messages: 365996
nosy: Steven Lu
priority: normal
severity: normal
status: open
title: tty unblocking setraw and save-restore features
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-40082: trip_signal() gets NULL tstate on Windows on CTRL+C.

--

___
Python tracker 

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

[issue40082] Assertion failure in trip_signal

[STINNER Victor]

STINNER Victor  added the comment:

Oh oh. This issue is quite annoying for my work on subinterpreters.

I introduced this bug when I moved pending calls from _PyRuntimeState to 
PyInterpreterState in bpo-39984. _PyEval_AddPendingCall() now requires tstate 
to add a function to pending calls of the proper interpreter.

The problem on Windows is that each CTRL+c is executed in a different thread. 
Here is a modified Python 3.8 which dumps the thread identifier ("tid") at 
startup and when trip_signal() is triggered by CTRL+C:

vstinner@WIN C:\vstinner\python\3.8>python
Running Release|x64 interpreter...
pymain_main: tid=1788
Python 3.8.1+ (heads/3.8-dirty:19be85c765, Apr  8 2020, 19:35:20) [MSC v.1916 
64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^C
trip_signal: tid=6996 tstate=
KeyboardInterrupt

>>> ^C
trip_signal: tid=2384 tstate=
KeyboardInterrupt

>>> ^C
trip_signal: tid=32 tstate=
KeyboardInterrupt

When trip_signal() is called, PyGILState_GetThisThreadState() returns NULL.

--

___
Python tracker 

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

[issue40082] trip_signal() gets NULL tstate on Windows on CTRL+C

[STINNER Victor]

Change by STINNER Victor :


--
title: Assertion failure in trip_signal -> trip_signal() gets NULL tstate on 
Windows on CTRL+C

___
Python tracker 

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

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

[SilentGhost]

SilentGhost  added the comment:

Hi Fernando,

the first parameter of the connect function is described in documentation as 
follows: 

> database is a path-like object giving the pathname (absolute or relative to 
> the current working directory) of the database file to be opened. You can use 
> ":memory:" to open a database connection to a database that resides in RAM 
> instead of on disk.

So, while it can be a bytes object, it's still would be a bytes object 
representing a file-path. It's not bytes object representing a file content of 
the database.

Hope that helps.

--
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue37127] Handling pending calls during runtime finalization may cause problems.

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +18793
pull_request: https://github.com/python/cpython/pull/19439

___
Python tracker 

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

[issue40077] Convert static types to PyType_FromSpec()

[hai shi]

Change by hai shi :


--
pull_requests: +18792
pull_request: https://github.com/python/cpython/pull/19438

___
Python tracker 

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

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

[Zachary Ware]

Zachary Ware  added the comment:

Feel free to backport PR19404 as needed, but mark versions here appropriately 
to make sure the *real* fix makes it where it needs to go.

--

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.

[Mark Shannon]

Change by Mark Shannon :


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

___
Python tracker 

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

[issue40226] Leak in tstate->interp->ceval.pending

[STINNER Victor]

STINNER Victor  added the comment:

Fixed, thanks for the bug report Stefan ;-)

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

[issue40226] Leak in tstate->interp->ceval.pending

[STINNER Victor]

STINNER Victor  added the comment:


New changeset dda5d6e071c6a9d65993d45b90232565cfad2cde by Victor Stinner in 
branch 'master':
bpo-40226: PyInterpreterState_Delete() deletes pending calls (GH-19436)
https://github.com/python/cpython/commit/dda5d6e071c6a9d65993d45b90232565cfad2cde


--

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.

[Mark Shannon]

New submission from Mark Shannon :

Debuggers are allowed to change the line number of the currently executing 
frame. Regardless of whether this is sensible or not, the current 
implementation rather fragile.

The code makes various assumptions about the layout of the bytecode that may 
not be true in the future, and I suspect, are not true now.

We should use a more brute-force approach of computing the exception stack for 
the whole function and then searching for a safe place to jump to. This is not 
only more robust it allows more jumps.

For example, it is safe to jump from one exception handler to another.
It may not be sensible, but it is safe.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 365990
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Make setting line number in frame more robust.

___
Python tracker 

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

[issue40226] Leak in tstate->interp->ceval.pending

[STINNER Victor]

STINNER Victor  added the comment:

I confirm that I'm able to reproduce the issue on the master branch:

$ PYTHONMALLOC=malloc valgrind --leak-check=full --log-file=valgrind.log 
--num-callers=20 ./python -c pass

==44052== 32 bytes in 1 blocks are definitely lost in loss record 187 of 2,264
==44052==at 0x483980B: malloc (vg_replace_malloc.c:309)
==44052==by 0x46DA1E: _PyMem_RawMalloc (obmalloc.c:99)
==44052==by 0x46EBE1: PyMem_RawMalloc (obmalloc.c:572)
==44052==by 0x5475C7: PyThread_allocate_lock (thread_pthread.h:379)
==44052==by 0x4ED6EF: _PyEval_InitThreads (ceval.c:296)
==44052==by 0x52FE87: pycore_create_interpreter (pylifecycle.c:561)
==44052==by 0x5316B3: pyinit_config (pylifecycle.c:757)
==44052==by 0x532D38: pyinit_core (pylifecycle.c:924)
==44052==by 0x5338F5: Py_InitializeFromConfig (pylifecycle.c:1134)
==44052==by 0x41DA88: pymain_init (main.c:66)
==44052==by 0x41EAAC: pymain_main (main.c:653)
==44052==by 0x41EB39: Py_BytesMain (main.c:686)
==44052==by 0x41D6CE: main (python.c:16)

> 50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a
leak. Possibly the leak was there before but showed up under
"still reachable".

Python freed pending calls at exit. It's just that Valgrind decided to complain 
about them :-)

=> Attached PR fix the issue.

Note: the GIL is still leaked at exit. See "Don't destroy the GIL at exit" 
section of 
https://vstinner.github.io/daemon-threads-python-finalization-python32.html for 
the rationale.

--

___
Python tracker 

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

[issue40226] Leak in tstate->interp->ceval.pending

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue39851] tarfile: Exception ignored in (... stdout ...) BrokenPipeError

[Dong-hee Na]

Change by Dong-hee Na :


--
keywords: +patch
Added file: https://bugs.python.org/file49046/bpo-39851.patch

___
Python tracker 

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

[issue40227] SSLError is not passed to the client during handshake

[Ivan Ivanyuk]

New submission from Ivan Ivanyuk :

Due to the combination of the logic here: 
https://github.com/python/cpython/blob/master/Lib/asyncio/sslproto.py#L483 and 
changes introduced in the issue https://bugs.python.org/issue37035, the 
assumption that "Not-logged exceptions are not skipped but reported to the user 
by protocol.connection_lost(exc) callback." as stated in the issue is not valid.
 If SSLError happens during the handshake, no exception get's propagated even 
if it's possible to log stacktrace using loop.set_debug(True).

 As opposed to the usage pattern mentioned in the initial issue comment, we are 
very much interested in the errors there, so, for now, I just monkey patch 
SSLprotocol.connection_lost() in runtime to be like this 
https://github.com/anthrax-0/cpython/pull/1/commits/d652ed8d0e72bb839fe4841530cc48928b3c3bb0
 .

What should be the best solution for this?

--
components: asyncio
messages: 365988
nosy: asvetlov, iivanyuk, yselivanov
priority: normal
severity: normal
status: open
title: SSLError is not passed to the client during handshake
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue36287] Make ast.dump() not output optional default fields

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

Adding issue 39981 as a dependency.

--
dependencies: +Default values for AST Nodes

___
Python tracker 

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

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

[Fernando]

Change by Fernando :


--
components: +Extension Modules -IO

___
Python tracker 

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

[issue39851] tarfile: Exception ignored in (... stdout ...) BrokenPipeError

[Dong-hee Na]

Dong-hee Na  added the comment:

Victor,
I found a way how to deal with it.
The submitted file will show how it can be handled.

If you remove the try: finally statement.
You can see the same stdout which occurred from tarfile

But I'd like to listen to your opinion before submitting the patch. :)

➜  cpython git:(master) ✗ set -o pipefail
➜  cpython git:(master) ✗ ./python.exe ttt.py
test
hi
➜  cpython git:(master) ✗ ./python.exe ttt.py | true
➜  cpython git:(master) ✗ echo $?
32

--
Added file: https://bugs.python.org/file49045/approach.py

___
Python tracker 

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

[issue40154] embedded null byte when connecting to sqlite database using a bytes object

[Fernando]

Fernando  added the comment:

bump?

--

___
Python tracker 

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

[issue40225] generator exhaustion for builtin functions in nested call is O(depth)

[brendon zhang]

Change by brendon zhang :


--
title: generator exhaustion for builtin functions in recursion is O(depth) -> 
generator exhaustion for builtin functions in nested call is O(depth)

___
Python tracker 

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

[issue40225] generator exhaustion for builtin functions in recursion is O(depth)

[brendon zhang]

Change by brendon zhang :


--
title: max() performance regression (quadratic time) -> generator exhaustion 
for builtin functions in recursion is O(depth)

___
Python tracker 

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

[issue40225] max() performance regression (quadratic time)

[brendon zhang]

brendon zhang  added the comment:

this affects ALL builtin functions (eg all(), any(), sum(), sorted(), etc...) 
that accept generator as input and exhaust it.

--

___
Python tracker 

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

[issue40225] max() performance regression (quadratic time)

[brendon zhang]

brendon zhang  added the comment:

update:
it is specifically caused by passing in a generator expression to max(), where 
the generator invokes recursive function.

I added another file to demonstrate this

--
Added file: https://bugs.python.org/file49044/maxbug2.py

___
Python tracker 

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

[issue34033] distutils is not reproducible

[Jeffery To]

Change by Jeffery To :


--
nosy: +jefferyto

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Jeffery To]

Change by Jeffery To :


--
nosy: +jefferyto

___
Python tracker 

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

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

[Jeffery To]

Change by Jeffery To :


--
nosy: +jefferyto

___
Python tracker 

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

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
pull_requests: +18789
pull_request: https://github.com/python/cpython/pull/19435

___
Python tracker 

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

[issue40224] delete_me

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is expected behavior, the call to "C.sm()" happens before "C" is created.

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

___
Python tracker 

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

[issue40225] max() performance regression (quadratic time)

[brendon zhang]

brendon zhang  added the comment:

You can get the replicate this issue even when removing lru_cache(None) and 
calling max with iterable of size 1.

eg.
best = max(solve(j) for j in [i-1])

--

___
Python tracker 

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

[issue40226] Leak in tstate->interp->ceval.pending

[Stefan Krah]

New submission from Stefan Krah :

50e6e991781db761c496561a995541ca8d83ff87 causes or exposes a
leak. Possibly the leak was there before but showed up under
"still reachable".

Now it is "definitely lost", so tstate->interp->ceval.pending
needs to be cleaned up.


==11235== 32 bytes in 1 blocks are definitely lost in loss record 186 of 1,901
==11235==at 0x483880B: malloc (vg_replace_malloc.c:309)
==11235==by 0x467061: _PyMem_RawMalloc (obmalloc.c:99)
==11235==by 0x467A24: PyMem_RawMalloc (obmalloc.c:572)
==11235==by 0x528599: PyThread_allocate_lock (thread_pthread.h:379)
==11235==by 0x4C69B3: _PyEval_InitThreads (ceval.c:231)
==11235==by 0x50F1EE: pycore_create_interpreter (pylifecycle.c:560)
==11235==by 0x50FB8A: pyinit_config (pylifecycle.c:756)
==11235==by 0x5102F7: pyinit_core (pylifecycle.c:923)
==11235==by 0x510D7A: Py_InitializeFromConfig (pylifecycle.c:1133)
==11235==by 0x41DAF1: pymain_init (main.c:66)
==11235==by 0x41EB04: pymain_main (main.c:653)
==11235==by 0x41EBAD: Py_BytesMain (main.c:686)
==11235==

--
components: Interpreter Core
messages: 365980
nosy: skrah, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Leak in tstate->interp->ceval.pending
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

[issue40225] max() performance regression (quadratic time)

[brendon zhang]

brendon zhang  added the comment:

Something about calling max() in deeply nested recursion context appears to 
make the overall complexity O(n^2) instead of O(n)

--

___
Python tracker 

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

[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
pull_requests: +18788
pull_request: https://github.com/python/cpython/pull/19434

___
Python tracker 

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

[issue40225] max() performance regression (quadratic time)

[brendon zhang]

New submission from brendon zhang :

There is a performance regression of the max (and also min) function 
implementation starting in python 3.7.

I provide code and associated benchmarks in the file attachment.

--
components: Library (Lib)
files: maxbug.py
messages: 365978
nosy: brendon-zh...@hotmail.com
priority: normal
severity: normal
status: open
title: max() performance regression (quadratic time)
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file49043/maxbug.py

___
Python tracker 

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

[issue40224] delete_me

[keyboardAnt]

Change by keyboardAnt :


--
components:  -macOS
title: Execute a @staticmethod (Python 3.8.2) -> delete_me
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

[issue40224] Execute a @staticmethod (Python 3.8.2)

[keyboardAnt]

Change by keyboardAnt :


Removed file: https://bugs.python.org/file49042/example.py

___
Python tracker 

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

[issue40224] Execute a @staticmethod (Python 3.8.2)

[keyboardAnt]

New submission from keyboardAnt :

Executing the following code* raise a NameError**. Is it on purpose?
Attached minimal example to reproduce.

class C:
val = C.sm()

@staticmethod
def sm():
return 'val'

*With Python 3.8.2, on MacOS.
**"NameError: name 'C' is not defined"

Best regards

--
components: macOS
files: example.py
messages: 365977
nosy: keyboardAnt, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Execute a @staticmethod (Python 3.8.2)
versions: Python 3.8
Added file: https://bugs.python.org/file49042/example.py

___
Python tracker 

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

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

New submission from Stefan Krah :

Newer icc version require -fwrapv:

https://software.intel.com/en-us/forums/intel-c-compiler/topic/849064

--
components: Build
messages: 365976
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -fwrapv for new icc versions
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue40222] "Zero cost" exception handling

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

+1! I was going to implement this, but first I wanted to implement support of 
line number ranges instead of just line numbers (co_lineno). We need to design 
some compact portable format for address to address mapping (or address range 
to address mapping if it is more efficient).

Are you already working on this Mark? I would be glad to make a review.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue40222] "Zero cost" exception handling

[Mark Shannon]

New submission from Mark Shannon :

C++ and Java support what is known as "zero cost" exception handling.
The "zero cost" refers to the cost when no exception is raised. There is still 
a cost when exceptions are thrown.

The basic principle is that the compiler generates tables indicating where 
control should be transferred to when an exception is raised. When no exception 
is raised, there is no runtime overhead.

(C)Python should support "zero cost" exceptions.


Now that the bytecodes for exception handling are regular (meaning that their 
stack effect can be statically determined) it is possible for the bytecode 
compiler to emit exception handling tables.

Doing so would have two main benefits.
1. "try" and "with" statements would be faster (and "async for", but that is an 
implementation detail).
2. Calls to Python functions would be faster as frame objects would be 
considerably smaller. Currently each frame carries 240 bytes of overhead for 
exception handling.

--
assignee: Mark.Shannon
messages: 365974
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: "Zero cost" exception handling
type: performance

___
Python tracker 

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

[issue40187] Refactor typing.TypedDict

[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

[issue40185] Refactor typing.NamedTuple

[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

[issue40187] Refactor typing.TypedDict

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset f228bf2300a9d3bf833b1a89336581822e864ae5 by Serhiy Storchaka in 
branch 'master':
bpo-40187: Refactor typing.TypedDict. (GH-19372)
https://github.com/python/cpython/commit/f228bf2300a9d3bf833b1a89336581822e864ae5


--

___
Python tracker 

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

[issue40185] Refactor typing.NamedTuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a2ec06938f46683e33692615aca3875d8b8e110c by Serhiy Storchaka in 
branch 'master':
bpo-40185: Refactor typing.NamedTuple (GH-19371)
https://github.com/python/cpython/commit/a2ec06938f46683e33692615aca3875d8b8e110c


--

___
Python tracker 

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