[issue46833] Installer Wizard is unclear and has redundant settings

[Christian Buhtz]

New submission from Christian Buhtz :

Hello together,
this is is about the installer of Python 3.9.10 on Windows 10 64bit.

I have problems to interpret the installer wizard/dialog. And my argument is 
that no matter if there are good reasons for the current options some of the 
users are confused by it.

The goal should be to make the installer more clear about what this options do.

Lets see the "Install for all users" option:
 This appears on all three pages.
 I am not sure but would say that the first two options are related to the 
py-launcher not the the python interpreter itself. OK, but why two options?
 The third option is for the interpreter?
 And I do not see an advantage in making a difference between launcher and 
interpreter for that option.

Lets see about PATH/environment variables:
 This appears on the first page ("Add Python 3.9 to PATH") and on the third 
page ("Add Python to environment variables").
 I do not understand why.

And all this options are not synchronized. It means when I Enable "Add Python 
3.9 to Path" on the first page the "Add Python to environment variables" on the 
third page is not updated (enabled) also.

Again:
I am sure there are very good reasons for this separated options. But the 
wizard should make this reason clear to the user (or her/his admins) so that 
she/he can make an well informed decision.

--
components: Installation, Windows
files: python3_9_10_install_wizard_page1-3.png
messages: 413777
nosy: buhtz, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Installer Wizard is unclear and has redundant settings
versions: Python 3.9
Added file: 
https://bugs.python.org/file50638/python3_9_10_install_wizard_page1-3.png

___
Python tracker 

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

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

[Ofey Chan]

Ofey Chan  added the comment:

Hello, I am new to cpython project and want to help.

I dig into `follow_wrapper_chains` feature and found it really interesting.

In `inspect.signature()`, the conversion of `functools.partial` object's 
signature is made when going down the unwrap chain.

Relevant code: 
https://github.com/python/cpython/blob/288af845a32fd2a92e3b49738faf8f2de6a7bf7c/Lib/inspect.py#L2467

So, there is an inconsistent assumption which cause the problem:

- `inspect.signature()` handle `functools.partial` object it met specially.
- `functools.update_wrapper()` just treat `functools.partial` object as a 
normal decorator and ignore it.
  
After calling `functools.update_wrapper()`, a new (wrong) signature is 
constructed, and it covers the original (right) process.

That's why `inspect.signature()` returns the *original* function's signature, 
not the *wrapped* function's signature.

In my humble opinion, A sane solution might be that: let the 
`functools.update_wrapper` respect the `functools.partial` object in the 
similar way of `inspect.signature()`.

I'm working on a pull request to express my idea more clearly, any help is 
welcome!

--
nosy: +ofey404

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Seems a CancelledError message can be lost also in Condition.wait().

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[padremayi]

padremayi  added the comment:

IMHO if the developer doesn't manage the XML itself it is VERY unreasonable to 
use the document value and not the developer one. At the moment the developer 
must predict the future changes on XML structure.

For my point of view if an attribute is not present get() must return None (or 
the default value passed by developer) AND the document default adding an 
optional parameter to get() call: if True return 2 values, otherwise return the 
document one (current behaviour).

In this way the old code continue to work

--

___
Python tracker 

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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[padremayi]

Change by padremayi :


--
status: closed -> open

___
Python tracker 

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

[issue26832] ProactorEventLoop doesn't support stdin/stdout nor files with connect_read_pipe/connect_write_pipe

[Min RK]

Min RK  added the comment:

It appears that connect_read_pipe also doesn't accept pipes returned by 
`os.pipe`. If that's the case, what _does_ ProactorEventLoop.connect_read_pipe 
accept? I haven't been able to find any examples of `connect_read_pipe` that 
work on Windows, and every connect_read_pipe call in the cpython test suite 
appears to be skipped on win32. Should it still be raising NotImplementedError 
on ProactorEventLoop?

I think the error handling could be better (I only get logged errors, nothing I 
can catch/handle). It seems like `connect_read_pipe` itself should raise when 
it fails to register the pipe with IOCP. If that's not feasible, 
connection_lost/transport.close should probably be triggered, but it isn't with 
Python 3.9, at least.

Example that works on posix, but seems to fail with non-catchable errors with 
ProactorEventLoop:

```
import asyncio
import os
import sys

class PipeProtocol(asyncio.Protocol):
def __init__(self):
self.finished = asyncio.Future()

def connection_made(self, transport):
print("connection made", file=sys.stderr)
self.transport = transport

def connection_lost(self, exc):
print("connection lost", exc, file=sys.stderr)
self.finished.set_result(None)

def data_received(self, data):
print("data received", data, file=sys.stderr)
self.handler(data)

def eof_received(self):
print("eof received", file=sys.stderr)
self.finished.set_result(None)

async def test():
r, w = os.pipe()
rf = os.fdopen(r, 'r')
x, p = await asyncio.get_running_loop().connect_read_pipe(PipeProtocol, rf)
await asyncio.sleep(1)
print("writing")
os.write(w, b'asdf')
await asyncio.sleep(2)
print("closing")
os.close(w)
await asyncio.wait([p.finished], timeout=3)
x.close()

if __name__ == "__main__":
asyncio.run(test())
```

--
nosy: +minrk
versions: +Python 3.10, Python 3.11, 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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[padremayi]

padremayi  added the comment:

Now:
def get(self, key, default=None)

Future:
def get(self, key, default=None, double_value=False)

No code break

--

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 424023efee5b21567b4725015ef143b627112e3c by Brandt Bucher in 
branch 'main':
bpo-46329: Fix test failure when `Py_STATS` is enabled (GH-31511)
https://github.com/python/cpython/commit/424023efee5b21567b4725015ef143b627112e3c


--

___
Python tracker 

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

[issue45885] Specialize COMPARE_OP

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 375a56bd4015596c0cf44129c8842a1fe7199785 by Brandt Bucher in 
branch 'main':
bpo-45885: Don't un-adapt `COMPARE_OP` when collecting stats (GH-31516)
https://github.com/python/cpython/commit/375a56bd4015596c0cf44129c8842a1fe7199785


--

___
Python tracker 

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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[Stefan Behnel]

Stefan Behnel  added the comment:

> IMHO if the developer doesn't manage the XML itself it is VERY unreasonable 
> to use the document value and not the developer one.

I disagree. If the document says "this is the default if no explicit value if 
given", then I consider that just as good as providing a value each time. 
Meaning, the attribute *is* in fact present, just not explicitly spelled out on 
the element.

I would specifically like to avoid adding a new option just to override the way 
the document distributes its attribute value spelling across DTD and document 
structure. In particular, the .get() method is the wrong place to deal with 
this.

You can probably configure the parser to ignore the internal DTD subset, if 
that's what you want.

--

___
Python tracker 

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

[issue46834] test_gdb started to fail on buildbot/s390x RHEL7

[Nikita Sobolev]

New submission from Nikita Sobolev :

Log sample:

```
==
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
--
Traceback (most recent call last):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", 
line 782, in test_up_then_down
self.assertMultilineMatches(bt,
^^^
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", 
line 297, in assertMultilineMatches
self.fail(msg='%r did not match %r' % (actual, pattern))

AssertionError: 'Breakpoint 1 at 0x801ff160: file Python/bltinmodule.c, line 
1168.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db 
library "/lib64/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=, 
v=<_PyRuntime+2184>) at Python/bltinmodule.c:1168\n1168\t{\n#16 Frame 
0x3fffdfb1118, for file , line 9, in bar (a=1, b=2, c=3)\n#16 Frame 
0x3fffdfb1090, for file , line 6, in foo (a=1, b=2, c=3)\n#16 Frame 
0x3fffdfb1020, for file , line 14, in  ()\nUnable to find an 
older python frame\n#4 Frame 0x3fffdfb11a8, for file , line 12, in baz 
(args=(1, 2, 3))\n' did not match '^.*\n#[0-9]+ Frame 0x-?[0-9a-f]+, for file 
, line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n#[0-9]+ \n#[0-9]+ Frame 
0x-?[0-9a-f]+, for file , line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n$'
--
Ran 32 tests in 15.312s
FAILED (failures=53)
test test_gdb failed
1 test failed again:
test_gdb
```

Full log (too long): 
https://buildbot.python.org/all/#/builders/179/builds/1769/steps/5/logs/stdio

It started to happen (at least more often - however, I cannot find any older 
failures at the moment) after this commit: 
https://github.com/python/cpython/commit/b899126094731bc49fecb61f2c1b7557d74ca839

Build link: https://buildbot.python.org/all/#/builders/402/builds/1744

Latest commits (at this moment):
- Fails: 
https://github.com/python/cpython/commit/375a56bd4015596c0cf44129c8842a1fe7199785
- Passes: 
https://github.com/python/cpython/commit/424023efee5b21567b4725015ef143b627112e3c
- Fails: 
https://github.com/python/cpython/commit/288af845a32fd2a92e3b49738faf8f2de6a7bf7c

--
components: Tests
messages: 413786
nosy: sobolevn, vstinner
priority: normal
severity: normal
status: open
title: test_gdb started to fail on buildbot/s390x RHEL7
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue46834] test_gdb started to fail on buildbot/s390x RHEL7

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Sorry, wrong link. It started to fail after this commit: 
https://github.com/python/cpython/commit/66b3cd7063322a9f5c922a97bbd06fdb9830

--

___
Python tracker 

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

[issue46835] ImportError: bad magic number in ... does not indicate where is that file located

[Miro Hrončok]

New submission from Miro Hrončok :

Recently I've been debugging a very nasty bug report that looked like this:

Traceback (most recent call last):
  File "/usr/bin/jupyter-notebook", line 5, in 
from notebook.notebookapp import main
  File "/usr/lib/python3.10/site-packages/notebook/notebookapp.py", line 
78, in 
from .services.kernels.kernelmanager import MappingKernelManager, 
AsyncMappingKernelManager
  File 
"/usr/lib/python3.10/site-packages/notebook/services/kernels/kernelmanager.py", 
line 18, in 
from jupyter_client.session import Session
  File "/usr/lib/python3.10/site-packages/jupyter_client/session.py", line 
41, in 
from jupyter_client.jsonutil import extract_dates, squash_dates, 
date_default
  File "/usr/lib/python3.10/site-packages/jupyter_client/jsonutil.py", line 
10, in 
from dateutil.parser import parse as _dateutil_parse
  File "/usr/lib/python3.10/site-packages/dateutil/parser/__init__.py", 
line 2, in 
from ._parser import parse, parser, parserinfo, ParserError
  File "/usr/lib/python3.10/site-packages/dateutil/parser/_parser.py", line 
42, in 
import six
ImportError: bad magic number in 'six': b'\x03\xf3\r\n'

For details, see https://bugzilla.redhat.com/2057340 and 
https://github.com/benjaminp/six/issues/359


What would really make things much easier to understand would be if the 
exception mentioned what is the path of 'six'.


Consider this example:

A rogue .py file in /usr/bin:

$ sudo touch /usr/bin/copy.py

Programs fail with:

Traceback (most recent call last):
  File "/usr/bin/...", line ..., in 
...
ImportError: cannot import name 'deepcopy' from 'copy' (/usr/bin/copy.py)

Immediately I can see there is /usr/bin/copy.py which is probably not supposed 
to be there.

However, when it is a pyc instead:

$ sudo touch /usr/bin/copy.pyc

Programs fail with:

Traceback (most recent call last):
  File "/usr/bin/...", line ..., in 
...
ImportError: bad magic number in 'copy': b''

Now I have no idea where "copy" is.


The is a request for that exception to give that infomartion.

--
components: Interpreter Core
messages: 413788
nosy: hroncok, petr.viktorin
priority: normal
severity: normal
status: open
title: ImportError: bad magic number in ... does not indicate where is that 
file located
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue46835] ImportError: bad magic number in ... does not indicate where is that file located

[Miro Hrončok]

Miro Hrončok  added the comment:

Apparently, the exception already contains a path attribute with exactly the 
kind of information I'd like to see.

What if the message was:

ImportError: bad magic number in '/usr/bin/six.pyc': b'\x03\xf3\r\n'

Would that be accepted as a PR? Should I discuss this on the mailing list?

--

___
Python tracker 

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

[issue45326] Unexpected TypeError with type alias+issubclass+ABC

[burrito]

Change by burrito :


--
nosy: +burrito

___
Python tracker 

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

[issue46622] Add an async variant of lru_cache for coroutines.

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Thanks, Raymond.

I agree that caching of iterators and generators is out of the issue scope.

Also, I agree that a separate async cache decorator should be added. I prefer 
the `async_lru_cache` (and maybe `async_cache` for the API symmetry). We have 
`contextmanager` and `asynccontextmanager` in contextlib already along with 
`closing` / `aclosing`, `ExitStack` / `AsyncExitStack` etc.

`async_lru_cache` should have the same arguments as accepted by `lru_cache` but 
work with async functions.

I think this function should be a part of stdlib because the implementation 
shares *internal* `_lru_cache_wrapper` that does all dirty jobs (and has C 
accelerator). A third-party library should either copy all these implementation 
details or import a private function from stdlib and keep fingers crossed in 
hope that the private API will keep backward compatibility in future Python 
versions.

Similar reasons were applied to contextlib async APIs.

Third parties can have different features (time-to-live, expiration events, 
etc., etc.) and can be async-framework specific (work with asyncio or trio 
only) -- I don't care about these extensions here.

My point is: stdlib has built-in lru cache support, I love it. Let's add 
exactly the as we have already for sync functions but for async ones.

--

___
Python tracker 

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

[issue46622] Add an async variant of lru_cache for coroutines.

[Tzu-ping Chung]

Tzu-ping Chung  added the comment:

Another thing to point out is that existing third-party solutions (both 
alru_cache and cached_property) only work for asyncio, and the stdlib version 
(as implemented now) will be an improvement. And if the position is that the 
improvements should only be submitted to third-party solutions---I would need 
to disagree since both lru_cache and cached_property have third-party solutions 
predating their stdlib implementations, and it is double-standard IMO if an 
async solution is kept out while the sync version is kept in.

--

___
Python tracker 

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

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29651
pull_request: https://github.com/python/cpython/pull/31527

___
Python tracker 

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

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

STINNER Victor  added the comment:

> Include/object.h:109:3: warning: redefinition of typedef 'PyObject' is a C11 
> feature [-Wtypedef-redefinition]

Oh. I already met this error :-(

That's why I proposed in GH-31201 to move all forward declarations at the top 
of Python.h to solve such issue.

I wrote GH-31527 to do exactly that: add a new pytypedefs.h header files to 
move all forward declarations at the top of Python.h.

I didn't move *all* "typedef struct xxx yyy;" there: only the ones which cause 
interdependencies issues.

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

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29652
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/31528

___
Python tracker 

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

[issue46833] Installer Wizard is unclear and has redundant settings

[Steve Dower]

Steve Dower  added the comment:

> I am not sure but would say that the first two options are related to the 
> py-launcher not the the python interpreter itself.

You correctly read the options, so we'll need a suggestion on how to make it 
more clear without becoming impenetrable. Maybe changing the third one to say 
"Install Python for all users" would suffice?

Possibly we should link to the install docs from the front page for people who 
want more help.

> OK, but why two options?

The py.exe launcher is totally separate from the version of Python you're 
installing, and if you previously installed it for all users (including if you 
previously installed Python 3.4 or earlier), you have to install it for all 
users again or it won't work.

The option is on the front page so that non-admins can easily disable it and 
still install everything.

> This appears on the first page ("Add Python 3.9 to PATH") and on the third 
> page ("Add Python to environment variables").

So that users can change it without having to go through the advanced install. 
This is the most common option to enable, even though we recommend against it 
unless you know what you're doing, so putting it on the front page saves _many_ 
users from having to go through all the other pages.

> all this options are not synchronized

That sound like a bug. And I can't reproduce it, so we might need more info.

If you go through setup a few times (without ever actually installing) and 
fiddle with the options, it will still produce a log file in %TEMP% that should 
explain which settings were modified, so we can see why they may not be 
updating in the UI for you.

--

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Chris Jerdonek]

Chris Jerdonek  added the comment:

For future reference, with Andrew's change merged above, the traceback for the 
example snippet in my message above:
https://bugs.python.org/issue45390#msg403570
is now the following. Observe that (1) the call to sleep() continues to be 
present, but (2) without introducing two new intermediate CancelledErrors, 
which increase the verbosity of the traceback:

Traceback (most recent call last):
  File "/home/andrew/projects/cpython/exc_traceback.py", line 14, in 
asyncio.run(main())
^^^
  File "/home/andrew/projects/cpython/Lib/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
   ^
  File "/home/andrew/projects/cpython/Lib/asyncio/base_events.py", line 640, in 
run_until_complete
return future.result()
   ^^^
  File "/home/andrew/projects/cpython/exc_traceback.py", line 11, in main
await task
^^
  File "/home/andrew/projects/cpython/exc_traceback.py", line 5, in job
await asyncio.sleep(5)
^^
  File "/home/andrew/projects/cpython/Lib/asyncio/tasks.py", line 619, in sleep
return await future
   
asyncio.exceptions.CancelledError: cancel job

(This is copied from Andrew's comment in the PR here:
https://github.com/python/cpython/pull/31383#issuecomment-1046822899 )

Serhiy, can you provide a sample snippet for your case with output, like I did 
in my message linked above?

--

___
Python tracker 

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

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

[Ofey Chan]

Change by Ofey Chan :


--
keywords: +patch
pull_requests: +29653
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/31529

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

New submission from STINNER Victor :

I propose to move the PyFrameObject structure to the internal C API.


--


Between Python 3.10 and Python 3.11, the work on optimizing ceval.c modified 
deeply the PyFrameObject structure. Examples:

* The f_code member has been removed by in bpo-44032 by the commit 
b11a951f16f0603d98de24fee5c023df83ea552c.
* The f_frame member has been added in bpo-44590 by the commit 
ae0a2b756255629140efcbe57fc2e714f0267aa3.

Most members have been moved to a new PyFrameObject.f_frame member which has 
the type "struct _interpreter_frame*". Problem: this type is only part of the 
*internal* C API.

Moreover, accessing the few remaining members which "didn't change" became 
dangerous. For example, f_back can be NULL even if the frame has a previous 
frame: the PyFrame_GetBack() function *must* now be called. See bpo-46356 "[C 
API] Enforce usage of PyFrame_GetBack()".

Reading directly f_lineno was already dangerous since Python 2.3: the value is 
only valid if the value is greater than 0. It's way safer to use the clean 
PyFrame_GetLineNumber() API instead.

PyFrame_GetBack() was added to Python 3.9. You can use the pythoncapi_compat 
project to get this function on Python 3.8 and older:

=> https://pythoncapi-compat.readthedocs.io/

PyFrame_GetLineNumber() was added to the limited API in Python 3.10.

=> Documentation: 
https://docs.python.org/dev/c-api/reflection.html#c.PyFrame_GetBack


--


There *are* projects accessing directly PyFrameObject like the gevent project 
which sets the f_code member (moved to f_frame.f_code in Python 3.11). It's 
broken on Python 3.11:
https://bugs.python.org/issue40421#msg413719

Debuggers and profilers also want to read PyFrameObject directly. IMO for these 
*specific* use cases, using the *internal* C API is a legit use case and it's 
fine.

Moving PyFrameObject to the internal C API would clarify the situation. 
Currently, What's New in Python 3.11 documents the change this with warning:

"While the documentation notes that the fields of PyFrameObject are subject to 
change at any time, they have been stable for a long time and were used in 
several popular extensions. "


--


I'm mostly worried about Cython which still get and set many PyFrameObject 
members directly (ex: f_lasti, f_lineno, f_localsplus, f_trace), since there 
are no public functions for that.

=> https://bugs.python.org/issue40421#msg367550

Right now, I would suggest Cython to use the internal C API, and *later* 
consider adding new getter and setter functions. I don't think that we can 
solve all problems at once: it takes take to design clean API and use them in 
Cython.

Python 3.11 already broke Cython since most PyFrameObject members moved into 
the new "internal" PyFrameObject.f_frame API which requires using the internal 
C API to get "struct _interpreter_frame".

=> https://github.com/cython/cython/issues/4500


--


Using a frame using the *public* C API was and remains supported. Short example:
--
PyThreadState *tstate = PyThreadState_Get();
PyFrameObject* frame = PyThreadState_GetFrame(tstate);
int lineno = PyFrame_GetLineNumber(frame);
---

The PyFrameObject structure is opaque and members are not accessed directly: 
it's fine.

--
components: C API
messages: 413795
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Move PyFrameObject to the internal C API
versions: Python 3.11

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

By the way, Include/cpython/ceval.h uses the "struct _interpreter_frame*" type 
whereas this type is part of the internal C API:

PyAPI_FUNC(PyObject *) _PyEval_EvalFrameDefault(PyThreadState *tstate, struct 
_interpreter_frame *f, int exc);

Maybe we should move this defintion to the internal C API pycore_ceval.h.

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

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

[issue44590] Create frame objects lazily when needed

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--
nosy: +vstinner

___
Python tracker 

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

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

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

[issue44032] Function locals and evaluation stack should be stored in a contiguous, per-thread stack

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-40421 "[C API] Add getter functions for PyFrameObject and maybe 
move PyFrameObject to the internal C API". I added getter functions in recent 
Python versions:

* PyFrame_GetBack(): Python 3.9
* PyFrame_GetCode(): Python 3.9
* PyFrame_GetLineNumber() added to the limited C API version 3.10

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-44800 "Code readability: rename InterpreterFrame to _Py_framedata".

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-45247: [C API] Add explicit support for Cython to the C API.

--

___
Python tracker 

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

[issue45247] [C API] Add explicit support for Cython to the C API

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

I marked my PR as a draft since this change is an incompatible change. Even if 
PyFrameObject structure is excluded from the limited C API and not documented, 
it's used by a few projects. I plan to check how this change impacts these 
projects before merging the change.

For example, test this change on:

* Cython: https://github.com/cython/cython/issues/4500
* gevent: https://github.com/gevent/gevent/issues/1867
* coverage uses f_lasti: https://bugs.python.org/issue40421#msg403814

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +Mark.Shannon, corona10, erlendaasland, petr.viktorin, scoder

___
Python tracker 

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

[issue45184] Add `pop` function to remove context manager from (Async)ExitStack

[Andreas H.]

Andreas H.  added the comment:

Inside the discussion an ExitPool class is sketched 
(https://mail.python.org/archives/list/python-id...@python.org/message/66W55FRCYMYF73TVMDMWDLVIZK4ZDHPD/),
 which provides this removal of context managers.

What I learned is that this would have different cleanup mode (atexit style), 
as compared to present ExitStack cleanup (nested style). 

So contrary to what I was originally thinking ExitPool functionality would be 
close to, but not a strict superset of ExitStack functionality. Still such an 
ExitPool functionality would be extremely useful.

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

See also the bpo-39947: "[C API] Make the PyThreadState structure opaque (move 
it to the internal C API)". Recently, I also added helper functions:

* PyThreadState_GetFrame(): Python 3.9 and limited C API version 3.10
* PyThreadState_GetID(): Python 3.9 and limited C API version 3.10
* PyThreadState_GetInterpreter(): Python 3.9 and limited C API version 3.10
* PyThreadState_EnterTracing(), PyThreadState_LeaveTracing(): Python 3.11

See also pending GH-29121 of bpo-39947: "Add PyThreadState_SetTrace() function".

--

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Serhiy is right, Condition.wait() has the following code:

finally:
# Must reacquire lock even if wait is cancelled
cancelled = False
while True:
try:
await self.acquire()
break
except exceptions.CancelledError:
cancelled = True

if cancelled:
raise exceptions.CancelledError

It swallows CancelledError exceptions from waiters and re-raises CancelledError 
without the cancellation message.

--

___
Python tracker 

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

[issue46833] Installer Wizard is unclear and has redundant settings

[Christian Buhtz]

Christian Buhtz  added the comment:

Thank you very much for your quick replay and for taking my problems and 
thoughts into account.

I have to dive deeper into the topic but still have some ideas how to re-design 
the wizard.

IMHO the primary problem is that on the first page the decision between 
"normal" and "advanced" is mixed with the settings for "normal".

--

___
Python tracker 

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

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46836: "[C API] Move PyFrameObject to the internal C API".

--

___
Python tracker 

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

[issue46813] Allow developer to resize the dictionary

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm going to close this one.  Making a new and previously rejected extension to 
one of Python's most import APIs requires broad discussion and buy-in.  If you 
really want to push for this, please take it to the python-ideas list.

--
resolution:  -> rejected
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

[issue45107] Improve LOAD_METHOD specialization

[Mark Shannon]

Change by Mark Shannon :


--
nosy: +Mark.Shannon
nosy_count: 1.0 -> 2.0
pull_requests: +29655
pull_request: https://github.com/python/cpython/pull/31531

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I have no good simple real-case scenario, sorry. 

There is a demonstration of my thoughts.

Suppose we have a custom context manager that behaves similar to timeout() but 
is controlled not by timer but external event source (it could be an 
invalidation message sent by a distributed broker or something else).


class EventRaised(Exception):
pass

class CancelOnEvent:
async def __init__(self, event):
self.event = event

async def __aenter__(self):
self.waiter = asyncio.task(self._cancel_on_event, 
asyncio.current_task())

async def __aexit__(self, exc_typ, ecx_val, exc_tb):
if exc_typ is asyncio.CancelledError:
if CASE1:  # <<< cleanup strategy selector
if asyncio.current_task().uncancel() == 0:
raise EventRaised
else:
if self.event.is_set():
raise EventRaised

async def _cancel_on_event(self, task):
await self.event.wait()
task.cancel()

###
event = asyncio.Event()

async with asyncio.timeout(1):  # what exception should bubble-up here?
async with CancelOnEvent(event):
await asyncio.sleep(10)  # event.set() is called here after 1 sec 
timeout

If this CancelOnEvent context manager is used together with timeout() CM, is 
the behavior clear? Should `.uncancel()` be used by CancelOnEvent? Why? How 
should it interact with timeout()?
I have no clear and obvious answer on these questions, this worries me.

--

___
Python tracker 

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

[issue46806] Overlapping PYTHONPATH may cause import already imported module

[Eric Snow]

Eric Snow  added the comment:

FYI, a technical solution has been discussed before: bpo-13475 and PEP 395.  
However, that does not help so much if the default behavior isn't changed.  
That would require a PEP but I expect it would be rejected because so many 
scripts already rely on the current behavior and the current behavior is useful 
in some cases.

PEP 395 also has a good discussion of the various pitfalls related to 
sys.path[0] initialization.  Furthermore, the topic is discussed in quite a few 
issues, such as bpo-44132 and bpo-29929.

Probably the best use of your time on this would be to improve the 
documentation so people will more easily avoid the problem, or at least more 
easily diagnose the situation when they stumble on it.  Again, PEP 395 is a 
good guide for this.

--

___
Python tracker 

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

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

[Ofey Chan]

Ofey Chan  added the comment:

I fix the problem.

But sorry for my last message, because it totally miss the point ;)

In `inspect.signature()`, the order of handle `follow_wrapper_chains` and 
`functools.partial` cause the problem.

Relevant code: 
https://github.com/python/cpython/blob/288af845a32fd2a92e3b49738faf8f2de6a7bf7c/Lib/inspect.py#L2408

The original order is:

1. `follow_wrapper_chains` unwrap decorators.
   - It would check `__wrapped__` attribute in `unwrap()`.
   - `functools.update_wrapper()` would set `__wrapped__`.
2. Then handle `functools.partial`, construct new signature with 
`_signature_get_partial()`

So the original `functools.partial` object would skip (1), goto (2) and would 
be correctly processed.

But after calling `functools.update_wrapper()`, the `functools.partial` object 
has a `__wrapped__` attribute, so it directly handled by (1) and will never 
reach (2). That's why `inspect.signature()` return the original function's 
signature.

`update_wrapper.breaks.partial.signature.check.__wrapped__.py` shows the 
`__wrapped__` attribute.

My solution is simple: swap the order of (1) and (2).

`functools.partial` is a special type of wrapper, handle it before going down 
the wrapper chain is sane.

And I have written test case to ensure it's correct, hope it works.

--

___
Python tracker 

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

[issue46835] ImportError: bad magic number in ... does not indicate where is that file located

[Petr Viktorin]

Petr Viktorin  added the comment:

I assume a PR review should be enough.

--
components: +Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

[Ofey Chan]

Change by Ofey Chan :


Added file: 
https://bugs.python.org/file50639/update_wrapper.breaks.partial.signature.check.__wrapped__.py

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29656
pull_request: https://github.com/python/cpython/pull/31532

___
Python tracker 

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

[issue46356] [C API] Enforce usage of PyFrame_GetBack()

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue46736] Generate HTML 5 with SimpleHTTPRequestHandler.list_directory

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue43311] bpo-43311: PyInterpreterState_New use thread-specific data tstate before key create .

[STINNER Victor]

Change by STINNER Victor :


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

[issue46622] Add an async variant of lru_cache for coroutines.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think that it would be simpler to add a decorator which wraps the result of 
an asynchronous function into an object which can be awaited more than once:

def reawaitable(func):
@wraps(func)
def wrapper(*args, **kwargs):
return CachedAwaitable(func(*args, **kwargs))
return wrapper

It can be combined with lru_cache and cached_property any third-party caching 
decorator. No access to internals of the cache is needed.

@lru_cache()
@reawaitable
async def coro(...):
...

@cached_property
@reawaitable
async def prop(self):
...

--

___
Python tracker 

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

[issue46829] Confusing CancelError message if multiple cancellations are scheduled

[Guido van Rossum]

Guido van Rossum  added the comment:

But that example is made-up. Is there a real-world situation where you need to 
know the call site, and it wouldn't be obvious from other log messages?

Directly cancelling a task without also somehow catching the cancellation (like 
in the timeout or task group cases) feels like an odd practice to me.

And passing the cancel message through is complex (as we've seen in recent PRs).

--

___
Python tracker 

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

[issue46833] Installer Wizard is unclear and has redundant settings

[Christian Buhtz]

Christian Buhtz  added the comment:

In the attachment you will find a PDF with variants A to D on each side.

I tried to think into the design decisions made by the team who created the 
current installer. I am not sure of course but I tried to take this (assumed) 
decisions into account.

Variant A:
This is nearest to the current release version.
 - The settings on page 1 are moved onto that page directly to the bottom of 
"Install Now" and before(!) "Customize installation".
 - The "all users" option is now available for the interpreter and launcher.
Modifying the position of the two checkboxes make‘s it more clear to which 
decision way (simple or customized/advanced installation) they belong.

Variant B:
The same as A but Page 2 and 3 (from A) are joined together. If there is enough 
room on the wizard dialog this would be OK. But very important is to visually 
separate the two sections "Interpreter" and "Launcher" on that one dialog. You 
could do that with bigger bold text like headings or you could use a horizontal 
bar.

Variant C (would be my second favourite):
Page 1 is more minimal. The user only have to make a decision between simple 
installation and advanced/customize installation.

Variant D (my favourite):
Page one offers the simple options about "PATH" and "all users" for interpreter 
and launcher. This should be separated in a visual way of course.
btw: From a technical point of view I do not see an advantage of separating the 
decision about "PATH" and "all users" between python and py. I would assume if 
py should goes to PATH and installed for "all users" the interpreter should 
treated the same.
More important on D is that the way to the "advanced" (currently named 
"customize") installation way is "hidden" behind a simple GUI button. A lot of 
other installers doing it the same way. It is just a simple button. Not big, no 
special colours or something like that. The page 1 of the current release 
version of the installer is to much bling-bling. ;)

Some more Notes and Thoughts

„Customize“ is not a good term, because it is still possible to „customize“ the 
installation on that first page (the two check boxes on the bottom) without 
clicking „Customize installation“ and
When clicking on „Customize installation“ the next (2nd) page is named 
„Optional Features“ which is different from „Customization“. I would suggest 
"Advanced" or "Expert".
It is similar with “Advanced” on page 3. What is the difference between 
“Advanced” and “Customize”?

Add a „What is the py launcher for“ link to the wizard.

Add a „What is pip launcher for“ link to the wizard.

In the What-for-pages: Do not describe what py/pip can do but describe what the 
user can do with it. Modify the perspectives/view points! I would help you to 
review this texts.

Use horizontal bars in the GUI to better visualise the separate ways/topics. 
E.g. in Variant B on page 2.

I have some more detailed suggestions about modified wording. But I think at 
this point it is enough. :)

--
Added file: https://bugs.python.org/file50640/py_installer.pdf

___
Python tracker 

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

[issue46736] Generate HTML 5 with SimpleHTTPRequestHandler.list_directory

[Dong-hee Na]

Change by Dong-hee Na :


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

___
Python tracker 

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

[issue46622] Add an async variant of lru_cache for coroutines.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

async_lru_cache() and async_cached_property() can be written using that 
decorator. The implementation of async_lru_cache() is complicated because the 
interface of lru_cache() is complicated. But it is simpler than using 
_lru_cache_wrapper().

def async_lru_cache(maxsize=128, typed=False):
if callable(maxsize) and isinstance(typed, bool):
user_function, maxsize = maxsize, 128
return lru_cache(maxsize, typed)(reawaitable(user_function))

def decorating_function(user_function):
return lru_cache(maxsize, typed)(reawaitable(user_function))

return decorating_function

def async_cached_property(user_function):
return cached_property(reawaitable(user_function))

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

To make this cleanly interact with timeout, TaskGroup etc., the CancelOnEvent 
class should have a "did-I-cancel" flag which is set in the _cancel_on_event() 
callback. Then if that flag is set it should call .uncancel(), and if that 
returns a value > 0, it should bubble the CancelledError out; otherwise it can 
raise EventRaised (if the condition is set).

--

___
Python tracker 

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

[issue46829] Confusing CancelError message if multiple cancellations are scheduled

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For reference, the msg parameter of Task.cancel() was added in issue31033.

It seems that the initial use case was for debugging. I do not see how it 
differs from the following example:

r = random.random()
if r < 0.5:
x = 0
else:
x = 0
1/x

In the traceback we see the line where an error occurred but we do not see a 
line which lead to this error.

--

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset c0a5ebeb1239020f2ecc199053bb1a70d78841a1 by Kumar Aditya in 
> branch 'main':
> bpo-46430: Intern strings in deep-frozen modules  (GH-30683)

This change introduced a memory leak at Python exit.

Before:

$ ./python -X showrefcount -c pass
[0 refs, 0 blocks]

After:

$ ./python -X showrefcount -c pass
[0 refs, 344 blocks]

--
nosy: +vstinner

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> This change introduced a memory leak at Python exit.

It's regression related to bpo-1635741 which I fixed recently:
https://mail.python.org/archives/list/python-...@python.org/thread/E4C6TDNVDPDNNP73HTGHN5W42LGAE22F/

--

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

_PyStaticCode_InternStrings() error handling is based on assert(): that's 
really bad. It can crash Python (exit with abort()) at the first memory 
allocation failure. Why not returning -1 on error?

--

___
Python tracker 

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

[issue46668] encodings: the "mbcs" alias doesn't work

[STINNER Victor]

STINNER Victor  added the comment:

commit ccbe8045faf6e63d36229ea4e1b9298572cda126
Author: Victor Stinner 
Date:   Tue Feb 22 22:04:07 2022 +0100

bpo-46659: Fix the MBCS codec alias on Windows (GH-31218)

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

[issue45412] [C API] Remove Py_OVERFLOWED(), Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9bbdde218005f552304d9954bb97e3f9185edded by Victor Stinner in 
branch 'main':
bpo-45412: Add _PY_SHORT_FLOAT_REPR macro (GH-31171)
https://github.com/python/cpython/commit/9bbdde218005f552304d9954bb97e3f9185edded


--

___
Python tracker 

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

[issue45412] [C API] Remove Py_OVERFLOWED(), Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-46670: "Build Python with -Wundef: don't use undefined macros".

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[Petr Viktorin]

Petr Viktorin  added the comment:

So, this will break Cython and gevent, but (unlike the optimization work that 
broke f_code/f_frame) it won't provide any value to users?

I don't see how that's a good idea.

--

___
Python tracker 

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

[issue46836] [C API] Move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

Petr Viktorin:
> So, this will break Cython and gevent,

This change doesn't break Cython and gevent: they are already broken.


> but (unlike the optimization work that broke f_code/f_frame) it won't provide 
> any value to users?

The problem is that the C API changed silently: existing code which gets 
directly PyFrameObject.f_back still compiles successfully, but it will no 
longer work in some cases.

See bpo-46356 "[C API] Enforce usage of PyFrame_GetBack()" for more details.

The intent of moving the structure to the internal C API is to clarify its 
status: we provide no backward compatibility warranty, you are on our own if 
you use it.

It's also a way to promote the usage of the new clean public C API: it is now 
reliable, whereas accessing directly PyFrameObject members break at each Python 
version.

The internal C API cannot be used easily on purpose: you have to opt-in for 
this API by defining the Py_BUILD_CORE_MODULE macro and you need to use 
different #include. It's a way to enforce the usage of the clean public C API.

--

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Also Future.result() and Future.exception() can raise a CancelledError. So a 
CancelledError raised in a task may not contain a message passed to 
Task.cancel().

import asyncio
import random

async def main():
fut = asyncio.Future()
fut.cancel()
async def job():
if random.random() < 0.5:
await asyncio.sleep(2)
fut.result()
await asyncio.sleep(5)
task = asyncio.create_task(job())
await asyncio.sleep(1)
task.cancel("cancel task")
await task

asyncio.run(main())

You need to catch a CancelledError raised in a coroutine and re-raise a new 
CancelledError with the specified cancel message if the task was cancelled.

--

___
Python tracker 

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

[issue46837] lstrip and strip not working as expected

[Jigar Gajjar]

New submission from Jigar Gajjar :

Code:

my_string = 'Auth:AWS'
print(my_string.lstrip('Auth:'))


Actual Output:

WS

Excepted Output:

AWS

--
messages: 413831
nosy: jigar030
priority: normal
severity: normal
status: open
title: lstrip and strip not working as expected
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

[issue46837] lstrip and strip not working as expected

[Jigar Gajjar]

Change by Jigar Gajjar :


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

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

Okay, let's change the error handling. @Kumar, can you handle that?

@Victor, the refleak is unrelated to the error handling right? Presumably the 
leak is imaginary -- the deep-frozen interned strings should be accounted for 
somehow. @Kumar do you need help investigating this?

--

___
Python tracker 

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

[issue46835] ImportError: bad magic number in ... does not indicate where is that file located

[Miro Hrončok]

Change by Miro Hrončok :


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

___
Python tracker 

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

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

[Larry Hastings]

Larry Hastings  added the comment:

Ofey, I appreciate your enthusiasm, but you should probably slow down.  Fixing 
the bug is probably going to be the easy part here.  But we're not to that 
stage quite yet.  First, we need to determine

* why the code behaves like this--is this behavior a genuine bug, or is it 
actually a bugfix for some worse behavior?
* will fixing the bug cause problems for Python users? and if so, can we still 
fix the bug while mitigating the damage to people who are unfortunately 
depending on the bug?

The next step is not to write a bugfix for this exact behavior, it's to 
determine why the code is the way it is.  If it was genuinely just a mistake, 
and we can simply fix it and people will thank us, then we may have a use for 
your patch.  But, generally, people who work on Python are smart, and they 
don't tend to commit dumb mistakes, so we can't simply assume it's a simple bug 
and fix it.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Yves Duprat]

Change by Yves Duprat :


--
nosy: +yduprat

___
Python tracker 

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

[issue46736] Generate HTML 5 with SimpleHTTPRequestHandler.list_directory

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 0bb40a42d71873ea267aace8c92a02d66fe36dc2 by Dong-hee Na in branch 
'main':
closes bpo-46736: SimpleHTTPRequestHandler now uses HTML5. (GH-31533)
https://github.com/python/cpython/commit/0bb40a42d71873ea267aace8c92a02d66fe36dc2


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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29659
pull_request: https://github.com/python/cpython/pull/31535

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

> The docs for PyFrame_GetCode say it's returning an "int". 

Oh. I  missed your comment. I created GH-31535 to fix the return type in the 
documentation.

--

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Thomas Grainger]

Thomas Grainger  added the comment:

there could be multiple messages here

perhaps it could be:

```
finally:
# Must reacquire lock even if wait is cancelled
cancelled = []
while True:
try:
await self.acquire()
break
except exceptions.CancelledError as e:
cancelled.append(e)

if len(cancelled) > 1:
raise ExceptionGroup("Cancelled", cancelled)
if cancelled:
raise cancelled[0]
```

--

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> Presumably the leak is imaginary

Well, you can check with your favorite memory debugger like Valgrind if you 
don't trust Python internal memory debugger :-)

Not leaking memory at exit matters when Python is embedded in an application.

I don't think that it's related to the error handling which is stripped in 
release mode.

--

___
Python tracker 

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

[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.

[Guido van Rossum]

Guido van Rossum  added the comment:

We should really stop appending to a closed issue.

Anyway, raising ExceptionGroup is backwards incompatible, since "except 
CancelledError" wouldn't cancel the group.

--

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[Guido van Rossum]

Guido van Rossum  added the comment:

> Not leaking memory at exit matters when Python is embedded
> in an application.

Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the 
deep-frozen memory -- the solution must be to update the accounting somewhere.

Where is the existence of Py_None accounted for (since it's statically 
allocated, or at least used to be)? That's likely where we'd have to do 
something about the deep-frozen objects.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Clear, thanks!

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

I will now merge GH-31513 (cancel counts). Once that's in you can merge main 
into your timeout PR (GH-31394) and then that can land soon (I'd like to review 
it once more).

--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

Ned Batchelder:
> I went ahead and changed the coverage.py code to this: (...)

I proposed a coverage PR using PyObject_GetAttrString(frame, "f_lasti") which 
should works on all Python versions:
https://github.com/nedbat/coveragepy/pull/1331

--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29660
pull_request: https://github.com/python/cpython/pull/31536

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

Mark Shannon:
> The only purpose of `f_lasti` is to get the line number and that can be done 
> directly via `PyFrame_GetLineNumber(PyFrameObject *frame)`

I found the uwsgi project on PyPI which uses f_lasti with PyCode_Addr2Line(). I 
wrote GH-31536 to suggest using PyFrame_GetLineNumber() in What's New in Python 
3.11.

--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:

> I found the uwsgi project on PyPI which uses f_lasti with PyCode_Addr2Line().

Oh, plugins/python/profiler.c uses that to define PyFrame_GetLineNumber() on 
Python older than 2.7, Python 3.0 and Python 3.1. In 2022, it's no longer 
relevant.

But well, there might be other code in the wild using PyCode_Addr2Line() with 
f_lasti, so IMO it's worth it to document the suggestion ;-)

--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +29661
pull_request: https://github.com/python/cpython/pull/31537

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 78859e58e4e016286e648d1dc155e0f6cebfa6ff by Victor Stinner in 
branch 'main':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/78859e58e4e016286e648d1dc155e0f6cebfa6ff


--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[miss-islington]

Change by miss-islington :


--
pull_requests: +29662
pull_request: https://github.com/python/cpython/pull/31538

___
Python tracker 

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

[issue44337] Port LOAD_ATTR to adaptive interpreter

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset 281ea9c39146a00cdf3fa2b3d0be60e2a39278ce by Brandt Bucher in 
branch 'main':
bpo-44337: Shrink the LOAD_ATTR/STORE_ATTR caches (GH-31517)
https://github.com/python/cpython/commit/281ea9c39146a00cdf3fa2b3d0be60e2a39278ce


--

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[STINNER Victor]

STINNER Victor  added the comment:

> Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the 
> deep-frozen memory -- the solution must be to update the accounting somewhere.

Python allocates memory (ex: with PyObject_Malloc()) which is not released at 
exit. Two examples from Valgrind:

==196803== 50 bytes in 1 blocks are still reachable in loss record 1 of 87
==196803==at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==by 0x58C4CF: get_latin1_char (unicodeobject.c:2148)
==196803==by 0x58D7F7: _PyUnicode_FromUCS1 (unicodeobject.c:2450)
==196803==by 0x58E374: PyUnicode_FromKindAndData (unicodeobject.c:2525)
==196803==by 0x69402B: r_object (marshal.c:1150)
==196803==by 0x694295: r_object (marshal.c:1212)
==196803==by 0x694AE0: r_object (marshal.c:1393)
==196803==by 0x694295: r_object (marshal.c:1212)
==196803==by 0x694AA4: r_object (marshal.c:1387)
==196803==by 0x6950F3: read_object (marshal.c:1524)
==196803==by 0x6953E7: PyMarshal_ReadObjectFromString (marshal.c:1641)
==196803==by 0x763223: _Py_Get_Getpath_CodeObject (getpath.c:792)
==196803==by 0x76337F: _PyConfig_InitPathConfig (getpath.c:847)
==196803==by 0x68CD04: config_init_import (initconfig.c:1967)
==196803==by 0x68CE4E: _PyConfig_InitImportConfig (initconfig.c:2000)
==196803==by 0x69E594: init_interp_main (pylifecycle.c:1103)
==196803==by 0x69EBF8: pyinit_main (pylifecycle.c:1216)
==196803==by 0x69EDCE: Py_InitializeFromConfig (pylifecycle.c:1247)
==196803==by 0x6D5346: pymain_init (main.c:67)
==196803==by 0x6D64F8: pymain_main (main.c:692)
==196803==by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==by 0x41D7B5: main (python.c:15)

and

==196803== 3,336 bytes in 60 blocks are still reachable in loss record 87 of 87
==196803==at 0x484486F: malloc (vg_replace_malloc.c:381)
==196803==by 0x544E29: _PyMem_RawMalloc (obmalloc.c:101)
==196803==by 0x545E0E: PyObject_Malloc (obmalloc.c:700)
==196803==by 0x587159: PyUnicode_New (unicodeobject.c:1448)
==196803==by 0x59AEB9: unicode_decode_utf8 (unicodeobject.c:5162)
==196803==by 0x59B5B0: PyUnicode_DecodeUTF8Stateful (unicodeobject.c:5292)
==196803==by 0x58D296: PyUnicode_FromString (unicodeobject.c:2322)
==196803==by 0x5CFFAE: PyUnicode_InternFromString (unicodeobject.c:15650)
==196803==by 0x4E8B61: descr_new (descrobject.c:885)
==196803==by 0x4E8C9B: PyDescr_NewMethod (descrobject.c:934)
==196803==by 0x56694C: type_add_method (typeobject.c:5643)
==196803==by 0x566A92: type_add_methods (typeobject.c:5689)
==196803==by 0x569166: type_ready_fill_dict (typeobject.c:6165)
==196803==by 0x569A02: type_ready (typeobject.c:6421)
==196803==by 0x569B59: PyType_Ready (typeobject.c:6457)
==196803==by 0x544363: _PyTypes_InitTypes (object.c:1952)
==196803==by 0x69D12D: pycore_init_types (pylifecycle.c:704)
==196803==by 0x69D8FC: pycore_interp_init (pylifecycle.c:831)
==196803==by 0x69DC31: pyinit_config (pylifecycle.c:887)
==196803==by 0x69E355: pyinit_core (pylifecycle.c:1050)
==196803==by 0x69ED32: Py_InitializeFromConfig (pylifecycle.c:1240)
==196803==by 0x6D5346: pymain_init (main.c:67)
==196803==by 0x6D64F8: pymain_main (main.c:692)
==196803==by 0x6D65A1: Py_BytesMain (main.c:725)
==196803==by 0x41D7B5: main (python.c:15)

Before the commit c0a5ebeb1239020f2ecc199053bb1a70d78841a1, Python didn't leak 
this memory.

--

___
Python tracker 

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

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue45107] Improve LOAD_METHOD specialization

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue46823] Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[miss-islington]

miss-islington  added the comment:


New changeset b0de6299a840a397d4fe3e6c98159d9f258d3295 by Miss Islington (bot) 
in branch '3.10':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/b0de6299a840a397d4fe3e6c98159d9f258d3295


--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[miss-islington]

miss-islington  added the comment:


New changeset 763e23e11e785162f9d68f83539404af8e863748 by Miss Islington (bot) 
in branch '3.9':
bpo-40421: Fix PyFrame_GetCode() documentation (GH-31535)
https://github.com/python/cpython/commit/763e23e11e785162f9d68f83539404af8e863748


--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8a716bc62c8205bb9deeda17422b7e69204b6897 by Victor Stinner in 
branch 'main':
bpo-40421: What's New in Python 3.11: PyFrameObject.f_lasti (GH-31536)
https://github.com/python/cpython/commit/8a716bc62c8205bb9deeda17422b7e69204b6897


--

___
Python tracker 

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

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29663
pull_request: https://github.com/python/cpython/pull/31539

___
Python tracker 

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