Python and Flaming Thunder

[Lie]

On May 16, 3:58 am, "bruno.desthuilli... at gmail.com"
<bruno.desthuilli... at gmail.com> wrote:
> On 15 mai, 19:30, Lie <Lie.1... at gmail.com> wrote:
>
>
>
> > On May 15, 4:08 am, "bruno.desthuilli... at gmail.com"
>
> > <bruno.desthuilli... at gmail.com> wrote:
> > > On 14 mai, 08:08, Lie <Lie.1... at gmail.com> wrote:
>
> > > > On May 14, 12:51 pm, Lie <Lie.1... at gmail.com> wrote:
>
> > > > > And your 8 by 8 cross compiler doesn't impress me at all, they're all
> > > > > based on x86/IA-32 architecture which is quite similar, no PowerPC,
> > > > > SPARC, ARM, no other CISC or RISC architecture. And your compiler is a
> > > > > single language compiler instead of three dimensional compiler that
> > > > > GCC is (cross platform, cross target platform, cross language).
>
> > > > And to add, I also need to mention that Python doesn't need to be
> > > > compiled at all,
>
> > > No language needs compilation - it's an implementation problem, not a
> > > language problem. Now all the Python's implementations I know do use
> > > compilation (to byte-code).
> > > > its py and pyo file is architecture independent.
>
> > > True, but this is not strictly related to being compiled or not.
>
> > It's true, it's implementation problem whether a language is compiled
> > or not, but what I was emphasizing was that Python's code is
> > architecture independent at all stages (that is visible to the user
> > and the programmer), on the other hand, a compiled code is a compiled
> > code is a compiled code,
>
> Ever wondered what all these .pyc files were ?
>
> > it cannot be architecture independent without
> > packing multiple binaries in the same executable (like in Macintosh's
> > universal binary) or using an emulation (with huge overheads) or at
> > least using a compatibility layer (which doesn't always work) and all
> > this is done in the layer that is visible to user and programmer
> > (programmer having to compile against everything and user having to
> > download the correct executable) instead of being done in a platform
> > independent way that interpreted language like Python have.
>
> Python is not interpreted, because being interpreted is a feature of
> an implementation, not of a language. And so far, no known Python
> implementation is (strictly speaking) interpreted - they all compile
> to byte-code. "compiled" doesn't necessarily imply "compiled to
> platform native binary code", you know.

That's beside the point, the point is about platform independentness
of the .py file. When I call Python is interpreted, I meant that the
CPU doesn't directly interpret python codes (in most Python
implementation).

> Ok, this may look like a bit on the splitting hairs side. But may I
> remind you that to run ever a .pyc file, you do need to have the
> Python runtime (VM + quite a lot of libs) installed one way (normal
> install) or another (packed in something that looks like an ordinary
> "executable" - whatever this means for the target platform) ? OTHO,
> it's true that a .pyc file is platform-independant  - it just requires
> the correct versions of quite a lot of platform-dependant binaries.
> Wait... Isn't this code some kind of a "visible to the user and
> programmer" "compatibilty layer" ?

With the same bit on being on the splitting hair side: It's the same
with msvcrt in C or msvbvm60 in VB, programming language runtime is
invisible to the user, it's visible to the system administrator
(which, in many cases is also the user though). It is, however,
invisible to both the user and the programmers.