[issue46652] Use code.co_qualname to provide richer information
Gabriele N Tornetta added the comment: code.co_qualname was introduced in 2021 with bpo-44530 and shuold give the same guarantees as code.co_name. The __qualname__ attribute is derived from code.co_qualname, so perhaps Cython can benefit from accessing code.co_qualname directly instead? -- ___ Python tracker <https://bugs.python.org/issue46652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46652] Use code.co_qualname to provide richer information
Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +29327 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31150 ___ Python tracker <https://bugs.python.org/issue46652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46652] Use code.co_qualname to provide richer information
New submission from Gabriele N Tornetta :
https://bugs.python.org/issue44530 introduced the co_qualname field to code
objects. This could be used to, e.g. enrich the information provided by
tracebacks. Consider this simple example
~~~ python
import traceback
class Bogus:
def __init__(self):
traceback.print_stack()
raise RuntimeError("Oh no!")
class Foo:
def __init__(self):
Bogus()
Foo()
~~~
The current output is
~~~
❯ python3.10 test_tb_format.py
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in
Foo()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
Bogus()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in __init__
traceback.print_stack()
Traceback (most recent call last):
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in
Foo()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
Bogus()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in __init__
raise RuntimeError("Oh no!")
RuntimeError: Oh no!
~~~
The proposed change is to use the co_qualname field instead of co_name to
provide more immediate information about the distinct functions __init__, viz.
~~~
❯ ./python test_tb_format.py
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in
Foo()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in
Foo.__init__
Bogus()
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in
Bogus.__init__
traceback.print_stack()
Traceback (most recent call last):
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in
Foo()
^
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in
Foo.__init__
Bogus()
^^^
File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in
Bogus.__init__
raise RuntimeError("Oh no!")
RuntimeError: Oh no!
~~~
This makes it clear that two distinct __init__ functions are involved, without
having to look at sources.
--
components: Interpreter Core
messages: 412598
nosy: Gabriele Tornetta, pablogsal
priority: normal
severity: normal
status: open
title: Use code.co_qualname to provide richer information
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46652>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46649] Propagate Python thread name to thread state structure
Gabriele N Tornetta added the comment: Thanks for mentioning that issue, it didn't come up in my search for a similar one. Indeed, with the proposals in bpo-15500 implemented, and the fact that native_thread_id is already in PyThreadState, retrieving the name should be easy and might make for a better implementation than what I'm proposing. Furthermore, doing this at the OS level would benefit an even larger set of tools. What pushed me to open this issue is the fact that this feature has been lacking for quite some time (indeed bpo-15500 dates back to 2012!), so I thought I'd propose a different approach in case it would get a quicker resolution this way. -- ___ Python tracker <https://bugs.python.org/issue46649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46649] Propagate Python thread name to thread state structure
Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +29319 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31142 ___ Python tracker <https://bugs.python.org/issue46649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46649] Propagate Python thread name to thread state structure
New submission from Gabriele N Tornetta : For tools like Austin (https://github.com/P403n1x87/austin) it is currently quite challenging to derive the name of a thread based on the information exposed by the PyThreadState structure and one stored in threading._active. I would like to propose propagating the thread name from the Thread object to the PyThreadState structure so that profiling information from tools like Austin could easily be enriched with the names of each sampled thread. -- components: C API messages: 412569 nosy: Gabriele Tornetta priority: normal severity: normal status: open title: Propagate Python thread name to thread state structure type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Gabriele N Tornetta added the comment: @rhettinger Apologies. You're totally right but I wasn't expecting this to become a lengthy conversation. So, to get closer to the initial issue, I believe that this ticket could be closed provided that the documentation is improved by making developers aware of the potential side effects of isinstance. I was doing some more experiments and it looks like def _isinstance(obj, classinfo): return issubclass(type(obj), classinfo) might be considered a "side-effects-free" version of isinstance. So perhaps one thing to mention in the documentation is that `isinstance(obj, classinfo) != issubclass(type(obj), classinfo)` in general. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Gabriele N Tornetta added the comment: > Python is very much a language about responsibility. If Django is overriding > `__getattribute__` then it is their responsibility to ensure that everything > still works properly. Perhaps I didn't stress observability enough. A tool like a tracer or a profiler, in the ideal world, is not supposed to perturb the tracee in any way. The current implementation of isinstance, when used by an observability tool, may cause side effects as well as overheads, so it is not safe to use in such tools. Working around it may solve the side-effects issue, but leaves the problem of overheads. Changing the way isinstance works internally might prove beneficial for such tools. En passant, I think it should be noted that the built-in "type" doesn't suffer from the same problem, i.e. ~~~ class Side(object): def __getattribute__(self, name): ValueError(name) type(Side()) ~~~ works as expected. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Gabriele N Tornetta added the comment: > I tend to agree with Steven and David here. You define __getattribute__ and > so that's the behaviour you get when an attribute of the class is requested > (whether by the system or by your code). I would agree if it was obvious or explicitly stated that isinstance looks up __class__ using the object's __getattribute__, and thus prone to cause side-effects. It wasn't obvious to me that isinstance would access any attributes from the object, but that it would rather get the object's type in a more direct way (at the C level for CPython). > Do you have a real-world example of code that is broken by this behaviour, or > is this just a theoretical problem? I was looking at some profiling data for a real-life project (observability) that I'm working on. I was using a simple Django application as a target and noticed calls to a __getattribute__ (implemented by a Django class) that I wasn't expecting. All my code was doing was to check that a certain object was not of "callable" type using isinstance. Whilst I believe no side effects were caused by this particular instance of __getattribute__, it should be noted that "Django" is a variable here: any other target framework or library might have caused side effects in theory. The code that I want to execute must have guarantees of being side-effects-free, so using isinstance does not give me that. Currently, I have worked around this by using a custom, pure Python implementation of isinstance that gets __mro__ (via object.__getattribute__) and checks that type(obj) is an element of it (plus caching, for performance reasons). -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Gabriele N Tornetta added the comment: I think the issue on display here is that isinstance could cause a side effect, which I dare say it's unexpected (and not documented AFAIK). Are there any reasons why __class__ cannot be retrieved with object.__getattribute__ instead? In fact, considering that __getattribute__ could be overridden, this would be the right thing to do imho, else isinstance would break spectacularly, like in my previous example. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Gabriele N Tornetta added the comment: The following example shows isinstance causing a side effect class Side: class Effect(Exception): pass def __getattribute__(self, name): raise Side.Effect() isinstance(Side(), str) I'd be inclined to see this as a bug as I wouldn't expect isinstance to cause any side effects. -- nosy: +Gabriele Tornetta ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45468] Add support for preloading a Python script
Gabriele N Tornetta added the comment: That's totally fine. My aim is to have something in place that would make preloading some code less clunky than what it is just now. -- ___ Python tracker <https://bugs.python.org/issue45468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45468] Add support for preloading a Python script
Gabriele N Tornetta added the comment: @christian.heimes thanks for bringing PEP 648 to my attention. The solution proposed there would work for me, although it actually does a bit more with some extra complexity. Not a big issue though. @eric.smith I think that, as argued in PEP 648, pth files are not meant to be used to inject arbitrary code. Besides, the way to exploit pth files wouldn't be much more different than what I described in the issue body. -- ___ Python tracker <https://bugs.python.org/issue45468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45468] Add support for preloading a Python script
Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +27235 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28946 ___ Python tracker <https://bugs.python.org/issue45468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45468] Add support for preloading a Python script
New submission from Gabriele N Tornetta : I would like to propose adding support for preloading a Python script before executing a Python application. Potential design: A new environment variable (e.g. PY_PRELOAD, an allusion to LD_PRELOAD, or PYTHONPRELOAD to be more aligned with the naming pattern of existing variables) is used to specify the path of the script to execute. The script is then executed just before the import of the site module. This is similar to what PYTHONSTARTUP does, except that it works in all cases, not just when launching the REPL. Rationale: There are examples of tools that require performing some operations (e.g. monkey-patching) before starting the actual Python application. Currently, this could be achieved in the following rather contrived way: - prepare an ad-hoc sitecustomize.py file - add its path to PYTHONPATH - run the Python application with the computed PYTHONPATH The ad-hoc sitecustomize.py requires the following steps - run the custom initialisation code - remove the path of the custom sitecustomize.py script from sys.path - unload the sitecustomize module - try importing sitecustomize to force-load any original sitecustomize scripts that would have run otherwise The new environment variable makes the whole process a lot easier by allowing tools to just set a single environment variable to achieve the same result. -- components: Interpreter Core messages: 403898 nosy: Gabriele Tornetta priority: normal severity: normal status: open title: Add support for preloading a Python script type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
Gabriele N Tornetta added the comment: With commit 7a12d31a8c22cae7a9c1a2239a1bb54adee33622 the new figures are # main (7569c0fe91): 25_059_438 bytes # bpo-445303-code-qualname (7a12d31a8c): 25_089_917 bytes which is a 0.1% relative increase :). This is likely due to the fact that with the change MAKE_FUNCTION needs to pop one less value from the TOS, as the qualname now comes from the code object. I think the PR is now good for a first review. I think I'd need some help with the documentation sources. -- ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
Gabriele N Tornetta added the comment: > That is a pointer size per code object. The most standard way is to calculate > the size of all pyc files in the stdlib after compiling them all with "-m > compileall -r 1000 Lib". This yields the following numbers between what was main when I branched off and the tip of my branch: # main (7569c0fe91): 25_059_438 bytes # bpo-445303-code-qualname (a0252ab9ad): 25_511_492 bytes So that seems to be about half a MB increase over 25 MB (about 2% relative increase). This is potentially just an interim result, as at first sight it looks like MAKE_FUNCTION could require one less argument (the qualname), which can now be taken from the code object. So not quite the final picture yet. -- ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
Gabriele N Tornetta added the comment: @pablogsal Commit a0252ab9add7d48e9e0604ebf97342e46cf00419 exposes co_qualname to Python. I've added a test case to check that the result coincides with the current implementation of __qualname__. Is there a "standard" way for me to quantify the memory impact of these kinds of changes? @Mark.Shannon I'll look into making __qualname__ use __code__.co_qualname as a next step. -- ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
Gabriele N Tornetta added the comment: Thanks for the feedback. I certainly appreciate all the concerns around this proposed change. @Mark.Shannon 1. This is the desired behaviour as profiling data should be attached to the actual code objects that correlate with the actual source content. Besides, in this respect, given the immutability of code objects, qualname behaves like name. 2. At the Python level it is already possible to get the __qualname__ of a function (but not of a code object). As this is all I needed, I kept my initial implementation to the bare minimum. 3. I agree with this analysis. Whilst this increases the memory footprint, it might have the benefit of making the derivation of __qualname__ faster as this would now be cached on code objects. However, I also appreciate @pablogsal's point of view of evaluating the actual benefits. The extra point in favour of this change that I can make is that it would resolve name clashes in profiling data from tools that have minimal impact on the runtime. Whether this is enough to justify the extra memory cost is certainly up for debate. From my side, I don't have the numbers to make this case more concrete. As a next step, I'll look into exposing the new field to Python to see what it actually ends up looking like. -- ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +25508 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26941 ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44530] Propagate qualname from the compiler unit to code objects for finer grained profiling data
New submission from Gabriele N Tornetta : When dumping profiling data out of code objects using out-of-process tools like Austin (https://github.com/p403n1x87/austin) one has access only to file name, function name, and line number. Consider the flame graph generated by running the following script, and aggregating on function names class Foo: def on_cpu(self, n): a = [] for i in range(n): a.append(i) class Bar: def on_cpu(self, n): a = [] for i in range(n): a.append(i) if __name__ == "__main__": f = Foo() b = Bar() f.on_cpu(1_000_000) b.on_cpu(5_000_000) Without the extra information coming from the actual Python source, one would not be able to tell, by looking at the flame graph alone, that on_cpu has contributions from two different methods. By propagating the qualname information from the compiler to code objects, such names would be disambiguated and the resulting flame graph would be clearer. I would like to propose adding the co_qualname field to the PyCodeObject structure, which is to be set to NULL except for when the code object is created by the compiler in compile.c. -- components: C API files: py_main.png messages: 396667 nosy: Gabriele Tornetta priority: normal severity: normal status: open title: Propagate qualname from the compiler unit to code objects for finer grained profiling data type: enhancement versions: Python 3.11 Added file: https://bugs.python.org/file50128/py_main.png ___ Python tracker <https://bugs.python.org/issue44530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44417] bytecode<>line number mapping and f_lasti seem wrong in 3.10.0b2
Gabriele N Tornetta added the comment: I think I managed to find the source of the confusion. This seems to be due to https://github.com/python/cpython/commit/fcb55c0037baab6f98f91ee38ce84b6f874f034a, with the f_lasti from the C struct now being half of the value returned by the f_lasti attribute of the frame object (is this documented somewhere?). -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44417] bytecode<>line number mapping and f_lasti seem wrong in 3.10.0b2
Change by Gabriele N Tornetta : -- title: bytecode<>line number mapping seems wrong in 3.10.0b2 -> bytecode<>line number mapping and f_lasti seem wrong in 3.10.0b2 ___ Python tracker <https://bugs.python.org/issue44417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44417] bytecode<>line number mapping seems wrong in 3.10.0b2
New submission from Gabriele N Tornetta :
I was looking at how the new co_linetable works in order to add initial support
for Python 3.10 to Austin (https://github.com/P403n1x87/austin) when I stumbled
upon the following interesting output from the dis module. I am using the
following test target:
https://github.com/P403n1x87/austin/blob/master/test/target34.py
When I call python3.10 -m dis target34.py using Python 3.10.0b2 I get
25 0 LOAD_CONST 0 (0)
2 LOAD_CONST 1 (None)
4 IMPORT_NAME 0 (threading)
6 STORE_NAME 0 (threading)
28 8 LOAD_CONST 2 ()
10 LOAD_CONST 3 ('keep_cpu_busy')
12 MAKE_FUNCTION0
14 STORE_NAME 1 (keep_cpu_busy)
36 16 LOAD_NAME2 (__name__)
18 LOAD_CONST 4 ('__main__')
20 COMPARE_OP 2 (==)
22 POP_JUMP_IF_FALSE 25 (to 50)
37 24 LOAD_NAME0 (threading)
26 LOAD_ATTR3 (Thread)
28 LOAD_NAME1 (keep_cpu_busy)
30 LOAD_CONST 5 (('target',))
32 CALL_FUNCTION_KW 1
34 LOAD_METHOD 4 (start)
36 CALL_METHOD 0
38 POP_TOP
38 40 LOAD_NAME1 (keep_cpu_busy)
42 CALL_FUNCTION0
44 POP_TOP
46 LOAD_CONST 1 (None)
48 RETURN_VALUE
36 >> 50 LOAD_CONST 1 (None)
52 RETURN_VALUE
Disassembly of :
29 0 BUILD_LIST 0
2 STORE_FAST 0 (a)
30 4 LOAD_GLOBAL 0 (range)
6 LOAD_CONST 1 (200)
8 CALL_FUNCTION1
10 GET_ITER
>> 12 FOR_ITER21 (to 56)
14 STORE_FAST 1 (i)
31 16 LOAD_FAST0 (a)
18 LOAD_METHOD 1 (append)
20 LOAD_FAST1 (i)
22 CALL_METHOD 1
24 POP_TOP
32 26 LOAD_FAST1 (i)
28 LOAD_CONST 2 (100)
30 BINARY_MODULO
32 LOAD_CONST 3 (0)
34 COMPARE_OP 2 (==)
36 POP_JUMP_IF_FALSE 27 (to 54)
33 38 LOAD_GLOBAL 2 (print)
40 LOAD_CONST 4 ('Unwanted output ')
42 LOAD_GLOBAL 3 (str)
44 LOAD_FAST1 (i)
46 CALL_FUNCTION1
48 BINARY_ADD
50 CALL_FUNCTION1
52 POP_TOP
>> 54 JUMP_ABSOLUTE6 (to 12)
30 >> 56 LOAD_CONST 0 (None)
58 RETURN_VALUE
Note how the line number is not monotonic. Compare this to the output generated
by Python 3.9.5
25 0 LOAD_CONST 0 (0)
2 LOAD_CONST 1 (None)
4 IMPORT_NAME 0 (threading)
6 STORE_NAME 0 (threading)
28 8 LOAD_CONST 2 ()
10 LOAD_CONST 3 ('keep_cpu_busy')
12 MAKE_FUNCTION0
14 STORE_NAME 1 (keep_cpu_busy)
36 16 LOAD_NAME2 (__name__)
18 LOAD_CONST 4 ('__main__')
20 COMPARE_OP 2 (==)
22 POP_JUMP_IF_FALSE 46
37 24 LOAD_NAME0 (threading)
26 LOAD_ATTR3 (Thread)
28 LOAD_NAME1 (keep_cpu_busy)
30 LOAD_CONST 5 (('target',))
32 CALL_FUNCTION_KW 1
34 LOAD_METHOD 4 (start)
36 CALL_METHOD 0
38 POP_TOP
38 40 LOAD_NAME1 (keep_cpu_busy)
42 CALL_FUNCTION0
44 POP_TOP
>> 46 LOAD_CONST 1 (None)
48 RETURN_VALUE
Disassembly of :
29 0 BUILD_LIST 0
2 STORE_FAST 0 (a)
30 4 LOAD_GLOBAL 0 (range)
6 LOAD_CONST 1 (200)
8 CALL_FUNCTION1
10 GET_ITER
>> 12 FOR_ITER42 (to 56)
14 STORE_FAST 1 (i)
31 16 LOAD_FAST0 (a)
18 LOAD_METHOD 1 (append)
20 LOAD_FAST1 (i)
[issue43931] Add the Python version to the API data.
Change by Gabriele N Tornetta : -- keywords: +patch pull_requests: +24297 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25577 ___ Python tracker <https://bugs.python.org/issue43931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43931] Add the Python version to the API data.
New submission from Gabriele N Tornetta : When Python is embedded in other applications, it is not easy to determine which version of Python is being used. This change exposes the Python version as part of the API data. Tools like Austin (https://github.com/P403n1x87/austin) can benefit from this data when targeting applications like uWSGI, as the Python version can then be inferred systematically by looking at the exported symbols rather than relying on unreliable pattern matching or other hacks (like remote code execution etc...). -- components: C API messages: 391779 nosy: Gabriele Tornetta priority: normal severity: normal status: open title: Add the Python version to the API data. type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43879] Add native_thread_id to PyThreadState
Change by Gabriele N Tornetta : -- title: Add native_id to PyThreadState -> Add native_thread_id to PyThreadState ___ Python tracker <https://bugs.python.org/issue43879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
