[Python-de] Syntax / Parrot

Det ddet at gmx.de
Mon Apr 2 16:04:12 EDT 2001


Hi folks,

sorry wegen "schon wieder dieser Diskussion",  sie ist aber wohl
nicht abgehakt, habe ich den Eindruck, sonst bringen Leute wie
ich sie nicht immer wieder auf den Plan.
(Der Sinn ist eben nicht  intuitiv ersichtlich).
Muss jetzt aber nicht zu weit fuehren, wenn's nervt.

On 2 Apr 2001, at 6:48, Georg Mischler wrote:
> Warum kann Code in einer Zeitschrift nicht so gedruckt werden,
  wie er geschrieben wurde?  Muessen gedruckte Listings wirklich
  immer unleserlich formatiert werden?

Schon recht ;-)

> Dito fuer E-mail. 

(Hmm. Autom. Zeilenumbrueche ?)

> Wenn's mehr als fuenf oder zehn Zeilen sind,
  solltest du es ohnehin in ein Attachement verpacken.

Danke fuer den Tip ....

> > 2.)  Scripts auf der Kommandozeile (-c)
  
  Wie haeufig verwendest du das mit anderen Sprachen?  

Nun, unter Unices ist es relativ wenig notwendig, man hat ja die
Shell selber. Unter DOS eigentlich nur, wenn man mit einer
vernuenftigen Sprache arbeiten will.
Und wenn man auf heterogenen Systemen ist, waere
es schoen, ueberall mit _einer_  Sprache auszukommen,
auch fuer die kleinen Tasks  (ohne direkt eine Datei im 
Editor anlegen zu muessen).

> Wenn das
  Script mehr als ein Statement enthaelt, dann muss ich es
  normalerweise ohnehin mehrmals ausprobieren/korrigieren.

Hmm.   Trifft nicht meinen Unix-Alltag, und den etlicher
Perlianer (bin ich nicht) auch nicht.
Und wenn der erste Treffer nicht hinhaut, gibts noch die History.

> Damit wird der Overhead einer extra Datei vernachlaessigbar.
  Aber mit einer vernuenftigen Shell ist es ja auch kein Problem,
  auf der Kommandozeile ein paar Tabs oder Spaces
  unterzubringen.

Tja, reden wir nochmal ueber  DOS....
Ich gebrauche Python eben auch als Hilfsmittel  :-) .


> > 3.)  Fehler durch gemischte Indentation Tab/Spaces
 
> Besorg dir 'nen vernuenftigen Editor. Diese Antwort wirst du
  sicher am meisten schaetzen... ;-) Aber es ist wirklich wahr, es
  hilft!

_Ich_  ?   Hab einen  (BTW: Wann gibt's emacs mit Python als
Sprache ?  :-)  ).

Aber ist schon komisch, mal an einem anderen System zu sitzen,
einen Code zu oeffnen und nicht zu wissen, welcher Art denn die
unsichtbaren Infos sind ...  (und selbst der emacs bietet ein
Sichtbarmachen von Tabs/Spaces nur als add-on).

> > und:  Ich sehe so keine Moeglichkeit, Python ggf. mal als
    HTML-Embedded-Sprache anzubieten, wie es Perl macht.
    Mir waere eine Sprache fuer alles schon lieber, als hier
    PHP, da Python (und dort ggf. doch noch Perl) und so.
> HTML-embedded XXX ist nur eine von vielen Moeglichkeiten,
  dynamischen Content zu erzeugen, und definitiv nicht die
  sauberste (wegen der Vermischung von Praesentation und
  Funktionalitaet).  

*sigh*  Wem sagst Du das. 

> Der Trend mit Python geht eher in Richtung von
  Templates, wie es z.B.  Mailman macht. 

Wenn, und auch nur wenn, es eine Applikation ist, die sich
ueber HTML praesentiert.  und nicht (von der Verteilung her) 
umgekehrt.
Da ist das Anlegen eines CGI-Scripts plus Template
umstaendlicher, als ein paar Zeilen in der Seite selbst.
(Portale oder Webforen wuerde ich auch nicht embedded
schreiben).

> Damit kann auch jemand
  ohne Programmierkenntnisse das Layout der Seiten aendern, im
  Falle von Mailman sogar ueber ein Web-Interface.  Und neben
  Zope sehen alle Perl/php-Loesungen ohnehin eher blass aus...

Hmmm.  Moloch. Viel Doku.   Mit Kanonen auf Spatzen.
Als Big-Site-Loesung voellig ok,  fuer ein bisschen Dynamik bzw.
Modularitaet auf einer  kleinen bis mittleren Web-Page IMHO zuviel.
Oder deckt Python per definitionem  nur den High-End-Bereich
ab ?
Dann hab ich da was falsch verstanden.

> Tatsache ist: Es gibt keine vernuenftige Moeglichkeit (oder gar
  einen wirklichen Bedarf), Python mit unspacigen Block-Delimitern
  zu versehen, ohne damit gleichzeitig die einmalige Qualitaet der
  Sprache massiv zu beeintraechtigen. 

Moeglichkeit ...    ok! 

Bedarf ...Aeh .. war das in Mailmansourcen, wo ich  Konstrukte,
wie:

def  funktion () :
     rumpf
     rumpf
#endfunktion

oder  
   while   xyz :
         rumpf
    #endwhile

gesehen habe  ?


Es geht einfach darum, welche Information steckt wo ?
Ich rege mich auch ueber den Kollegen auf, der in Excel
vier Spalten anlegt, um acht Informationen unterzubringen.
(Und die restlichen vier eben durch Fettschrift und farbige Zellen
dokumentiert).  Fehleranfaellig, Info ist nicht exportierbar usw. .

Und dann als Formel gesehen:
Ich stelle mir  vor:    3  *  5 + 4   = 27
Da ja 5 + 4 zuerst gerechnet wird, die Operanden sind ja
schliesslich vom Operator nur _ein_  Space entfernt, 
(habt Ihr sicherlich gemerkt, wenn Ihr nicht gerade
Proportionalschrift habt) die Operanden beim *  jedoch 
_zwei_  ...

Aber genug davon.
Schliesslich will ich Python nicht schlecht machen, dazu nutze ich
es zu gerne  :-| .

>  Geh einfach davon aus, dass
> es in deiner Lebenszeit auch nicht passieren wird.

OK,   _das_   ist mal eine Aussage.
Das beantwortet meine Frage.

> > Wisst Ihr hier schon mehr ueber diese Aeusserungen ?
> 
> Damit bist du einen Tag zu spaet dran.

*banginghandonhead*
Sorry, aber in Kenntnis der UML-Historie  und diversen Joints 
neulich (ich meine jetzt Zusammenschluessen  :-)  ),  glaube ich 
(fast) alles.

Bye

Dirk Detering  - aka Det




More information about the Python-de mailing list