[Python-de] Minimal Python (war: [Langer, leicht ins OT driftende Sermon] Was mir an Python gef?llt)

holger krekel pyth at devel.trillke.net
Sat Jan 4 15:10:29 EST 2003


Christian Tismer wrote:
> holger krekel wrote:
> 
> ...
> 
> >>Gut, um es zu konkretisieren: Ich will keine
> >>Rekursionen verbieten, das wird man auf jeden
> >>Fall für C-Module brauchen, wenn die nicht total
> >>umgschrieben/gedacht werden sollen.
> >>Aber den Kernel kann man 100% kompatibel machen
> >>und dabei von vornherein interativ arbeiten.
> > 
> > welche teile meinst du genau mit kernel?
> 
> Der Kernel ist für mich zunächst das absolute
> Minimalsystem, damit's läuft. Dieser Teil ist
> in C geschrieben.
> 
> Es ist mehr ein Scripting-Kernel, weniger auf
> Python fixiert.
> 
> Als implementierte Grundstrukturen schweben mir
> vor (aber diese könnten evtl. noch reduziert werden):
> 
> allg. Sequence, List, Tuple
> allg. Mapping, Dictionary, String-Dict
> Integers

bis hierhin ist es wohl keine Frage, das in C zu machen
bzw. zu belassen.  Allerdings ist 'Sequence' kein Type. 
Das ist ein Protokol auf einer hoeheren Ebene oder 
was meinst du genau? 

> Frames

[zu meiner vergewisserung]
ein Frame ist ja das objekt, mit dem der interpreter arbeitet.
Es enthaelt Informationen darueber, was die VM gerade abarbeitet,
ueber 'code bloecke' wie z.B. try-finally Konstrukte, damit im
Falle einer Exception der Stack zurueckgerollt werden kann.  
Zudem kennt es alle Konstanten und lokalen, globalen und freien
Variablen(namen).  Frei sind Variablen z.B. wenn sie einen
nested Scope referenzieren. 

> Interpreter für Bytecode Python 2.3

Vielleicht liesse sich der schon in Python schreiben? 
Erst mal klingt das widerspruechlich. Wie sollte der Interpreter
jemals einen bytecode interpretieren, wenn diese interpretation
auch wieder aus der interpretation von bytecodes besteht.  

Andererseits ist es durchaus vorstellbar, einen Interpreter 
komplett in python zu schreiben.  Es hindert uns nichts daran, 
die C-Frame Funktionalitaet in python zu implementieren, oder?  
Insofern duerfte das "nur" ein bootstrapping problem sein.  

"Of course, you tell, the Python interpreter is meant to be executed, as
 fast as possible. Wrong! There are cool things we can do about it
 without blindly running it. If (portions of) the core interpreter were
 written in a higher-level language --- say Python --- we would have more
 control over it." Armin Rigo in http://psyco.sourceforge.net/plans.html

Wenn Frame+Interpreter in python geschrieben waeren, waeren
das Probleme [toedliche "Rekursion":-] fuer Stackless?  
 
> Function objects
> 
> New-Style classes

da kenne ich mich noch gar nicht aus (auf der C-Ebene). 

> Minimales File-Interface

was ist mit den ganzen os.path, socket und sonstigen 
lowleveligen systemgeschichten?  Die sind weiterhin
in C (moeglichst unveraendert) zu belassen, oder?

> wenige, essentielle builtins.

Auf dem Namespace-Level wuerde ich die Kompatibilitaet
nicht ueber den Haufen werfen.  

Auf der Frame, bytecode und Interpreterebene kann man ja 
ggf. aendern.  Aber die effektiven namespaces, mit denen 
Python Module laufen, sollten wir nicht veraendern.  Ist 
doch auch kein grosses Thema, weil die meisten builtins sich
doch schnell in python (statt in C) formulieren lassen. 

> Eine virtuelle Maschine, um die core engine zu
> erweitern und als platformunabhängiges Target
> für Psyco. Alles Wesentliche soll in Python
> implementiert werden. Psyco soll dies auf die
> Target-Hardware abbilden. Als Default gibt es
> die virtuelle Maschine, wobei mir ein Subset
> von Knuth's MMIX vorschwebt.

Ist MMIX wirklich schon so weit?  Wie 'minimal' ist
denn MMIX?  Da es von Donald Knuth kommt, wird es 
wohl sehr gut sein.  Kannst du ein paar Eckpunkte
benennen?

> mehr eigentlich nicht.

Threading?  Auf irgendeine Weise muss Threading 
zumindest mitgedacht werden, aber frag mich nicht
auf welche :-)

> Alles obige genannte sehe ich ebenso auf's
> Minimum reduziert.
> 
> Eigentlich ist mir das immer noch zuviel.
> Aber das System wird und in die Lage versetzen,
> die nächste, noch weiter abgespeckte Version
> darin zu implementieren. Hoffe ich.

zumal nur das umsetzen koennen, was innerhalb
einer woche zu einem release fuehrt :-)

> > wann ist denn der naechste BPS?   
> 
> Am 24.01.03 Heilbronner Str. 10, 10709 Berlin, 18:00

werde versuchen, da zu sein.  (Kann ich ggf. bei dir 
uebernachten?)

gruss,

    holger




More information about the Python-de mailing list