Understanding Python's interpreter

["Martin v. Löwis"]

>> 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 not necessarily true for C. To deal with ASCII-printed
integers in C, you need to deal with memory management, and
variable-sized buffer. For example, if you want to print to
memory, you need to overallocate memory, print to it, and
then shrink the extra allocation (e.g. by copying the string
elsewhere).

For 4-byte integers in binary, no memory-management issue arises.
You know exactly how much memory you will need.

> 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.

That would probably defeat the point of .pyc files entirely: you
already *have* an ASCII version of it, the .py file. So why create
a second file?

> 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.

Sure: Take a look at the struct module.

Regards,
Martin