[Python-Dev] Exceptions and tracebacks and frames, oh my!

Hi everyone, Apologies for pinging the dev list; I'm shaving a very hairy yak, and the python-help crew, the docs, and the source are all unable to help. Context: I'm working on a library function to dump stack traces for all threads, sorta like _Py_DumpTracebackThreads but in Python and meant to

[Python-Dev] Re: Sanity check about ctypes

ong typing, does it show?) Yonatan On Wed, Jan 5, 2022 at 5:15 PM Gregory P. Smith wrote: > > On Wed, Jan 5, 2022 at 3:17 PM Yonatan Zunger wrote: > >> Hey everyone. >> >> Quick sanity check: The ctypes docs >> <https://docs.python.org/3.10/library/ctypes.h

[Python-Dev] Sanity check about ctypes

Hey everyone. Quick sanity check: The ctypes docs refer to _CData as a non-public class which is in the module, but _ctypes.c doesn't actually export it . (

[Python-Dev] Re: Intended invariants for signals in CPython

e of thumb: If your Python code has comments talking about specific opcodes, you are writing some Really Interesting Python Code. :) Yonatan On Sat, Jun 27, 2020 at 10:26 PM Nick Coghlan wrote: > On Fri., 26 Jun. 2020, 7:02 am Chris Jerdonek, > wrote: > >> On Wed, Jun 24, 2020 at

[Python-Dev] Re: Intended invariants for signals in CPython

limb that particular mountain yet, but I figured I'd see what obvious holes other people could poke in it. Thanks for your help! On Thu, Jun 25, 2020 at 1:27 PM Antoine Pitrou wrote: > On Thu, 25 Jun 2020 11:18:13 -0700 > Yonatan Zunger via Python-Dev wrote: > > Also, just to

[Python-Dev] Re: Intended invariants for signals in CPython

e to say it's a damned clever solution to the problem. On Thu, Jun 25, 2020 at 6:35 PM Yonatan Zunger wrote: > I had not -- thank you! > > On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek > wrote: > >> On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < >&

[Python-Dev] Re: Intended invariants for signals in CPython

I had not -- thank you! On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek wrote: > On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> gen

[Python-Dev] Re: Intended invariants for signals in CPython

to write a general library to help simplify the task, and so thinking about a lot of slightly nutty corner cases...) On Thu, Jun 25, 2020 at 10:33 AM Yonatan Zunger wrote: > I'm taking it from this thread that suppressing signals in a small window > is not something anyone in their right mind

[Python-Dev] Re: Intended invariants for signals in CPython

org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4TNEA5KNWCYTJVIPISUZKVXVDK2BQJWT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Yonatan Zunger Distinguished Engineer and Chief Ethics Of

[Python-Dev] Re: Intended invariants for signals in CPython

indicating this? On Wed, Jun 24, 2020 at 2:34 PM Yonatan Zunger wrote: > Hi everyone, > > I'm in the process of writing some code to defer signals during critical > regions, which has involved a good deal of reading through the CPython > implementation to understand the behaviors.

[Python-Dev] Intended invariants for signals in CPython

. - In `faulthandler`, dump_traceback - In `select`, all of the methods. (select, epoll, etc) - In `time`, sleep. - In `curses`, whenever you look for key input. - In `tkinter`, during the main loop of a Tcl/Tk app. - During an SSL handshake. -- Yonatan Zunger Distinguished

[Python-Dev] Re: Adding a scarier warning to object.__del__?

inate that!) On Fri, Jan 3, 2020 at 3:56 AM Jeff Allen wrote: > On 02/01/2020 02:53, Yonatan Zunger wrote: > > Oh, I'm absolutely thinking about clarity. ... > > Could any revision also be clear what is *required of Python the language* > vs. what is a CPython implementation

[Python-Dev] Re: Adding a scarier warning to object.__del__?

ations of __del__(), that's why hard to buy it. > atexit.register() is not a common thing, the recommendation of using > atexit for file descriptor closing *in general* looks weird, while it > can be a good solution in some particular case. > > On Thu, Jan 2, 2020 at 1:05 PM Armin Rigo wrot

[Python-Dev] Re: Adding a scarier warning to object.__del__?

in a context way outside of normal control flow that all other methods are >> invoked from. >> >> -gps >> >> >>> >>> Action on the shutdown is another beast. >>> Personally, I prefer to do all finalization works by explicit calls >>>

[Python-Dev] Re: PEP 558: Defined semantics for locals() (December 2019 edition)

Makes sense. Thanks for the clarification! On Wed, Jan 1, 2020 at 1:30 AM Nick Coghlan wrote: > On Wed, 1 Jan 2020 at 10:42, Yonatan Zunger wrote: > > > > Thanks for writing this up, Nick! > > > > My main question is about the remaining difference between semantics a

[Python-Dev] Re: PEP 558: Defined semantics for locals() (December 2019 edition)

Thanks for writing this up, Nick! My main question is about the remaining difference between semantics at the class/module versus function level: is it worth the additional cognitive complexity to have the class/module behavior be different from the function behavior? The "mutable" class/module b

[Python-Dev] Adding a scarier warning to object.__del__?

Hey everyone, I just encountered yet another reason to beware of __del__: when it's called during interpreter shutdown, for reasons which are kind of obvious in retrospect, if it calls notify() on a threading.Condition, the waiting thread may or may not ever actually receive it, and so if it does

[Python-Dev] Re: Helpers for dynamic bytecode generation

@jjevnik -- Oops! I meant to send it there and sent it here by mistake. But thank you, everyone, for the recommendations! I'll check them all out and (mercifully) will probably not try to write this from scratch. On Thu, Oct 24, 2019 at 11:05 PM Brandt Bucher wrote: > Interesting that you bring

[Python-Dev] Helpers for dynamic bytecode generation

Hi everyone, I've found myself recently writing Python code that dynamically generates bytecode.¹ I now have yet another case where I'm having to do this, in which my nice situation of being able to easily precompute all the jump addresses no longer holds. So I'm starting to write a helper to make

[Python-Dev] Re: Snapshot formats in tracemalloc vs profiler

PM Yonatan Zunger wrote: > Well, then. I think I'm going to have some fun with this. :) > > Thank you! > > On Thu, Jun 27, 2019 at 4:17 PM Victor Stinner > wrote: > >> Le ven. 28 juin 2019 à 01:03, Yonatan Zunger a écrit : >> > Although while I h

[Python-Dev] Re: Snapshot formats in tracemalloc vs profiler

Well, then. I think I'm going to have some fun with this. :) Thank you! On Thu, Jun 27, 2019 at 4:17 PM Victor Stinner wrote: > Le ven. 28 juin 2019 à 01:03, Yonatan Zunger a écrit : > > Although while I have you hear, I do have a further question about how > tracemalloc work

[Python-Dev] Re: Snapshot formats in tracemalloc vs profiler

mat. Adding a new > tracemalloc.dump_pstats() function looks like a good idea. Does pstats > allow to attach arbitrary data to a traceback? The root structure of > tracemalloc is basically the tuple (size: int, traceback) (trace_t > structure in C). > > Victor > > Le jeu. 27 juin

[Python-Dev] Snapshot formats in tracemalloc vs profiler

Hi everyone, Something occurred to me while trying to analyze code today: profiler and cProfiler emit their data in pstats format, which various tools and libraries consume. tracemalloc, on the other hand, uses a completely separate format which nonetheless contains similar data. In fact, in many