On Sat, 07 Apr 2007 04:35:49 +0200 Gabriel Genellina <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
