Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #59209 > unrolled thread

Re: Conditional breakpoints in ceval.c

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Conditional breakpoints in ceval.c Tim Golden <mail@timgolden.me.uk> - 2013-11-12 15:49 +0000

#59209 — Re: Conditional breakpoints in ceval.c

On 12/11/2013 15:40, Demian Brecht wrote:
> On Sat, Nov 9, 2013 at 5:33 AM,  <python-list-request@python.org> wrote:
>> I don't know how to use gdb the way you want, but it sounds like you are on a fascinating journey of discovery.  What are you trying to learn?  Perhaps we can talk about how the interpreter works.
> 
> Apologies for not getting to this sooner, I took a much needed short
> hiatus from touching all things computers over the long weekend.
> 
> A little backstory to how I got to this sticking point:
> 
> I decided to write a series of blog posts about the lesser-known areas
> of the Python stdlib (I was considering doing a lightning talk about
> one or two of them). First stop was abc's. When digging into that, I
> realized that the implementation of abcs is a bit different than other
> modules in the stdlib: It's only partially implemented in Python.
> 
> After digging into that more and figuring out how that was all
> implemented in C, I also found that, while I understood how to use
> metaclasses, I didn't quite understand how the interpreter used
> metaclasses to build new classes (I had read the docs, but felt that I
> couldn't explain it to my grandmother and therefore, a blog post on
> metaclasses likely would only be surface level and wouldn't include
> any information outside of what's readily available through the docs).
> 
> At that point, I had spent quite a bit of time grep'ing and grok'ing
> various parts of the interpreter code. I felt there /had/ to be a be a
> more efficient way to see what's going on for a particular code block.
> Further digging pointed me to compile/dis to get the bytecode
> generated by code blocks. This then led me to ceval.c, setting
> breakpoints to step through and see what actually happens with the
> code. This is where I ran into a bit of a wall due to my lack of
> practice with gdb.

You may well have seem them but, in case you haven't, look at Eli
Bendersky's occasional blog series:

http://eli.thegreenplace.net/category/programming/python/python-internals/

(Not answering your current query but hopefully useful anyway).

TJG

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web