[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset c8c818b0d73680516d5841597b705a1feeb42113 by Miss Islington (bot) 
in branch '3.7':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() 
(GH-21389)
https://github.com/python/cpython/commit/c8c818b0d73680516d5841597b705a1feeb42113


--

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[miss-islington]

miss-islington  added the comment:


New changeset 1d1c5743400bdf384ec83eb6ba5b39a355d121e3 by Miss Islington (bot) 
in branch '3.9':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() 
(GH-21385)
https://github.com/python/cpython/commit/1d1c5743400bdf384ec83eb6ba5b39a355d121e3


--

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[miss-islington]

miss-islington  added the comment:


New changeset c8b599ff0a4e4782e97e353a20146d3570845dbc by Miss Islington (bot) 
in branch '3.8':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() 
(GH-21385)
https://github.com/python/cpython/commit/c8b599ff0a4e4782e97e353a20146d3570845dbc


--

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[miss-islington]

Change by miss-islington :


--
pull_requests: +20535
pull_request: https://github.com/python/cpython/pull/21389

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[miss-islington]

Change by miss-islington :


--
pull_requests: +20534
pull_request: https://github.com/python/cpython/pull/21388

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset aebc0495572c5bb85d2bd97d27cf93ab038b5a6a by Zackery Spytz in 
branch 'master':
closes bpo-41235: Fix the error handling in SSLContext.load_dh_params() 
(GH-21385)
https://github.com/python/cpython/commit/aebc0495572c5bb85d2bd97d27cf93ab038b5a6a


--
nosy: +benjamin.peterson
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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20533
pull_request: https://github.com/python/cpython/pull/21387

___
Python tracker 

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

[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

[శ్రీనివాస్ రెడ్డి తాటిపర్తి]

Change by Srinivas  Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) 
:


--
keywords: +patch
nosy: +thatiparthy
nosy_count: 7.0 -> 8.0
pull_requests: +20532
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21386

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[mike bayer]

mike bayer  added the comment:

slight correction: it is of course possible to use gevent with a database 
driver without monkeypatching, as I wrote my own gevent benchmarks using 
psycogreen.  I think what I'm getting at is that it's a good thing if async 
DBAPIs could target asyncio explicitly rather than having to write different 
gevent/eventlet specific things, and that tools like SQLAlchemy can allow for 
greenlet style coding against those DBAPIs without one having to install/run 
the whole gevent event loop.   Basically I like the greenlet style of coding 
but I would be excited to skip the gevent part, never do any monkeypatching 
again, and also have other parts of the app doing asyncio work with other kinds 
of services. this is about interoperability.

--

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue41235] Incorrect error handling in SSLContext.load_dh_params()

[Zackery Spytz]

New submission from Zackery Spytz :

If the SSL_CTX_set_tmp_dh() call fails, SSLContext.load_dh_params() returns
None with a live exception.  It should return NULL in this case.

--
assignee: christian.heimes
components: Extension Modules, SSL
messages: 373271
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: Incorrect error handling in SSLContext.load_dh_params()
type: behavior
versions: Python 3.10, 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

[issue22239] asyncio: nested event loop

[mike bayer]

mike bayer  added the comment:

> Oh, I thought the primary problem for SQLAlchemy supporting async is that the 
> ORM needs to do IO from inside __getattr__ methods. So I assumed that the 
> reason you were so excited about greenlets was that it would let you use 
> await_() from inside those __getattr__ calls, which would involve exposing 
> your use of greenlets as part of your public API.


The primary problem is people want to execute() a SQL statement using await, 
and then they want to use a non-blocking database driver (basically asyncpg, 
I'm not sure there are any others, maybe there's one for MySQL also) on the 
back.Tools like aiopg have provided partial SQLAlchemy-like front-ends to 
accomplish this but they can't do ORM support, not because the ORM has lazy 
loading, but just to do explicit operations like query.all() or session.flush() 
that can sometimes require a lot of front-to-back database operations to 
complete which would be very involved to rewrite all that code using 
async/await.

Then there's the secondary problem of ORMs doing lazy loading, which is what 
you refer towards as "IO inside __getattr__ methods".   SQLAlchemy is not 
actually as dependent on lazy loading as other ORMs as we support a wide range 
of ways to "eagerly" load data up front.  With the SQLAlchemy 2.0-style ORM API 
that has a clear spot for "await" to occur, they can call "await 
session.execute(select(SomeObject))" and get a whole traversible graph of 
things loaded up front.We even have a loader called "raiseload" that is 
specifically anti-lazy loading, it's a loader that raises an error if you try 
to access something that wasn't explicitly loaded already.  So for a lot of 
cases we are already there.

But then, towards your example of "something.b = x", or more commonly in ORMS a 
get operation like "something.b" emitting SQL, the extension I'm building will 
very likely include some kind of feature that they can do this with an explicit 
call.  At the moment with the preliminary code that's in there, this might look 
like:

   await greenlet_spawn(getattr, something, "b")

not very pretty at the moment but that general idea.   

But the thing is, greenlet_spawn() can naturally apply to anything.  So it 
remains to be seen both how I would want to present this notion, as well as if 
people are going to be interested in it or not, but as a totally extra thing 
beyond the "await session.execute()" API that is the main thing, someone could 
do something like this:

   await greenlet_spawn(my_business_orm_method)

and then in "my_business_orm_method()", all the blocking style ORM things that 
async advocates warn against could be happening in there. I'm certainly not 
going to tell people they have to be doing that, but I dont think I should 
discourage it either, because if the above business method is written 
"reasonably" (see next paragraph), there really is no problem introduced by 
implicit IO.

By "written reasonably" I'm referring to the fact that in this whole situation, 
90% of everything people are doing here are in the context of HTTP services.   
The problem of, "something.a now creates state that other tasks might see" is 
not a real "problem" that is solved by using IO-only explicit context 
switching.  This is because in a CRUD-style application, "something" is not 
going to be a process-local yet thread-global object that had to be created 
specifically for the application (there's things like the database connection 
pool and some registries that the ORM uses, but those problems are taken care 
of and aren't specific to one particular application). There is certainly 
going to be global mutable state with the CRUD/HTTP application which is the 
database itself.  Event based programming doesn't save you from concurrency 
issues here because any number of processes maybe accessing the database at the 
same time.  There are well-established concurrency patterns one uses wit
 h relational databases, which include first and foremost transaction 
isolation, but also things like compare-and-swap, "select for update", ensuring 
MVCC is turned on (SQL Server), table locks, etc.  These techniques are 
independent of the concurrency pattern used within the application, and they 
are arguably better suited to blocking-style code in any case because on the 
database side we must emit our commands within a transaction serially in any 
case.   The major convenient point of "async" that we can fire off a bunch of 
web service requests in parallel does not apply to the CRUD-style business 
methods within our web service request because we can only do things in our 
ACID transaction one at a time.

The problem of "something.a" emitting IO needs to be made sane against other 
processes also viewing or altering "something.a", assuming "something" is a 
database-bound object like a row in a table, using traditional database 
concurrency constructs such as choosing an appropriate isolation 

[issue41227] minor typo in asyncio transport protocol

[Wansoo Kim]

Change by Wansoo Kim :


--
keywords: +patch
nosy: +ys19991
nosy_count: 4.0 -> 5.0
pull_requests: +20529
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21384

___
Python tracker 

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

[issue21041] pathlib.PurePath.parents rejects negative indexes

[Maxwell Ballenger]

Maxwell Ballenger  added the comment:

Use case: I want to see if a Path is a descendent of /tmp.

if filepath.parents[-2] == Path('tmp'):

turns into

if filepath.parents[len(filepath.parents)-2] == Path('tmp'):

--
nosy: +maxballenger

___
Python tracker 

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

[issue41225] Add a test for get_id() in the symtable module

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
components: +Tests
stage: patch review -> resolved
status: open -> closed
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

[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken

[miss-islington]

miss-islington  added the comment:


New changeset 730bce3a80819e0b7fa6bfa1e1afcd4c837b62c1 by Miss Islington (bot) 
in branch '3.8':
bpo-39417: Fix broken link to guide to building venvs (GH-18432)
https://github.com/python/cpython/commit/730bce3a80819e0b7fa6bfa1e1afcd4c837b62c1


--

___
Python tracker 

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

[issue41173] Windows ARM buildbots cannot upload results

[miss-islington]

miss-islington  added the comment:


New changeset 366cfc65f26b159e44ee30917ab35afe59f8339f by Miss Islington (bot) 
in branch '3.9':
bpo-41173: Copy test results file from ARM worker before uploading (GH-21305)
https://github.com/python/cpython/commit/366cfc65f26b159e44ee30917ab35afe59f8339f


--

___
Python tracker 

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

[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken

[Mariatta]

Mariatta  added the comment:

Just needed a backport to 3.8 (which is in flight) so this is good to be closed.
Thanks.

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

[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +20528
pull_request: https://github.com/python/cpython/pull/21383

___
Python tracker 

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

[issue27609] IDLE completions: format, factor, and fix

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Normally, tab completion works for attributes (after '.' and a possible prefix) 
and files (after os.sep and a possible prefix).  Unique matches to prefixes are 
immediately selected, as for undotted module names.  After changing the 
completion wait time and before restarting, this is disabled and tab adds 
spaces instead.  This need a new issue and fix.

--

___
Python tracker 

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

[issue41173] Windows ARM buildbots cannot upload results

[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

[issue41173] Windows ARM buildbots cannot upload results

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue41173] Windows ARM buildbots cannot upload results

[Steve Dower]

Steve Dower  added the comment:


New changeset 10772ec1505a4583d662c051e577eb2d4fb6e755 by Steve Dower in branch 
'master':
bpo-41173: Copy test results file from ARM worker before uploading (GH-21305)
https://github.com/python/cpython/commit/10772ec1505a4583d662c051e577eb2d4fb6e755


--

___
Python tracker 

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

[issue41224] Document is_annotate() in symtable and update doc strings

[Joannah Nanjekye]

Change by Joannah Nanjekye :


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

[issue41224] Document is_annotate() in symtable and update doc strings

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:


New changeset a95ac779e6bca0d87819969e361627182b83292c by Joannah Nanjekye in 
branch 'master':
bpo-41224: Document is_annotated() in symtable module and update doc strings 
(GH-21369)
https://github.com/python/cpython/commit/a95ac779e6bca0d87819969e361627182b83292c


--

___
Python tracker 

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

[issue41234] Remove symbol.sym_name

[Joannah Nanjekye]

Change by Joannah Nanjekye :


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

___
Python tracker 

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

[issue41234] Remove symbol.sym_name

[Joannah Nanjekye]

New submission from Joannah Nanjekye :

symbol.sym_name was already removed yet still documented in library/symbol.rst.

I suggest completely removing the docs too since the module is non-existing.

--
components: Library (Lib)
messages: 373261
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Remove symbol.sym_name
type: enhancement
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

[issue37373] Configuration of windows event loop for libraries

[jack1142]

Change by jack1142 :


--
nosy: +jack1142

___
Python tracker 

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

[issue41233] Missing links to errnos on Built-in Exceptions page

[yyyyyyyan]

Change by yyyan :


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

___
Python tracker 

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

[issue41233] Missing links to errnos on Built-in Exceptions page

[yyyyyyyan]

New submission from yyyan :

On the [Built-in 
Exceptions](https://docs.python.org/dev/library/exceptions.html) page, the 
exception 
[InterruptedError](https://docs.python.org/dev/library/exceptions.html#InterruptedError)
 correlates the error with the errno 
[EINTR](https://docs.python.org/dev/library/errno.html#errno.EINTR), linking 
the name `EINTR` with the errno page. This is great, since reading 
"*corresponds to errno EINTR*" is pointless if you don't know what `EINTR` 
means. The problem is `InterruptedError` is the only exception that put a link 
on the errno. All others only have the "correspondes to errno `ERRNO`", without 
any links, which makes it harder to understand.

The same thing happens on the 
[errno](https://docs.python.org/dev/library/errno.html). On the section about 
[errno.EINTR](https://docs.python.org/dev/library/errno.html#errno.EINTR) we 
have a "see also" box saying "This error is mapped to the exception 
InterruptedError", with a link to the InterruptedError section on the 
exceptions page. However, for some reason the "see also" box is only on this 
specific errno section.

The links should be added on both pages so the great pattern defined by 
`InterruptedError` and `errno.EINTR` is mantained.

--
assignee: docs@python
components: Documentation
messages: 373260
nosy: docs@python, eric.araujo, ezio.melotti, mdk, willingc, yyyan
priority: normal
severity: normal
status: open
title: Missing links to errnos on Built-in Exceptions page
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue27609] IDLE completions: format, factor, and fix

[Terry J. Reedy]

Terry J. Reedy  added the comment:

fetch_completions code could stand some refactoring.  The test should be split 
at least between attrs and files.

--

___
Python tracker 

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

[issue41231] Type annotations lost when using wraps by default

[David Caro]

David Caro  added the comment:

Hi Terry,

That would not work in this case, as I'd want to override all annotations with 
the wrapper function ones if there's any, instead of merging them.

The specific use case, is a type checker (part of TestSlide testing framework), 
to verify that if there's any type annotations, the parameters mocked and 
passed to it are the expected types.

For example, the contextmanager decorator returns an actual ContextManager, 
wrapping whatever the wrapped function returned, so if the wrapped function 
annotations prevail, then there's no way if verifying that the returned type is 
correct.

Thanks for the ChainMap pointer though, I'll use it for sure somewhere else.

--

___
Python tracker 

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

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8f42748ded5e978fe8a924115179d45a74a6363b by Victor Stinner in 
branch 'master':
bpo-29778: test_embed tests the path configuration (GH-21306)
https://github.com/python/cpython/commit/8f42748ded5e978fe8a924115179d45a74a6363b


--

___
Python tracker 

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

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

[Thor Whalen]

Thor Whalen  added the comment:

Further, note that even with the additional '__defaults__', and 
'__kwdefaults__', `functools.wraps` breaks when keyword only arguments involved:

```
from functools import wraps, WRAPPER_ASSIGNMENTS, partial

# First, I need to add `__defaults__` and `__kwdefaults__` to wraps, because 
they don't come for free...
my_wraps = partial(wraps, assigned=(list(WRAPPER_ASSIGNMENTS) + 
['__defaults__', '__kwdefaults__']))

def g(a: float, b=10):
return a * b

def f(a: int,  *, b=1):
return a * b

# all is well (for now)...
assert f(3) == 3
assert g(3) == 30
```

This:
```
my_wraps(g)(f)(3)
```
raises TypeError (missing required positional argument 'b'), expected

Note that `wraps(g)(f)(3)` doesn't throw a TypeError, but the output is not 
consistent with the signature (inspect.signature(wraps(g)(f)) is (a: float, 
b=10), so 3 should be multiplied by 10). This is because __defaults__ wasn't 
updated. See for example, that third-party from boltons.funcutils import wraps 
works as expected. And so do (the very popular) wrapt and decorator packages. 
Boltons works for wraps(f)(g), but not wraps(g)(f) in my example. 

See: 
https://stackoverflow.com/questions/62782709/pythons-functools-wraps-breaks-when-keyword-only-arguments-involved

--

___
Python tracker 

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

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

[Thor Whalen]

Thor Whalen  added the comment:

Posted to stackoverflow to gather opinions about the issue: 
https://stackoverflow.com/questions/62782230/python-functools-wraps-doesnt-deal-with-defaults-correctly

Also made GitHub PR: https://github.com/python/cpython/pull/21379

--
keywords: +patch
message_count: 1.0 -> 2.0
pull_requests: +20523
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21379

___
Python tracker 

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

[issue41232] Python `functools.wraps` doesn't deal with defaults correctly

[Thor Whalen]

New submission from Thor Whalen :

# PROBLEM

When using `functools.wraps`, the signature claims one set of defaults, but the 
(wrapped) function uses the original (wrappee) defaults.

Why might that be the desirable default?

# PROPOSED SOLUTION
Adding '__defaults__',  '__kwdefaults__' to `WRAPPER_ASSIGNMENTS` so that 
actual defaults can be consistent with signature defaults.

# Code Demo

```python
from functools import wraps
from inspect import signature

def g(a: float, b=10):
return a * b

def f(a: int, b=1):
return a * b

assert f(3) == 3

f = wraps(g)(f)

assert str(signature(f)) == '(a: float, b=10)'  # signature says that b 
defaults to 10
assert f.__defaults__ == (1,)  # ... but it's a lie!
assert f(3) == 3 != g(3) == 30  # ... and one that can lead to problems!
```

Why is this so? Because `functools.wraps` updates the `__signature__` 
(including annotations and defaults), `__annotations__`, but not 
`__defaults__`, which python apparently looks to in order to assign defaults.

One solution is to politely ask wraps to include these defaults.

```python
from functools import wraps, WRAPPER_ASSIGNMENTS, partial

my_wraps = partial(wraps, assigned=(list(WRAPPER_ASSIGNMENTS) + 
['__defaults__', '__kwdefaults__']))

def g(a: float, b=10):
return a * b

def f(a: int, b=1):
return a * b

assert f(3) == 3

f = my_wraps(g)(f)

assert f(3) == 30 == g(3)
assert f.__defaults__ == (10,)  # ... because now got g defaults!
```

Wouldn't it be better to get this out of the box?

When would I want the defaults that are actually used be different than those 
mentioned in the signature?



--
messages: 373254
nosy: Thor Whalen2
priority: normal
severity: normal
status: open
title: Python `functools.wraps` doesn't deal with defaults correctly
type: enhancement
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

[issue41230] IDLE intellisense

[Terry J. Reedy]

Terry J. Reedy  added the comment:

IDLE already has autocomplete of names, attributes, and string paths.  This is 
documented in the Completion subsection of the Editing and Navigation section 
of the doc, easily accessible on the Help menu.  Please read the doc before 
suggesting enhancements.

Issue 27609 summarizes approximately 10 existing bpo issues for improving 
completions.  Please check the list there before suggesting a specific change.

I believe that 'Intellisense' is a Microsoft's trademark for a Visual Studio 
feature.  It should not be used generically.  Since I only ever used VS, in the 
past, to compile python.exe, I never knew what Intellisense did, just that it 
made me wait when I opened VS.  (/PCBuild in the CPython repository now has 
build.bat to directly invoke the compiler without this delay.)

I am guessing from your wording that at least part of the Intellisense delay is 
to recompile the database needed for completions.  As a C++ program, VS cannot 
import python the current text of python modules the way that a python-coded 
IDE can.  It might be nice to add something to the stdlib that could be used by 
any python editor or shell, but I will not pursue that until existing issues 
are finished.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE completions: format, factor, and fix

___
Python tracker 

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

[issue37765] IDLE: Include longer keywords in __main__ autocomplete list

[Tal Einat]

Tal Einat  added the comment:

Auto-completion is not just about saving keystrokes. For example, I assume that 
many Python beginners just read through the completion list to see what the 
options are. This inconsistency would be hard to grok.

I think that including only some of the keywords in the completions list could 
potentially be very confusing. We'd have "class" but not "def", "finally" but 
not "else", "while" but not "for".

If the standard REPL completes keywords (at least on some platforms) that's a 
good enough argument to include them in IDLE, in my opinion.

--

___
Python tracker 

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

[issue37765] IDLE: Include longer keywords in __main__ autocomplete list

[Tal Einat]

Tal Einat  added the comment:

Also, note that the keywords would only be included in the suggested 
completions when not in a string and when not completing an attribute. So, for 
example, such a change could not possibly affect the completion of dunder 
method names.

--

___
Python tracker 

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

[issue16396] Importing ctypes.wintypes on Linux gives a ValueError instead of an ImportError

[Jason R. Coombs]

Change by Jason R. Coombs :


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

___
Python tracker 

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

[issue37765] IDLE: Include longer keywords in __main__ autocomplete list

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: IDLE: Include 'long' keywords in __main__ autocomplete list -> IDLE: 
Include longer keywords in __main__ autocomplete list

___
Python tracker 

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

[issue37765] IDLE: Include 'long' keywords in __main__ autocomplete list

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl said "This looks good" on the PR." while noting that True should not be 
added as  After trying out REPL completions in macOS Terminal, I *really* want 
to be able to type 'im' and have 'import' appear.  (When there is just one 
match, it is filled in without displaying a list of one item.)  I increasingly 
suffer from 'dystypia' (which I coined as the reverse of 'dyslexia'), and 
'import' is one of my worst words.  And I have to type it daily.  On #17238, 
Ramchandra Apte also requested completion of 'import'.

Sorting keywords by length, we get:
>>> sorted(keyword.kwlist, key=lambda s: len(s))
['as', 'if', 'in', 'is', 'or', 'and', 'def', 'del', 'for', 'not', 'try', 
'None', 'True', 'elif', 'else', 'from', 'pass', 'with', 'False', 'async', 
'await', 'break', 'class', 'raise', 'while', 'yield', 'assert', 'except', 
'global', 'import', 'lambda', 'return', 'finally', 'continue', 'nonlocal', 
'__peg_parser__']

I agree that adding 2 and 3 letter keywords is not useful. Among 4 letter 
keywords, None and True are already present from builtins.  'elif' and 'else' 
would need at least 3 and 4 keystrokes to complete ('e', , Down for 
'else', ).  'from' would need at least 4 because of 'filter' and 
'frozenset'.  'pass' would need 3 because of 'pow'.  'with' would require at 
least 5 if 'while' were added.  So skip length 4 keywords also.

So I am changing the proposal to adding the 17 keywords (other than False, 
already present) of length 5 or more.  These include 'async' and 'await', 
requested by Karthikeyan in the opening post above.

--
title: IDLE: Include keywords in __main__ autocomplete list -> IDLE: Include 
'long' keywords in __main__ autocomplete list
versions: +Python 3.10 -Python 3.7

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> Whether or not one buys that, the point of my approach is that SQLAlchemy 
> itself *will* publish async methods.  End user code *will not* ever context 
> switch to another task without them explicitly calling using an await.

Oh, I thought the primary problem for SQLAlchemy supporting async is that the 
ORM needs to do IO from inside __getattr__ methods. So I assumed that the 
reason you were so excited about greenlets was that it would let you use 
await_() from inside those __getattr__ calls, which would involve exposing your 
use of greenlets as part of your public API.

If you're just talking about using greenlets internally and then writing both 
sync and async shims to be your public API, then obviously that reduces the 
risks. Maybe greenlets will cause you problems, maybe not, but either way you 
know what you're getting into and the decision only affects you :-). But, if 
that's all you're using them for, then I'm not sure that they have a 
significant advantage over the edgedb-style synchronous wrapper or the 
unasync-style automatically generated sync code.

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[mohamed koubaa]

Change by mohamed koubaa :


--
pull_requests: +20522
pull_request: https://github.com/python/cpython/pull/21378

___
Python tracker 

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

[issue41206] behaviour change with EmailMessage.set_content

[R. David Murray]

R. David Murray  added the comment:

I'm short of time, if someone could approve Mark's PR and merge it it would be 
great. There wasn't supposed to be any behavior change other than the one 
documented in #40597.

--

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[Yury Selivanov]

Yury Selivanov  added the comment:

> The community is hurting *A LOT* right now because asyncio is intentionally 
> non-compatible with the traditional blocking approach that is not only still 
> prevalent it's one that a lot of us think is *easier* to work with.

Mike, I'm super happy with having you here and I encourage you to propose 
feature requests etc. That said, please don't use arguments like this here. 
Everyone has their own point of view and I, for example, haven't seen the "A 
LOT of community hurt" you're describing. I'm not implying that what you're 
saying is wrong, or that asyncio is perfect; the point is that it's just very 
subjective. The bug tracker is not the medium for these kind of remarks.

> That SQLAlchemy internally is not using this coding style, whether or not 
> that leads to new kinds of bugs, there are new kinds of bugs no matter what 
> kind of code a library uses, I don't think this hurts the user community.

You're free to use whatever approach you want in SQLAlchemy. We're here to 
share our advice and perspective (if we have any) and/or to discuss concrete 
proposals for API improvements or changes.

--

___
Python tracker 

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

[issue17238] IDLE: Add import statement completion

[Terry J. Reedy]

Terry J. Reedy  added the comment:

+1 for import completion.  Above, I misspelled 'rlcompleter' as 'rlcomplete'.  
When I just tried to import it as part of responding to #41230, the wrong name 
did not work.  I wish I could have stopped with 'import rl'.  To add a 
note to #37765, I tried 'import keywords'.  Nope, no 's'.  'import ke' 
would have been nice.  I suspect that some beginners have as much trouble with 
names they have no recently used.

im would work if keywords were added to the tab completion list. #37765.

--

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[mike bayer]

mike bayer  added the comment:

> With greenlets OTOH, it becomes possible for another task to observe 
> someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally 
> invoked an await_().

let me try this one more time.Basically if someone wrote this:

async def do_thing():
   someobj.a =1
   await do_io_setattr(someobj, "b", 2)

then in the async approach, you can again say, assuming "someobj" is global, 
that another task can observe "someobj.a == 1" without "someobj.b == 2".I 
suppose you are making the argument that because there's an "await" keyword 
there, now everything is OK because the reader of the code knows there's a 
context switch.

Whether or not one buys that, the point of my approach is that SQLAlchemy 
itself *will* publish async methods.  End user code *will not* ever context 
switch to another task without them explicitly calling using an await.  That 
SQLAlchemy internally is not using this coding style, whether or not that leads 
to new kinds of bugs, there are new kinds of bugs no matter what kind of code a 
library uses, I don't think this hurts the user community.  The community is 
hurting *A LOT* right now because asyncio is intentionally non-compatible with 
the traditional blocking approach that is not only still prevalent it's one 
that a lot of us think is *easier* to work with.

--

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[mike bayer]

mike bayer  added the comment:

> With greenlets OTOH, it becomes possible for another task to observe 
> someobj.a == 1 without someobj.b == 2, in case someobj.__setattr__ internally 
> invoked an await_(). Any operation can potentially invoke a context switch. 
> So debugging greenlets code is roughly as hard as debugging full-on 
> multithreaded code, and much harder than debugging async/await code.

I would invite you to look more closely at my approach.   The situation you 
describe above applies to a library like gevent, where IO means a context 
switch that can go anywhere.  My small recipe never breaks out of the asyncio 
event loop, and it only context switches within the scope of a single 
coroutine, not to any arbitrary coroutine.   So I don't think the above issue 
applies.

Additionally, we are here talking about *libraries* that are independently 
developed and tested distinct from end-user code.If there's a bug in 
SQLAlchemy, the end user isn't the person debugging that.   arguments over "is 
async or sync easier to debug" are IMO pretty subjective and at this point they 
are not relevant to what sync-based libraries should be doing.

--

___
Python tracker 

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

[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

Looks like this should be closed as the submitted PR was merged. Just following 
up for consesus.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue23802] patch: __deepcopy__ memo dict argument usage

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

The Pr should sort this. I will merge it tommorrow if there is no objection.

--

___
Python tracker 

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

[issue41188] Prepare CPython for opaque PyObject structure.

[Ronald Oussoren]

Change by Ronald Oussoren :


--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[Yury Selivanov]

Yury Selivanov  added the comment:

> Yeah, writing a trivial "event loop" to drive actually-synchronous code is 
> easy. Try it out:

This is exactly the approach I used in edgedb-python.

> I guess there's technically some overhead, but it's tiny.

Correct, the overhead isn't even detectable in microbenchmarks. In most async 
programs regular function calls dominate awaits by a few factors of magnitude.

> I think dropping 'await' syntax has two major downsides:

For the extra context, in the case of using this approach for something like 
edgedb-python these downsides don't really apply, because we're adapting 
async/await implementation to be sync. The async/await code can handle 
cancellation etc. whereas the sync code only needs to support the general 
protocol parsing flow. FWIW I don't think it would be possible to apply my 
approach to SQLA without a very invasive rewrite, which isn't probably worth it.

> tl;dr: I think switching from async/await -> greenlets would make it much 
> easier to write programs that are 90% correct, and much harder to write 
> programs that are 100% correct. That might be a good tradeoff in some 
> situations, but it's a lot more complicated than it seems.

Yeah, this sums up my opinion on this topic.

Also, having spent a couple of years writing and debugging big and small 
greenlet-heavy code bases I wouldn't want to touch them ever again. Your 
mileage may vary, Mike.

--

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Yeah, writing a trivial "event loop" to drive actually-synchronous code is 
easy. Try it out:

-

async def f():
print("hi from f()")
await g()

async def g():
print("hi from g()")

# This is our event loop:
coro = f()
try:
coro.send(None)
except StopIteration:
pass

-

I guess there's technically some overhead, but it's tiny.

I think dropping 'await' syntax has two major downsides:

Downside 1: 'await' shows you where context switches can happen: As we know, 
writing correct thread-safe code is mind-bendingly hard, because data can 
change underneath your feet at any moment. With async/await, things are much 
easier to reason about, because any span of code that doesn't contain an 
'await' is automatically atomic:

---
async def task1():
# These two assignments happen atomically, so it's impossible for
# another task to see 'someobj' in an inconsistent state.
someobj.a = 1
someobj.b = 2
---

This applies to all basic operations like __getitem__ and __setitem__, 
arithmetic, etc. -- in the async/await world, any combination of these is 
automatically atomic.

With greenlets OTOH, it becomes possible for another task to observe someobj.a 
== 1 without someobj.b == 2, in case someobj.__setattr__ internally invoked an 
await_(). Any operation can potentially invoke a context switch. So debugging 
greenlets code is roughly as hard as debugging full-on multithreaded code, and 
much harder than debugging async/await code.

This first downside has been widely discussed (e.g. Glyph's "unyielding" blog 
post), but I think the other downside is more important:

- 'await' shows where cancellation can happen: Synchronous libraries don't have 
a concept of cancellation. OTOH async libraries *are* expected to handle 
cancellation cleanly and correctly. This is *not* trivial. With your 
sqlalchemy+greenlets code, you've introduced probably hundreds of extra 
unwinding paths that you've never tested or probably even thought about. How 
confident are you that they all unwind correctly (e.g. without corrupting 
sqlalchemy's internal state)? How do you plan to even find them, given that you 
can't see the cancellation points in your code? How can your users tell which 
operations could raise a cancelled exception?

AFAICT you can't reasonably build systems that handle cancellation correctly 
without some explicit mechanism to track where the cancellation can happen. 
There's a ton of prior art here and you see this conclusion over and over.

tl;dr: I think switching from async/await -> greenlets would make it much 
easier to write programs that are 90% correct, and much harder to write 
programs that are 100% correct. That might be a good tradeoff in some 
situations, but it's a lot more complicated than it seems.

--
nosy: +njs

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Victor, is there any reason PyType_GetFlags() can't be converted to a macro or 
an inlined function?  That seems like a simple and robust fix that won't get in 
the way of anything else you're doing.

We shouldn't disregard macOS timings. It is an important platform —dominant in 
data science, dominant among most of my clients, and dominant among the core 
developers at the last sprint.

None of the inlining should depend on LTO and PGO.  That is fragile and will 
create hard-to-explain variations between builds (even consecutive builds on 
the same platform).  Third-party extensions, SO and DLL files won't benefit 
from that.  Also, it makes it difficult to individually optimize and analyze a 
function without a costly rebuild at every step.

--

___
Python tracker 

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

[issue41231] Type annotations lost when using wraps by default

[Terry Davis]

Terry Davis  added the comment:

I don't understand this use-case, but would it make sense to `ChainMap` the 
wrapper's __annotations__ on top of the wrapped __annotations__?

--
nosy: +Terry Davis

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Stefan Krah]

Stefan Krah  added the comment:

s/PyPy as a bottleneck/the C-API as a bottle neck for PyPy/

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Stefan Krah]

Stefan Krah  added the comment:

A brief note for Victor that *nothing* was directed against him. On
the contrary, msg372995 was supporting him in case the commit had
actually been unreviewed, which it apparently wasn't. Sorry for
jumping on the bandwagon there.


> PEP 620 for the overall plan.

This one I have some trouble with.  It cites PyPy as a bottleneck, but
IIRC Armin Rigo was on record saying that such changes would not help
PyPy, and he would come up with a counter proposal. Has this changed?

It is also a bit unusual that the PEP is in draft status but a lot
of things are already committed.

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[mohamed koubaa]

Change by mohamed koubaa :


--
pull_requests: +20521
pull_request: https://github.com/python/cpython/pull/21375

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Serhiy, do you have any insights to offer?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Here are two timings for math.dist().  They were run with the production macOS 
builds from python.org:

$ python3.8 -m timeit -r 11 -s 'from math import dist' -s 'p=(1.1, 2.2); 
q=(1.7, 2.3)' 'dist(p, q)'
500 loops, best of 11: 58.4 nsec per loop

$ python3.9 -m timeit -r 11 -s 'from math import dist' -s 'p=(1.1, 2.2); 
q=(1.7, 2.3)' 'dist(p, q)'
500 loops, best of 11: 66.9 nsec per loop

The attached screen shot shows that the only change between the two versions is 
that the subclass check is inlined and fast in 3.8, but is an external function 
call in 3.9.

 3.8 subclass check ---
movq8(%r12), %rax
movl$0, 32(%rsp)
testb   $4, 171(%rax)
je  L779

 3.9 subclass check ---

movq8(%r12), %rdi
call_PyType_GetFlags
movl$0, 32(%rsp)
testl   $67108864, %eax
je  L856

The C code for math.dist() is unchanged between 3.8 and 3.9.  Both use 
PyTuple_Check().

This isn't unique.  Every single PyTuple_Check() is the similarly affected 
(approx. 225 occurrences).  Presumably, this affects other type checks as well.

--
Added file: https://bugs.python.org/file49303/Screen Shot 2020-07-07 at 
10.40.52 AM.png

___
Python tracker 

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

[issue41231] Type annotations lost when using wraps by default

[David Caro]

New submission from David Caro :

In version 3.2, bpo-8814 introduced copying the __annotations__ property from 
the wrapped function to the wrapper by default.

That would be the desired behavior when your wrapper function has the same 
signature than the function it wraps, but in some cases (for example, with the 
contextlib.asynccontextmanager function) the return value is different, and 
then the __annotations__ property will have invalid information:

In [2]: from contextlib import asynccontextmanager  
  

In [3]: @asynccontextmanager 
   ...: async def mytest() -> int: 
   ...: return 1 
   ...: 
  

In [4]: mytest.__annotations__  
  
Out[4]: {'return': int}


I propose changing the behavior of wraps, to only assign the __annotations__ by 
default if there's no __annotations__ already in the wrapper function, that 
would fit most default cases, but would allow to preserve the __annotations__ 
of the wrapper function when the types are explicitly specified, allowing now 
to change the contextlib.asynccontextmanager function with the proper types 
(returning now an AsyncContextManager) and keep the __annotation__ valid.

I'll try to get a POC and attach to the issue, but please comment with your 
ideas too.

--
components: Library (Lib)
messages: 373233
nosy: David Caro
priority: normal
severity: normal
status: open
title: Type annotations lost when using wraps by default
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue41215] AIX: build fails for xlc/xlC since new PEG parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Yeah, this looks like something else. I am closing this issue then

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

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +20520
pull_request: https://github.com/python/cpython/pull/21377

___
Python tracker 

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

[issue39542] Cleanup object.h header

[STINNER Victor]

STINNER Victor  added the comment:

Stefan Krah:
> Christian Heimes has expressed an interest (quite rudely) in unreviewed 
> commits elsewhere.  I wonder if that applies to everyone regardless of 
> employer.

I don't understand the relationship between this issue, Christian Heimes and 
making reviews mandatory or not.

As I wrote, the commit 45ec5b99aefa54552947049086e87ec01bc2fc9a was reviewed 
and approved by another core dev.

Stefan, please stop personal attack and stay at the technical level.

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[STINNER Victor]

STINNER Victor  added the comment:

Raymond:
> PyTuple_Check() got slower across the board.  This is problematic because the 
> principal use case for PyTuple_Check() is as a guard for various fast paths.

Raymond gave more context in this email:
https://mail.python.org/archives/list/python-...@python.org/message/Q3YHYIKNUQH34FDEJRSLUP2MTYELFWY3/

As far as I know, only macOS is impacted by this performance regression (119 
nsec => 152 nsec on a microbenchmark). On Windows and Linux, Python is built 
with LTO and PGO optimizations.

For example, the Python package provided by Fedora 32 is built with GCC 10 
using LTO and PGO. Using GCC 10 and LTO, the PyTuple_Check() code is inlined 
even if PyType_GetFlags() is function call in PyType_HasFeature().

I didn't know that on macOS, LTO was not used. I created bpo-41181 to request 
to enable LTO on the macOS installer builder, but Ned Deily rejected the issue 
(read the issue for the rationale).

I dislike comparing performances when LTO and PGO optimizations are not used. 
LTO enables tons of optimizations and PGO makes benchmark results more 
reproducible.

One idea is to stop running benchmarks on macOS, and at least only run 
benchmarks on binaries built with LTO and PGO.

--

Raymond:
> The direct cause of the degradation is that the inlining of PyType_Check() 
> didn't go so well — commit 509dd90f4684e40af3105dd3e754fa4b9c1530c1.

I'm not sure the performance changed with this commit. IMHO it's more the 
commit 45ec5b99aefa54552947049086e87ec01bc2fc9a: bpo-40170 and GH-19378.

Background behind this change: see PEP 620 for the overall plan, see bpo-39573 
and bpo-40170 to make PyObject and PyTypeObject structures opaque. The idea is 
to slowly move third party extension modules towards the stable ABI (PEP 384). 
Internally, CPython continues to access directly structure members.


> The original unreviewed commit (...)

GH-19378 was reviewed and approved by another core dev.

The impact of performance of these changes was taken in account, and that's why 
it was decided to add a new internal _PyType_HasFeature() function.

It wasn't noticed that PyTuple_Check() calls the public PyType_HasFeature() 
instead of the internal _PyType_HasFeature(). As I wrote, using LTO, the code 
is inlined anyway, so it's the same thing.

--

___
Python tracker 

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

[issue41228] Fix the typo in the description of calendar.monthcalendar(year, month)

[Nima Dini]

New submission from Nima Dini :

https://docs.python.org/3.10/library/calendar.html#calendar.monthcalendar

> days outside of the month a represented by zeros.

"a" needs to be changed to "are"

--

___
Python tracker 

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

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

[Steve Dower]

Steve Dower  added the comment:

> Python 3.5 is also vulnerable, no? This branch still gets security fixes, do 
> you plan to backport the fix?

You're right. I thought because the backport tag was gone on GitHub that it was 
EOL already.

I can do the backport.

--
nosy: +larry
versions: +Python 3.5

___
Python tracker 

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

[issue41202] Allow to provide custom exception handler to asyncio.run()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I agree with Yuri.

Usually, you don't need overriding of the default exception handler.
Indeed, if you really need this low-level API I see nothing wrong with 
`asyncio.get_running_loop()` call.

--

___
Python tracker 

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

[issue22239] asyncio: nested event loop

[Joshua Bronson]

Change by Joshua Bronson :


--
nosy: +jab

___
Python tracker 

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

[issue41202] Allow to provide custom exception handler to asyncio.run()

[tomaszdrozdz]

tomaszdrozdz  added the comment:

https://docs.python.org/3/library/asyncio-eventloop.html#error-handling-api  

Here we can read:  

Application developers should typically use the high-level asyncio functions, 
such as asyncio.run(), and should rarely need to reference the loop object or 
call its methods. This section is intended mostly for authors of lower-level 
code, libraries, and frameworks, who need finer control over the event loop 
behavior.  


So as I understand this - I should not use  
asyncio.get_running_loop  
loop.set_exception_handler(...)  

Or maybe event loop should not be in "Low level api"  ???

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[mohamed koubaa]

Change by mohamed koubaa :


--
pull_requests: +20519
pull_request: https://github.com/python/cpython/pull/21371

___
Python tracker 

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

[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

[Mark Dickinson]

Mark Dickinson  added the comment:

@JD-Veiga: would you be willing to work on a PR?

--

___
Python tracker 

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

[issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's new

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

[issue41230] IDLE intellisense

[E. Paine]

E. Paine  added the comment:

If I understand the issue correctly, such a feature already exists. Currently, 
the wait before showing the list of completions is 2 seconds 
(https://github.com/python/cpython/blob/master/Lib/idlelib/config-extensions.def#L7)
 though this can be changed in settings. It is not as advanced as you would 
find in other IDEs, though it generally does the job.

--
nosy: +epaine
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue41215] AIX: build fails for xlc/xlC since new PEG parser

[Michael Felt]

Michael Felt  added the comment:

Here is the stack trace - still during initialization: And in "ceval.c,
but dbx does not like how the 'h files are being used: line 941 and 659
lines don't match :(

(dbx) list
"object.h" has only 659 lines

Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../git/py39-3.10/Include/object.h" ($t1)
"object.h" has only 659 lines
(dbx) where
_PyEval_EvalFrameDefault(tstate = 0x3009c9d0, f = 0x0017, throwflag
= 15), line 941 in "object.h"
_PyEval_EvalCode(tstate = 0x1001c454, _co = 0x3009c250, globals =
0x2ff20260, locals = 0x10324233, args = 0x100b2798, argcount = 44,
kwnames = 0x2ff20280, kwargs = 0x2228228f, kwcount = 0, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x0003, globals = 0x2ff20340, locals
= 0x2ff202f0, args = 0x2004429c, argcount = 805945904, kwnames = (nil),
kwargs = 0x2ff202f0, kwcount = 0, kwstep = 2, defs = (nil), defcount =
0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)),
line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10110c74, globals = 0x200817a2, locals =
(nil), args = 0x30091598, argcount = 805901716, kws = 0x200817da,
kwcount = 537401128, defs = 0x30078f58, defcount = 0, kwdefs = (nil),
closure = (nil)), line 4415 in "ceval.c"
builtin___build_class__(self = 0x100b8bdc, args = (nil), nargs =
804389872, kwnames = 0x2004429c), line 222 in "bltinmodule.c"
cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100d5e54, args = (nil),
nargsf = 805553488, kwnames = 0x3004658c), line 459 in "methodobject.c"
_PyEval_EvalFrameDefault(tstate = 0x300912d8, f = 0x30050c8c, throwflag
= 805485032), line 628 in "abstract.h"
_PyEval_EvalCode(tstate = 0x10110c74, _co = 0x3004abb8, globals =
0x30095fa8, locals = 0x3009d16c, args = 0x3009d168, argcount =
805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0,
kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil),
name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x30092258, locals
= 0x2ff20680, args = 0x2004429c, argcount = 269191840, kwnames =
0x300550e0, kwargs = 0x2ff20680, kwcount = 1109926476, kwstep = 2, defs
= (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil),
qualname = (nil)), line 4416 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10090ab0, globals = (nil), locals =
0xf0653ea8, args = 0xf0653ea8, argcount = 0, kws = 0x20082720, kwcount =
804390704, defs = 0x2228228f, defcount = 0, kwdefs = (nil), closure =
(nil)), line 4415 in "ceval.c"
PyEval_EvalCode(co = 0x103a1274, globals = 0x103a155e, locals =
0x30099978), line 857 in "ceval.c"
builtin_exec_impl(module = 0x300912c4, source = 0x30050cb8, globals =
0x20060a78, locals = 0x0002), line 1035 in "bltinmodule.c"
builtin_exec(module = 0x100d58b4, args = 0x30050cb8, nargs = 0), line
371 in "bltinmodule.c.h"
cfunction_vectorcall_FASTCALL(func = 0x, args = 0x30050b80,
nargsf = 804391008, kwnames = 0x2004429c), line 443 in "methodobject.c"
PyVectorcall_Call(callable = 0x1001e5cc, tuple = 0x20060a78, kwargs =
0x2ff208c0), line 249 in "call.c"
_PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args =
0x2ff20920, kwargs = 0x2004429c), line 265 in "call.c"
do_call_core(tstate = 0x0002, func = 0x20026bc0, callargs =
0x2ff20990, kwdict = 0x3004abb8), line 5142 in "ceval.c"
_PyEval_EvalFrameDefault(tstate = 0x, f = 0x3004a070, throwflag
= 804391536), line 3603 in "ceval.c"
_PyEval_EvalCode(tstate = 0x3005e9b0, _co = 0x30062290, globals = (nil),
locals = 0x20026020, args = 0x300922f8, argcount = 805331176, kwnames =
0x2ff20b30, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil),
defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8,
qualname = 0x300197c8), line 40 in "pycore_ceval.h"
_PyFunction_Vectorcall(func = 0x3005dbac, stack = (nil), nargsf =
805553488, kwnames = 0x30040960), line 417 in "call.c"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x300921b8, throwflag
= 804392064), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30087538, co = 0x3004a1b0, args =
0x2000af70, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = 0x0001, throwflag =
804392400), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x30042fcc, co = 0x30031176, args =
0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060a78, throwflag
= 804392736), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x00e0, co = 0x009c, args =
0x3003c550, nargs = -528718917, globals = 0x3004abd8), line 40 in
"pycore_ceval.h"
_PyEval_EvalFrameDefault(tstate = (nil), f = (nil), throwflag =
804393264), line 628 in "abstract.h"
function_code_fastcall(tstate = 0x3004ab90, co = 0x3004a7c8, args =
0x2ff210f0, nargs = 537150108, globals = 

[issue41230] IDLE intellisense

[Saumitra Verma]

Change by Saumitra Verma :


--
versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.9

___
Python tracker 

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

[issue41230] IDLE intellisense

[Saumitra Verma]

New submission from Saumitra Verma :

There should be a simple autocomplete(intellisense) in idle.

--
assignee: terry.reedy
components: IDLE
messages: 373222
nosy: Saumitra Verma, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE intellisense
type: enhancement
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

[issue41229] Asynchronous generator memory leak

[JIanqiu Tao]

New submission from JIanqiu Tao :

The resource used by asynchronous generator can't be released properly when 
works with "asend" method.

Besides, in Python 3.7-, a RuntimeError was raised when asyncio.run complete, 
but the message is puzzling:
  RuntimeError: can't send non-None value to a just-started coroutine

In Python 3.8+, No Exception showed.

Python3.5 unsupport yield in async function, so it seems no affect?

--
components: Interpreter Core, asyncio
files: leak.py
messages: 373221
nosy: asvetlov, yselivanov, zkonge
priority: normal
severity: normal
status: open
title: Asynchronous generator memory leak
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49302/leak.py

___
Python tracker 

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

[issue41207] distutils.command.build_ext raises FileNotFoundError

[STINNER Victor]

STINNER Victor  added the comment:

I close the issue since it's fixed. I also reset the priority.

--
priority: release blocker -> 
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

[issue41207] distutils.command.build_ext raises FileNotFoundError

[miss-islington]

miss-islington  added the comment:


New changeset 2c82628e9aa2af4b662e92e227618859675dd726 by Miss Islington (bot) 
in branch '3.9':
bpo-41207 In distutils.spawn, rewrite FileNotFound (GH-21359)
https://github.com/python/cpython/commit/2c82628e9aa2af4b662e92e227618859675dd726


--

___
Python tracker 

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

[issue41207] distutils.command.build_ext raises FileNotFoundError

[miss-islington]

Change by miss-islington :


--
pull_requests: +20517
pull_request: https://github.com/python/cpython/pull/21373

___
Python tracker 

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

[issue41207] distutils.command.build_ext raises FileNotFoundError

[miss-islington]

miss-islington  added the comment:


New changeset 6ae2780be0667a8dc52c4fb583171ec86067d700 by Jason R. Coombs in 
branch 'master':
bpo-41207 In distutils.spawn, rewrite FileNotFound (GH-21359)
https://github.com/python/cpython/commit/6ae2780be0667a8dc52c4fb583171ec86067d700


--
nosy: +miss-islington

___
Python tracker 

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

[issue41215] AIX: build fails for xlc/xlC since new PEG parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Master has to be something else then

--

___
Python tracker 

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

[issue41221] io.TextIOWrapper ignores silently partial write if buffer is unbuffered

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +inada.naoki, serhiy.storchaka

___
Python tracker 

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

[issue41221] io.TextIOWrapper ignores silently partial write if buffer is unbuffered

[STINNER Victor]

STINNER Victor  added the comment:

cc Antoine Pitrou who was involved in io module design.

Currently, the io.TextIOWrapper implementation doesn't handle partial write: it 
doesn't fully support an unbuffered 'buffer' object.

It should either handle partial write internally, or it should inject a 
buffered writer between itself (TextIOWrapper) and the unbuffered buffer so 
handling partial writes who be handled by the buffered writer.

The socket.socket class has a sendall() method which helps to handle such 
problem. In the io module, sometimes write() can do a partial write (unbuffered 
writer like FileIO), sometimes it doesn't (buffered writer like BufferedWriter).

== C implementation ==

Modules/_io/text.c. The _io_TextIOWrapper_write_impl() function puts the 
encoded string into an internal pending_bytes list. If needed, it calls 
flush(): _textiowrapper_writeflush().

The pseudo-code of _textiowrapper_writeflush() is to call 
"self.buffer.write(b)" where b is made of all "pending bytes". write() result 
is ignored: partial write is silently ignored.

== Python implementation ==

_pyio.TextIOWrapper.write() simply calls: "self.buffer.write(b)". It ignores 
partial write silently.

--
nosy: +pitrou
title: Output of print() might get truncated in unbuffered mode -> 
io.TextIOWrapper ignores silently partial write if buffer is unbuffered

___
Python tracker 

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

[issue41215] AIX: build fails for xlc/xlC since new PEG parser

[Michael Felt]

Michael Felt  added the comment:

On 07/07/2020 11:12, Michael Felt wrote:
> Michael Felt  added the comment:
>
> I saw the mails last night and restarted my bot - it still fails.
> Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
3.7, 3.8 and 3.9 built, master does not. Will provide more info on
master later.
> know asap.
>
> Yes - expecting 3.8 and 3.7 to build, but want to be sure.
>
> On 06/07/2020 23:34, Pablo Galindo Salgado wrote:
>> Pablo Galindo Salgado  added the comment:
>>
>> Michael, could you check the latest master and 3.9 HEAD? If you don;t see 
>> the problem anymore, we can close this issue :)
>>
>> --
>>
>> ___
>> Python tracker 
>> 
>> ___
>>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

[STINNER Victor]

STINNER Victor  added the comment:

Steve: Python 3.5 is also vulnerable, no? This branch still gets security 
fixes, do you plan to backport the fix? I can do it if you are not available.

--

___
Python tracker 

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

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

[STINNER Victor]

STINNER Victor  added the comment:

FYI this vulnerability is now tracked by:
https://python-security.readthedocs.io/vuln/pysetpath-python-dll-path.html

--

___
Python tracker 

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

[issue41220] add optional make_key argument to lru_cache

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks, I see what you're trying to do now:

1) Given a slow function 
2) that takes a complex argument 
   2a)  that includes a hashable unique identifier 
   2b)  and some unhashable data
3) Cache the function result using only the unique identifier

The lru_cache() currently can't be used directly because
all the function arguments must be hashable.

The proposed solution:
1) Write a helper function
   1a) that hash the same signature as the original function
   1b) that returns only the hashable unique identifier
2) With a single @decorator application, connect
   2a) the original function
   2b) the helper function
   2c) and the lru_cache logic


A few areas of concern come to mind:

* People have come to expect cached calls to be very cheap, but it is easy to 
write input transformations that aren't cheap (i.e. looping over all the inputs 
as in your example or converting entire mutable structures to immutable 
structures).

* While key-functions are relatively well understood, when we use them 
elsewhere key-functions only get called once per element.  Here, the 
lru_cache() would call the key function every time even if the arguments are 
identical.  This will be surprising to some users.

* The helper function signature needs exactly match the wrapped function.  
Changes would need to be made in both places.

* It would be hard to debug if the helper function return values ever stop 
being unique.  For example, if the timestamps start getting rounded to the 
nearest second, they will sporadically become non-unique.

* The lru_cache signature makes it awkward to add more arguments.  That is why 
your examples had to explicitly specify a maxsize of 128 even though 128 is the 
default. 

* API simplicity was an early design goal.  Already, I made a mistake by 
accepting the "typed" argument which is almost never used but regularly causes 
confusion and affects learnability.

* The use case is predicated on having a large unhashable dataset accompanied 
by a hashable identifier that is assumed to be unique.  This probably isn't 
common enough to warrant an API extension.  

Out of curiosity, what are you doing now without the proposed extension?  

As a first try, I would likely write a dataclass to be explicit about the types 
and about which fields are used in hashing and equality testing:

@dataclass(unsafe_hash=True)
class ItemsList:
unique_id: float
data: dict = field(hash=False, compare=False)

I expect that dataclasses like this will emerge as the standard solution 
whenever people need a mapping or dict to work with keys that have a mix of 
hashable and unhashable components.  This will work with the lru_cache(), 
dict(), defaultdict(), ChainMap(), set(), frozenset(), etc.

--

___
Python tracker 

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

[issue41215] AIX: build fails for xlc/xlC since new PEG parser

[Michael Felt]

Michael Felt  added the comment:

I saw the mails last night and restarted my bot - it still fails.
Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
know asap.

Yes - expecting 3.8 and 3.7 to build, but want to be sure.

On 06/07/2020 23:34, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado  added the comment:
>
> Michael, could you check the latest master and 3.9 HEAD? If you don;t see the 
> problem anymore, we can close this issue :)
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ data

[Hiroshi Miura]

Hiroshi Miura  added the comment:

Thank you for information about similar problem.

This problem is observed and reported on 7-zip library project, 
https://github.com/miurahr/py7zr/issues/178.
py7zr heavily depend on lzma FORMAT_RAW interface.

Fortunately  7-zip container format has size database, then library can know 
output is enough or not.

In reported case, the library/caller become a state that all input data has 
send into decompressor,  but decompressor does not output anything.

I'd like to wait upstream reaction.

--

___
Python tracker 

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

[issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ data

[Hiroshi Miura]

Change by Hiroshi Miura :


Added file: 
https://bugs.python.org/file49301/0001-lzma-support-LZMA1-with-FORMAT_RAW.patch

___
Python tracker 

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

[issue41220] add optional make_key argument to lru_cache

[Itay azolay]

Itay azolay  added the comment:

Yes, you're right.
It's a bad example, I tried to simplify it, and I ended up oversimplifying it.
Real-life cases are of course more complicated.
What I wanted to accomplish, is very similar to the `key` argument in 
sorted/min/max/etc..
let my try and give you an example.

assume we have a complex data type, with a timestamp-signed attribute.
our single item will look as follows:
SingleItem = (unique_timestamp,  )
now assume we have a function "extensive_computation"

def extensive_computation(items: List[SingleItem]):
  # very hard work
  sleep(60)

As developer, I know that the every item has unique timestamp.
So for a list of N timestamp, when they are the same, the result of the 
computation will be the same.

def item_cache_key(items: List[SingleItem]):
  return (timestamp for timestamp, data in items)

I would like to then create:

@lru_cache(128, key=item_cache_key):
def cache_extensive_computation(items):
  extensive_computation(items)

Does that makes more sense?

--

___
Python tracker 

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

[issue41228] Fix the typo in the description of calendar.monthcalendar(year, month)

[Nima Dini]

Change by Nima Dini :


--
assignee: docs@python
components: Documentation
nosy: docs@python, ndini
priority: normal
pull_requests: 20516
severity: normal
status: open
title: Fix the typo in the description of calendar.monthcalendar(year, month)
type: enhancement
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

[issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ data

[Ma Lin]

Ma Lin  added the comment:

There was a similar issue (issue21872).

When decompressing a lzma.FORMAT_ALONE format data, and it doesn't have the end 
marker (but has the correct "Uncompressed Size" in the .lzma header), sometimes 
the last one to dozens bytes can't be output.

issue21872 fixed the problem in `_lzmamodule.c`. But if liblzma strictly 
follows zlib's API (IMO it should), there should be no this problem.


I debugged your code with attached file `lzmabcj.bin`, when it output 12796 
bytes, the output buffer still has 353 bytes space. So it seems to be a problem 
of liblzma.

IMHO, we first wait the reply from liblzma maintainer, if Lasse Collin thinks 
this is a bug, let us wait for the upstream fix. And I will report the 
issue21872 to see if he can fix the problem in upstream as well.

--

___
Python tracker 

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

[issue41221] Output of print() might get truncated in unbuffered mode

[Manuel Jacob]

Manuel Jacob  added the comment:

It’s possible to trigger the problem on Unix with much smaller sizes, e.g. by 
interrupting the write() with a signal handler (even if the signal handler 
doesn’t do anything). The following script starts a subprocess doing a 16MiB 
write and sends a signal, which is handled but is a no-op, after reading a bit 
from the pipe:

import signal
import subprocess
import sys

CHILD_PROCESS = '''
import signal, sys
signal.signal(signal.SIGINT, lambda *x: None)
written = sys.stdout.write('x' * 16777216)
print('written:', written, file=sys.stderr, flush=True)
'''

proc = subprocess.Popen(
[sys.executable, '-u', '-c', CHILD_PROCESS],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)
read = len(proc.stdout.read(1))
proc.send_signal(signal.SIGINT)
read += len(proc.stdout.read())
stdout, stderr = proc.communicate()
assert stdout == b''
print('stderr:', stderr)
assert read == 16777216, "read: {}".format(read)


% python3 test_interrupted_write.py
stderr: b'written: 16777216\n'
Traceback (most recent call last):
  File "test_interrupted_write.py", line 24, in 
assert read == 16777216, "read: {}".format(read)
AssertionError: read: 69632

If I remove the '-u' that gets passed to the subprocess:

% python3 test_interrupted_write.py
stderr: b'written: 16777216\n'

--

___
Python tracker 

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