Understanding Python's interpreter

[Rafael Almeida]

On Sat, 07 Apr 2007 04:35:49 +0200
Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:

> Speed? Eficiency? File size? Ease of use?
> A .pyc *could* be written in ASCII, but what do you gain? Replacing a 
> few trivial functions in the Python core with a printf/scanf equivalent? 
>   At the same time you lose a lot of speed, so I don't see the point.

Hm, I didn't realise that it would be that much slower.

> Why harder? Once you read the file, they're just numbers. Anyway, being 
> harder to program the *interpreter* is not a problem, if you gain 
> something like speed or eficiency for the interpreted language.

Well, it's harder to get 4 bytes and create an int out of it in a
portable way than just call strtol or scanf, that's what I thought
while I was coding my interpreter. It's not the hardest thing to do,
of course, but it made me wonder why not just do the simplest thing.

Since I've never seen a .pyc bigger than a few kilobytes, I thought an
ascii file would take more space, but it wouldn't be anything really
prohibitive.

I didn't think using strtol would make that much difference in speed.
But now you talked about it, and after thinking a little bit more about
it, I'm convinced that the speed difference may be relevant.

> > And when I tried to code an assembler my problems got greater, as I
> > wanted to code it in python (the interpreter was in C++) and I had a
> > hard time trying to figure out how I would print something that's not a
> > ascii or unicode string. As for the benefits, I couldn't figure out any.
> 
> Sorry, I could not understand what you said here.

It's not anything important, I was just saying that I had to write a
little more code to make an integer such as 0xff into '\0\0\0\377' than
it would need to just print the integer. Well, unless there's already a
python function that does just that and I didn't know about. It's was
just an example on how writting in ascii is easier.