Mike C. Fletcher wrote:
> Steve Holden wrote:
>> Rafael Almeida wrote:
>>
> ...
>> Because they aer smarter than you, without wishing to be too rude.
>>
> Replace that with "more experienced", please. Otherwise it is a bit
> rude, despite your wishes. We've always been newbie positive on
Steve Holden wrote:
> Rafael Almeida wrote:
>
...
> Because they aer smarter than you, without wishing to be too rude.
>
Replace that with "more experienced", please. Otherwise it is a bit
rude, despite your wishes. We've always been newbie positive on
Python-list, and new compiler writer
Rafael Almeida wrote:
> 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 equival
>> 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
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
Rafael Almeida wrote:
> I'm studying compilers now on my university and I can't quite
> understand one thing about the python interpreter. Why is its input a
> binary file (pyc)? The LOAD_CONST opcode is 100 (dec) and STORE_FAST's
> is 125 (dec). The translation of the following code:
>
> foo.py:
