Python Written in C?

[giveitawhril2008]

I'm just learning about Python now and it sounds interesting. But I
just read (on the Wiki page) that mainstream Python was written in C.
That's what I was searching for: Python was written in what other
language?

See, my concern was something like: OK, if Python is so hot, then,
hopefully someone is writing it in assembly language for each MPU chip
out there. Otherwise, if, say, they've written it in C#, then it looks
like the REAL, generally useful language to learn is C# and Python is
akin to Visual Basic or something: a specialty language....whe reas
REAL WORLD programmers who want to be generally useful go and learn
C#.

So I was suspecting the Python compiler or interpreter is written in a
REAL language like C#. So, Wiki says it's written in C! It's almost as
if it were an intentional trick...write your own, new language in an
OLD, real world language that is passe. Compile it into executable
modules of course, so it is a real, working compiler, alright. But the
SOURCE is some old, high level language which no one wants to use
anymore! So now you've got a hot new language package and no one can
say "well, it is written in, the SOURCE code is written in, a REAL
language." No, it's not! The source is some outdated language and
compiler and no one is going to prefer learning THAT to learning your
hot new language!

I'm not dissing Python, here. Just noting that, if it is written in C,
that throws a curve at me in trying to balance the value of learning
Python vs. some other major language.

[Grant Edwards]

On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

You talk about "writing it in assembly language for each MPU
chip". Actually it is even better than that. We now have
these modern inventions, called compilers that do that type of
work for us. They translate high level instructions, not
into assembler but into machine language.

Actually, all of the compilers I'm familiar with (gcc and a
handful of cross compilers for various microprocessors )
translate from high-level languages (e.g. C, C++) into
assembly, which is then assembled into relocatable object
files, which are then linked/loaded to produce machine
language.

--
Grant Edwards grante Yow! "DARK SHADOWS"
at is on!! Hey, I think
visi.com the VAMPIRE forgot his
UMBRELLA!!

[Larry Bates]

Grant Edwards wrote:

On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

>You talk about "writing it in assembly language for each MPU
chip". Actually it is even better than that. We now have
these modern inventions, called compilers that do that type of
work for us. They translate high level instructions, not
into assembler but into machine language.

Actually, all of the compilers I'm familiar with (gcc and a
handful of cross compilers for various microprocessors )
translate from high-level languages (e.g. C, C++) into
assembly, which is then assembled into relocatable object
files, which are then linked/loaded to produce machine
language.

I just learned something I did not know. I was under the impression that they
translated directly to machine code without ever actually generating Assembler
text files. Seems like a waste to generate the text and turn around run that
through the assembler, but what do I know. I guess that way the compiler can
have pluggable assembler back-ends.

-Larry

[cokofreedom]

On Jul 22, 5:59 am, Larry Bates <larry.ba...@we bsafe.com`wrote :

Grant Edwards wrote:

On 2008-07-22, Larry Bates <larry.ba...@we bsafe.com`wrote :

You talk about "writing it in assembly language for each MPU
chip". Actually it is even better than that. We now have
these modern inventions, called compilers that do that type of
work for us. They translate high level instructions, not
into assembler but into machine language.

Actually, all of the compilers I'm familiar with (gcc and a
handful of cross compilers for various microprocessors )
translate from high-level languages (e.g. C, C++) into
assembly, which is then assembled into relocatable object
files, which are then linked/loaded to produce machine
language.

I just learned something I did not know. I was under the impression that they
translated directly to machine code without ever actually generating Assembler
text files. Seems like a waste to generate the text and turn around run that
through the assembler, but what do I know. I guess that way the compiler can
have pluggable assembler back-ends.

-Larry

I also I have just learned something new! Troll threads are useful.
Yay.

[Grant Edwards]

On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

Grant Edwards wrote:

>On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

>>You talk about "writing it in assembly language for each MPU
chip". Actually it is even better than that. We now have
these modern inventions, called compilers that do that type of
work for us. They translate high level instructions, not
into assembler but into machine language.

Actually, all of the compilers I'm familiar with (gcc and a
handful of cross compilers for various microprocessors )
translate from high-level languages (e.g. C, C++) into
assembly, which is then assembled into relocatable object
files, which are then linked/loaded to produce machine
language.

I just learned something I did not know. I was under the
impression that they translated directly to machine code
without ever actually generating Assembler text files.

There may indeed be compilers that work that way. On Unix
systems (which is what I work with) compilers have
traditionally generated assembly language files.

Seems like a waste to generate the text and turn around run
that through the assembler, but what do I know. I guess that
way the compiler can have pluggable assembler back-ends.

Since you probably need an assembler anyway, generating
assembly-language in the compiler prevents you from having to
duplicate a bunch of object-code-generation code in two places.

--
Grant Edwards grante Yow! Okay ... I'm going
at home to write the "I HATE
visi.com RUBIK's CUBE HANDBOOK FOR
DEAD CAT LOVERS" ...

[Ethan Furman]

Iain King wrote:

On Jul 21, 6:58 am, "Krishnakan t Mane" <hackin...@gmai l.comwrote:

>First off all c# is absolute rubbish waist of time. if I need to
learn it then I better lern java or pythonfor that matter. and by the
way what is a "real programmer?"

The story of a Real Programmer:

http://www.pbm.com/~lindahl/mel.html

Iain

Wow. Awesome story.
~Ethan

[Erik Max Francis]

Ethan Furman wrote:

Iain King wrote:

>On Jul 21, 6:58 am, "Krishnakan t Mane" <hackin...@gmai l.comwrote:

>>First off all c# is absolute rubbish waist of time. if I need to
learn it then I better lern java or pythonfor that matter. and by the
way what is a "real programmer?"

The story of a Real Programmer:

http://www.pbm.com/~lindahl/mel.html

Iain

Wow. Awesome story.

If my google-fu is up to snuff, these are "screenshot s" (scans of
printouts) of the actual blackjack game in operation:

http://wps.com/projects/LGP-21/Softw...Blackjack1.jpg
http://wps.com/projects/LGP-21/Softw...Blackjack2.jpg

and here's a scan of a printout of some "source code" (machine language):

http://wps.com/projects/LGP-21/Software/CrapGame.tiff

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
In time of war the devil makes more room in hell.
-- (a German proverb)

[Scott David Daniels]

Erik Max Francis wrote:

Ethan Furman wrote:

>Iain King wrote:

>>The story of a Real Programmer:
http://www.pbm.com/~lindahl/mel.html
Iain

Wow. Awesome story.

If my google-fu is up to snuff, these are "screenshot s" (scans of
printouts) of the actual blackjack game in operation:

http://wps.com/projects/LGP-21/Softw...Blackjack1.jpg
http://wps.com/projects/LGP-21/Softw...Blackjack2.jpg

and here's a scan of a printout of some "source code" (machine language):

http://wps.com/projects/LGP-21/Software/CrapGame.tiff

The high school I went to had an LGP-30, and I learned to program on it.
Rumor had it that a student from two years before me used to work late
in the lab, and allow the janitors to play blackjack, and it is further
rumored that he made a bit of money leaning on the transfer control
button.

--Scott David Daniels
Sc***********@A cm.Org

[Larry Bates]

Grant Edwards wrote:

On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

>Grant Edwards wrote:

>>On 2008-07-22, Larry Bates <la*********@we bsafe.com`wrote :

You talk about "writing it in assembly language for each MPU
chip". Actually it is even better than that. We now have
these modern inventions, called compilers that do that type of
work for us. They translate high level instructions, not
into assembler but into machine language.
Actually, all of the compilers I'm familiar with (gcc and a
handful of cross compilers for various microprocessors )
translate from high-level languages (e.g. C, C++) into
assembly, which is then assembled into relocatable object
files, which are then linked/loaded to produce machine
language.

I just learned something I did not know. I was under the
impression that they translated directly to machine code
without ever actually generating Assembler text files.

There may indeed be compilers that work that way. On Unix
systems (which is what I work with) compilers have
traditionally generated assembly language files.

>Seems like a waste to generate the text and turn around run
that through the assembler, but what do I know. I guess that
way the compiler can have pluggable assembler back-ends.

Since you probably need an assembler anyway, generating
assembly-language in the compiler prevents you from having to
duplicate a bunch of object-code-generation code in two places.

I'm not sure I understand what you mean here. The code generation phase of the
top level compiler would have to generate assembler mnemonics instead of just
generating machine coded directly. At that point it should be just as easy to
generate machine code, unless you take advantage of macros, or other helpers
provided in the assembly phase.

My "compiler" work was way back on mainframes and the ones I worked with
definitely didn't produce assembler then needed to be run through the assembler.
They created likable objects directly. But that was over 30 years ago!

All this may be a moot point, because assembler is just a mnemonic
representations of machine language anyway.

-Larry

[Larry Bates]

Marc 'BlackJack' Rintsch wrote:

On Mon, 21 Jul 2008 18:12:54 +0200, mk wrote:

>Seriously, though, would there be any advantage in re-implementing
Python in e.g. C++?

Not that current implementation is bad, anything but, but if you're not
careful, the fact that lists are implemented as C arrays can bite your
rear from time to time (it recently bit mine while using lxml). Suppose
C++ re-implementation used some other data structure (like linked list,
possibly with twists like having an array containing pointers to 1st
linked list elements to speed lookups up), which would be a bit slower
on average perhaps, but it would behave better re deletion?

An operation that most people avoid because of the penalty of "shifting
down" all elements after the deleted one. Pythonistas tend to build new
lists without unwanted elements instead. I can't even remember when I
deleted something from a list in the past.

Ciao,
Marc 'BlackJack' Rintsch

When I use os.walk and need to remove directories or files. Seems to be the
only way to do the in-place delete that is required. But you are right, it is
very seldom.

-Larry

[Grant Edwards]

On 2008-07-23, Larry Bates <la*********@we bsafe.com`wrote :

>Since you probably need an assembler anyway, generating
assembly-language in the compiler prevents you from having to
duplicate a bunch of object-code-generation code in two places.

I'm not sure I understand what you mean here. The code
generation phase of the top level compiler would have to
generate assembler mnemonics instead of just generating
machine coded directly. At that point it should be just as
easy to generate machine code, unless you take advantage of
macros, or other helpers provided in the assembly phase.

Generating assembly language can be a lot easier than
generating machine code. One of the big advantage if you're
generating assembly language is you don't have to handle
relocation and address fix-up issues -- you can let the
assembler and linker take care of it. Letting the linker do
the final machine-code generation step also allows certain
optimizations that can't really be done by the compiler.

My "compiler" work was way back on mainframes and the ones I
worked with definitely didn't produce assembler then needed to
be run through the assembler. They created likable objects
directly.

There probably are plenty of compilers that do that. My
background is Unix and microprocessor stuff, and it could be
that for various reasons the "emit assembly" approach was more
common in that genre.

But that was over 30 years ago!

All this may be a moot point, because assembler is just a
mnemonic representations of machine language anyway.

On many architectures, a particular mnemonic can end up being
translated into one of several slightly different machine
instructions -- for example a simple "jump" mnemonic might
generate any one of several instructions depending on how far
away the destination is located. If you've already got an
assembler and linker than know how to deal with that stuff,
then rather than duplicate the same functionality in the
compiler, one might just decided to emit a "jump mnemonic" and
a label.

--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.com it!