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
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/issu
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__
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
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/issu
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
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
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
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 explicit
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
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
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/issue45
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
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/issu
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
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
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 w
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 t
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
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/issu
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
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
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.pyt
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
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/issu
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
Change by Gabriele N Tornetta :
--
title: Add native_id to PyThreadState -> Add native_thread_id to PyThreadState
___
Python tracker
<https://bugs.python.org/issu
27 matches
Mail list logo
