mal grundsaetzlich: python vs. php...etc

[iujm]

ahoi und guten tag...
ich komme aus der c++/php ecke und moechte mich jetz noch
naeher mit einer weitern sprache beschaeftigen.
ruby finde ich ganz toll, aber das ist noch sowenig verbreitet auf den
servern.
wie ist es eigendlich mit python?
was sind die vorteieln gegenueber zb. php? fuer welche probleme/loesungen eignet sich python ganz besonders, fuer welche nich?
wie ist es mit sql (postrge und mysql)
kann python auch standalone?

fragen ueber fragen

[zotikus]

erst hatte ich ein problem mit einer
invalid session, musste den beitrag nochmal schreiben,
dann sagt das forum mir: benutztername is schon weg,
muste mich neu einloggen, dann ging es..
komisch..diese bb boards sind doch sonst ziemlich fehlerfrei??
viellecht bin ich ja uach zu doff..
naegal

ahoi und guten tag...
ich komme aus der c++/php ecke und moechte mich jetz noch
naeher mit einer weitern sprache beschaeftigen.
ruby finde ich ganz toll, aber das ist noch sowenig verbreitet auf den
servern.
wie ist es eigendlich mit python?
was sind die vorteieln gegenueber zb. php? fuer welche probleme/loesungen eignet sich python ganz besonders, fuer welche nich?
wie ist es mit sql (postrge und mysql)
kann python auch standalone?

fragen ueber fragen

[Aron Squander]

Also, für php brauchst du immer einen Server, für python nicht.
Das wichtigste an python ist aber eigentlich, das man die sprache in ihrer ganzen mächtigkeit sehr schnell verstehen kann. Das ist natürlich ideal für das, wofür python auch gedacht ist: Rapid Prototyping. Entwicklungszeit für Projekte ist einfach extrem klein...
Greetings
Aron

[DER Olf]

von was sprichst du?
cgi????
sonst is python eine programmiersprache, die auf dem system läuft wie jede andere auch, nur einfach zu verstehen.

[Milan]

Hi. Also Python ist eine schöne einfache, aber mächtige Sprache. Da man immer mit dem guten anfängt, tu ich das auch mal:
- Python hat im Gegensatz zu PHP ein sehr einfaches Konzept für OOP
- die Sprache ist minimalistisch, also es ist so wenig wie nötig eingebaut, aber du wirst trotzdem nix missen, da es zig Module gibt.
- in geschwindigkeitskritischen Teilen kannst du auf C umsteigen, dir dort was basteln und diesen Code dann aus Python heraus importieren (mit entsprechender Geschwindigkeit)

Python ist allerdings minimalistisch (was ich gutheiße). Das heißt, es ist so wenig wie nötig integriert. Die meiste Funktionalität steckt in der OOP und in den Modulen von Python. MySQL wirst du allerdings nachrüsten müssen, es existiert ein Modul für den Zugriff (MySQLdb), was aber nicht integriert ist.

Noch mehr Informationen findest du hier, da wurde schon mal was ähnliches gefragt...

Milan

[murphy]

also ich bin immer noch absoluter Ruby-fan.
Python finde ich dennoch sehr sympatisch und modern.

interessant, wenn auch etwas alt, ist folgender post:
gekürzter Link
ich las das und fand es ziemlich übertrieben pro-Ruby...und zum teil nicht korrekt.
wie auch immer, der urheber ist (war?) Python-programmierer und ich bin ziemlich erstaunt.

ich kenne bisher keinen Ruby-programmierer, der Python besonders mag...dauernd wird über "die sache mit den indents" gestritten.
aber davon abgesehen: der einzige vorteil, den ich bisher (1 woche )gesehen habe: Python ist erstaunlich schnell, gerade was schleifen und strings angeht.

gibt es hier jemanden, der beide sprachen gut genug kennt und die vorteile von Python gegenüber Ruby mal beschreiben kann?

[Dookie]

Hi murphy,

ich kenn ja nun einige Programmiersprachen und habe im Laufe der Zeit auch in vielen gecodet. Ruby habe ich mir natürlich auch schon angeschaut, kann mich aber mit einigen Sachen dort nicht wirkich anfreunden.
1. das leidige end bei Blöcken, ich rücke Blöcke schon immer ein, ausser bei Basic und Assembler, die das nicht vertragen. Gerade das bei Python Blöcke durch die Einrückung definiert sind fand ich von Anfang an schön
2. daß man bei Methoden vor dem Namen bei der Deklaration nochmal den Klassennamen angeben muss.
3. die in vielen Fällen sehr Perlartige Syntax von Ruby hat mich auch abgeschreckt, wie damals als ich eine Sprache für Websachen suchte und zum Glück nach Perl dann PHP entdeckte.
4. keine Möglichkeit von Mehrfachvererbung unter Ruby. Ich vermeide Mehrfachvererbung zwar nach Möglichkeit, aber manchmal ist es sehr praktisch ein Objekt von str und einer anderen Klasse abzuleiten.

Dem Text in dem Link merkt man sein Alter wirklich an. Dort wird gesagt daß bei Ruby eben alles ein Objekt ist. Seit Python Version 2.1 gilt das auch für Python.
Einen Vorteil sehe ich auch darin, daß ich bei Python frei bin imperativ, funktional oder objektorientiert zu programmieren und das innerhalb eines Scripts, so wie es die Problemstellung eben erfordert.


Gruß

Dookie

[mitsuhiko]

Der Vorteil von Python ist, dass du im Gegensatz zu PHP Module auf einem Webserver selbst nachrüsten kannst, auch wenn du keine Shell hast.

[Sorgenkind]

Noch ein unterschied von ruby und python:

Bei Python gilt "explicit is better than implecit"... das hast du bei ruby nie...

A.b ist das gleiche wie a.b() in ruby zb... finde ich persönlich nicht so toll und bin deswegen u.a. pythonanhänger...

ruby ist auch um einiges langsamer als python... und gegen python+psyco sieht es total alt aus...

und @topic
zu php sag ich nur quick&dirty

[Leonidas]

zu php sag ich nur quick&dirty

Jep. Python hat eine klare Struktur und OOP auch wenn die Ruby Leute uns sagen wollen dass das nicht so ist *g*.
Aber Ruby kann afaik auch eine Art Mehrfachvererbung durch sogenannte Mixins, von denen murphy uns sicher einiges erzählen kann.

Ich hatte die Wahl zwischen Python weiterlernen und es auch auf Webseiten einzusetzen, obwohl kaum Hoster Python anbieten, oder PHP. Aber in PHP hab ich es nur zusammengebracht ein kleines Newssystem zu schreiben, und danach habe ich festgestellt das mir PHP nicht wirklich gefällt. Seit dem nurtze ich auch für Webseiten Spyce und bin froh drüber.

[murphy]

1. das leidige end bei Blöcken

wie immer der erster und wichtigster punkt für alle Python-programmierer ich finde das ein wenig kindisch, weil es wichtigere dinge gibt als ein paar eingesparte end's. warum muss Python so was experimentelles haben?
da ich meine bisherigen bedenken zu nichtredundanten indents (oder wie nennt ihr das?) nicht einfach kopieren will, link zum thread im Ruby-forum:
http://www.rubyforen.de/ptopic,2191.html#2191
kritik erwünscht aber ich glaube, wir sollten uns auf wichtigere kriterien konzentrieren.

2. daß man bei Methoden vor dem Namen bei der Deklaration nochmal den Klassennamen angeben muss.

muss man nicht. was du meinst, ist vermutlich folgendes:

Code: Alles auswählen

class Foo
	def Foo.bar
		...

das ist eine klassenmethode (was mir in Python leider fehlt.) normalerweise benutzt man instanzmethoden, genau wie in Python:

Code: Alles auswählen

class Foo
	def bar
		...

kein Foo nötig.

3. die in vielen Fällen sehr Perlartige Syntax von Ruby hat mich auch abgeschreckt, wie damals als ich eine Sprache für Websachen suchte und zum Glück nach Perl dann PHP entdeckte.

ja, Ruby kann fast wie Perl aussehen, wenn du magst. es kann auch (semantisch) wie Smalltalk aussehen. oder wie Haskell oder Delphi oder Python. das ist die freiheit von Ruby.
Matz (Erfinder von Ruby) mochte an Perl vor allem die möglichkeit, einfache dinge ganz kurz hinzuschreiben. Perl erkauft sich das mit z.T. grausligem zeichenwust, Ruby dämmt diesen wust ein und packt alles in eine solide OO-struktur: /Regexps/, $1, if-modifier können den code lesbarer machen, wenn man sie gut einsetzt. darum gibt es sie auch in Ruby. im unterschied zu Python wollte man bei Ruby ganz klar auch Perl-ideen weiterentwickeln.
PHP ist auch nicht ganz frei von allen Perl-kürzeln, aber dafür frei von gutem design leider muss ich trotzdem da drin programmieren!

4. keine Möglichkeit von Mehrfachvererbung unter Ruby. Ich vermeide Mehrfachvererbung zwar nach Möglichkeit, aber manchmal ist es sehr praktisch ein Objekt von str und einer anderen Klasse abzuleiten.

Aber Ruby kann afaik auch eine Art Mehrfachvererbung durch sogenannte Mixins, von denen murphy uns sicher einiges erzählen kann.

das ist ein größeres thema. falls Dookie mit "von str ableiten" meint, dass das objekt fähigkeiten von einer anderen Klasse übernehmen soll: genau das tun mixins. ein paar infos hier:
http://www.approximity.com/rubybuch2/node72_main.html
http://www.rubygarden.org/faq/section/show/8
@Dookie: bitte poste mal ein beispiel für eine sinnvolle mehrfachvererbung.

Dem Text in dem Link merkt man sein Alter wirklich an. Dort wird gesagt daß bei Ruby eben alles ein Objekt ist. Seit Python Version 2.1 gilt das auch für Python.

sind klassen objekte? was ist mit true, null oder 0? kann ich sie auch syntaktisch als objekte behandeln, also 0.abs() oder null.__str__() ? ich kenne Python leider nicht gut genug.

Einen Vorteil sehe ich auch darin, daß ich bei Python frei bin imperativ, funktional oder objektorientiert zu programmieren und das innerhalb eines Scripts, so wie es die Problemstellung eben erfordert.

genau das kann man in Ruby auch. beim funktionalen gibt's defizite, das stimmt, aber ich habe gehört, dass Python's lambda auch seine grenzen hat.

Python hat eine klare Struktur und OOP auch wenn die Ruby Leute uns sagen wollen dass das nicht so ist *g*.

Python ist mit sicherheit klarer als Perl und objektorientierter als C++.

ich finde die tendenz von Python zu funktionen (damit meine ich alles, was keinen empfänger hat wie len) nicht sinnvoll...warum nicht "test".len()?
noch was: die zwingenden klammern bei funktionen verhindern schöne methodenreihen, wie sie in Ruby allgegenwärtig sind:

Code: Alles auswählen

input = DATA.read.split "----\n"

(ähnlicher gedankengang wie bei unix-befehlen, nur OO.) wozu diese klammern?

[murphy]

A.b ist das gleiche wie a.b() in ruby zb... finde ich persönlich nicht so toll

was meinst du damit? dass die klammern optional sind?

ach noch ein wenig selbstkritik, damit das ganze nicht zum glaubenskrieg ausartet:
http://www.rubyist.net/~matz/slides/rc2 ... 00004.html

[Milan]

A.b ist das gleiche wie a.b() in ruby zb... finde ich persönlich nicht so toll

was meinst du damit? dass die klammern optional sind?

Jo. Bei dem Code siehst du den Unterschied:

Code: Alles auswählen

class A:
    x=1
    def xy(self):
        return self.x

a=A()
#Methode aufrufen und Methode zurückgeben sind 2 Dinge
print a.xy()
print a.xy
print (lambda f:f())(a.xy)
#Attribute gibts auch noch
print a.x

Es gibt in meinen Augen keinen Unterschied zwischen Methoden, Methodenaufrufen und Attributen.

[Dookie]

Hi Murpy,

1. das leidige end bei Blöcken

wie immer der erster und wichtigster punkt für alle Python-programmierer ich finde das ein wenig kindisch, weil es wichtigere dinge gibt als ein paar eingesparte end's. warum muss Python so was experimentelles haben?
da ich meine bisherigen bedenken zu nichtredundanten indents (oder wie nennt ihr das?) nicht einfach kopieren will, link zum thread im Ruby-forum:
http://www.rubyforen.de/ptopic,2191.html#2191
kritik erwünscht aber ich glaube, wir sollten uns auf wichtigere kriterien konzentrieren.

Naja, das war das erste was mir bei Python positivermassen aufgefallen ist. Ich hab früher viel in Modula2 und Oberon2 gemacht, da waren auch die begin...end nötig, ich hab mir dann auf eine Tastenkombi ein Macro gelegt, daß mir das tippen von begin...end ersparte

2. daß man bei Methoden vor dem Namen bei der Deklaration nochmal den Klassennamen angeben muss.

muss man nicht. was du meinst, ist vermutlich folgendes:

Code: Alles auswählen

class Foo
	def Foo.bar
		...

das ist eine klassenmethode (was mir in Python leider fehlt.) normalerweise benutzt man instanzmethoden, genau wie in Python:

Code: Alles auswählen

class Foo
	def bar
		...

kein Foo nötig.

Aha, bei den Beispielen die ich zu Ruby fand, waren alle Methoden wie Foo.bar definiert

3. die in vielen Fällen sehr Perlartige Syntax von Ruby hat mich auch abgeschreckt, wie damals als ich eine Sprache für Websachen suchte und zum Glück nach Perl dann PHP entdeckte.

ja, Ruby kann fast wie Perl aussehen, wenn du magst. es kann auch (semantisch) wie Smalltalk aussehen. oder wie Haskell oder Delphi oder Python. das ist die freiheit von Ruby.
Matz (Erfinder von Ruby) mochte an Perl vor allem die möglichkeit, einfache dinge ganz kurz hinzuschreiben. Perl erkauft sich das mit z.T. grausligem zeichenwust, Ruby dämmt diesen wust ein und packt alles in eine solide OO-struktur: /Regexps/, $1, if-modifier können den code lesbarer machen, wenn man sie gut einsetzt. darum gibt es sie auch in Ruby. im unterschied zu Python wollte man bei Ruby ganz klar auch Perl-ideen weiterentwickeln.
PHP ist auch nicht ganz frei von allen Perl-kürzeln, aber dafür frei von gutem design leider muss ich trotzdem da drin programmieren!

dito

4. keine Möglichkeit von Mehrfachvererbung unter Ruby. Ich vermeide Mehrfachvererbung zwar nach Möglichkeit, aber manchmal ist es sehr praktisch ein Objekt von str und einer anderen Klasse abzuleiten.

Aber Ruby kann afaik auch eine Art Mehrfachvererbung durch sogenannte Mixins, von denen murphy uns sicher einiges erzählen kann.

das ist ein größeres thema. falls Dookie mit "von str ableiten" meint, dass das objekt fähigkeiten von einer anderen Klasse übernehmen soll: genau das tun mixins. ein paar infos hier:
http://www.approximity.com/rubybuch2/node72_main.html
http://www.rubygarden.org/faq/section/show/8
@Dookie: bitte poste mal ein beispiel für eine sinnvolle mehrfachvererbung.

ok, da überleg ich mir mal was.

Dem Text in dem Link merkt man sein Alter wirklich an. Dort wird gesagt daß bei Ruby eben alles ein Objekt ist. Seit Python Version 2.1 gilt das auch für Python.

sind klassen objekte? was ist mit true, null oder 0? kann ich sie auch syntaktisch als objekte behandeln, also 0.abs() oder null.__str__() ? ich kenne Python leider nicht gut genug.

Einen Vorteil sehe ich auch darin, daß ich bei Python frei bin imperativ, funktional oder objektorientiert zu programmieren und das innerhalb eines Scripts, so wie es die Problemstellung eben erfordert.

genau das kann man in Ruby auch. beim funktionalen gibt's defizite, das stimmt, aber ich habe gehört, dass Python's lambda auch seine grenzen hat.

Python hat eine klare Struktur und OOP auch wenn die Ruby Leute uns sagen wollen dass das nicht so ist *g*.

Python ist mit sicherheit klarer als Perl und objektorientierter als C++.

ich finde die tendenz von Python zu funktionen (damit meine ich alles, was keinen empfänger hat wie len) nicht sinnvoll...warum nicht "test".len()?
noch was: die zwingenden klammern bei funktionen verhindern schöne methodenreihen, wie sie in Ruby allgegenwärtig sind:

Code: Alles auswählen

input = DATA.read.split "----\n"

(ähnlicher gedankengang wie bei unix-befehlen, nur OO.) wozu diese klammern?

Code: Alles auswählen

input = DATA.read().split("\n")

geht natürlich auch in Python. Die Klammern zeigen das es eben ein Methodenaufruf ist und nicht die Methode. Du kannst ja z.B. bei GUI-Programmierung auch eine Methode an eine Widgetaktion binden.
Hier braucht man die Unterscheidung, ob der Rückgabewert der Funktion oder die Funktion selbst als Parameter gemeint ist.
Methoden sind bei Python eben auch nur Attribute einer Instanz. So kannst Du z.B. in Python mit

Code: Alles auswählen

if hasattr(foo, "write"):
    ...

testen ob foo eine write-Methode hat oder nicht.

Gruß

Dookie

[Leonidas]

1. das leidige end bei Blöcken

wie immer der erster und wichtigster punkt für alle Python-programmierer ich finde das ein wenig kindisch, weil es wichtigere dinge gibt als ein paar eingesparte end's. warum muss Python so was experimentelles haben?

Dafür benehmen sich die Ruby Leute kindisch wenn wie probleme haben Python Code aus einer Seite zu kopieren, also mit null Einrückungen und null Lesbarkeit. Und das Indenting ist gar nicht so experimentell, das ist einfach mal anders, und ausserdem ist Python nicht die erste Sprache die sowas macht.

da ich meine bisherigen bedenken zu nichtredundanten indents (oder wie nennt ihr das?) nicht einfach kopieren will, link zum thread im Ruby-forum:
http://www.rubyforen.de/ptopic,2191.html#2191
kritik erwünscht aber ich glaube, wir sollten uns auf wichtigere kriterien konzentrieren.

Ok, schluss damit hier.

ja, Ruby kann fast wie Perl aussehen, wenn du magst. es kann auch (semantisch) wie Smalltalk aussehen. oder wie Haskell oder Delphi oder Python. das ist die freiheit von Ruby.
Matz (Erfinder von Ruby) mochte an Perl vor allem die möglichkeit, einfache dinge ganz kurz hinzuschreiben. Perl erkauft sich das mit z.T. grausligem zeichenwust, Ruby dämmt diesen wust ein und packt alles in eine solide OO-struktur: /Regexps/, $1, if-modifier können den code lesbarer machen, wenn man sie gut einsetzt. darum gibt es sie auch in Ruby. im unterschied zu Python wollte man bei Ruby ganz klar auch Perl-ideen weiterentwickeln.

In der Entwicklung von Python hat man warscheinlich gedacht, das viele Perl Ideen zu Perlartigem Code führen. Man hat eigentlich auch weniger auf Perl geschaut, sondern eine neue Sprache gemacht. Wenn man hätte Perl verbessern wollen, dann hätte man ja nicht eine neue Sprache gemacht sondern an Perl6 mitgemacht.

PHP ist auch nicht ganz frei von allen Perl-kürzeln, aber dafür frei von gutem design leider muss ich trotzdem da drin programmieren!

Mich bringt inzwischen nichts freiwillig zu PHP.

das ist ein größeres thema. falls Dookie mit "von str ableiten" meint, dass das objekt fähigkeiten von einer anderen Klasse übernehmen soll: genau das tun mixins. ein paar infos hier:
http://www.approximity.com/rubybuch2/node72_main.html
http://www.rubygarden.org/faq/section/show/8
@Dookie: bitte poste mal ein beispiel für eine sinnvolle mehrfachvererbung.

Ja, genau das kann man seit neueren Python Versionen. Genau so werden auch New Style Klassen gemacht: durch vererben von Object. Man kann in Python inzwischen von jedem Typ erben. Warum fragst du um sinnvolle beispiele, wenn du dir einfach die sinnvollen Mixin Beispiele nehemen kannst?

sind klassen objekte? was ist mit true, null oder 0? kann ich sie auch syntaktisch als objekte behandeln, also 0.abs() oder null.__str__() ? ich kenne Python leider nicht gut genug.

Code: Alles auswählen

>>>type(true)
<type 'bool'>
>>>class mybool(bool):
>>>    pass
>>>
>>>type(null)
NameError: name 'null' is not defined
>>>type(0)
<type 'int'>
>>>class myint(int):
>>>    pass
>>>

Es ist auch kein Problem sogar von NameError zu erben. Das könnte dir gefallen:

Code: Alles auswählen

>>>"abc".upper()
ABC

Wenn du möchtest kannst du auch von int erben und eine upper() Methode machen, blos Sinn macht das halt keinen

ich finde die tendenz von Python zu funktionen (damit meine ich alles, was keinen empfänger hat wie len) nicht sinnvoll...warum nicht "test".len()?

Gute Frage, warum nicht? Das haben sich auch die Python Entwickler gedacht, deswegen macht len() genau das:

Code: Alles auswählen

>>>len('abc')
3
>>>'abc'.__len__()
3

Du siehst also das len() __len__() aufruft, das kannst du dann auch in deinen Klassen definieren und auch deine Klassen funktionieren dann mit len().[/python]

[murphy]

Es gibt in meinen Augen keinen Unterschied zwischen Methoden, Methodenaufrufen und Attributen.

Ruby hat, wie Smalltalk, keine attribute. instanzvariablen sind nur innerhalb der klasse verfügbar und beginnen mit @. zugriffsmethoden gehen per attr_reader & friends. alles ist ein objekt, objekte haben nach außen nur methoden. vorteil: kapselung; nachteil: ein wenig mehr schreibarbeit
ich verstehe bei deinem code gar nicht, zu was das x jetzt gehört. wann/wie oft wird x 1 zugewiesen? zu wem gehört x?

zu methoden ohne (): wie oft schreibt ihr () ohne inhalt? und wie oft braucht ihr die methoden selbst?
ich finde es gar nicht so schlimm, dass man in Ruby etwas mehr schreiben muss:

Code: Alles auswählen

foo.bar  # methodenaufruf
foo.method(:bar)  # methode

habe das noch nie gebraucht. musste erst in der doku nachschauen.
funktionale elemente (funktionen als parameter übergeben etc.) fallen in Ruby meist gar nicht auf, da vieles über codeblöcke läuft:

Code: Alles auswählen

[1, 2, 3].map { |x| x*x }

for-schleifen, mappings, closures, iteratoren, funktionen höherer ordnung sind in Ruby alle ein und dasselbe (semantisch).
die redundanten klammern sind ganz grundlegend für Rubys syntax-logik. print zB ist ja auch nur eine methode...da hat ja auch Python keine klammern.

Aha, bei den Beispielen die ich zu Ruby fand, waren alle Methoden wie Foo.bar definiert

sehr seltsam. falls du mal schöneren code sehen willst, hier die appetithappen, die mich dazu gebracht haben, das buch zu kaufen und Ruby zu lernen:
http://www.approximity.com/rubybuch2/node8.html

So kannst Du z.B. in Python mit

Code: Alles auswählen

if hasattr(foo, "write"):
    ...

testen ob foo eine write-Methode hat oder nicht.

(hasattr? write ist ein attribut?)
in Ruby geht das natürlich auch:

Code: Alles auswählen

if foo.respond_to :write
  ...

und wieder die frage: warum ist hasattr keine methode von foo? das nette foo weiß doch selber am besten, ob es write kann.
lass mich raten: __hasattr__()?

Man kann in Python inzwischen von jedem Typ erben. Warum fragst du um sinnvolle beispiele, wenn du dir einfach die sinnvollen Mixin Beispiele nehemen kannst?

module einzumischen und von klassen zu erben sind verschiedene dinge.

Code: Alles auswählen

>>>type(true)
<type 'bool'>
>>>type(0)
<type 'int'>
>>>class myint(int):'

geht auch int.methods() oder type(var) == int?

was benutzt man eigentlich in Python statt null oder nil? irgendein "nicht definiert" muss es doch geben...

Gute Frage, warum nicht? Das haben sich auch die Python Entwickler gedacht, deswegen macht len() genau das:

Code: Alles auswählen

>>>len('abc')
3
>>>'abc'.__len__()
3

Du siehst also das len() __len__() aufruft, das kannst du dann auch in deinen Klassen definieren und auch deine Klassen funktionieren dann mit len().

meine frage bleibt: warum kein 'abc'.len()? wieso dieser seltsame umweg über __len__? das erweckt den eindruck, man würde mit einer definition von __len__ geheimnisvolle dinge tun, die Python unglaublicherweise ermöglicht. upper() ist doch auch eine echte methode (weil ja upper('abc') auf __upper__() umgeleitet wird.)
warum nicht auch len? ich will es ja nicht ändern, ich will bloß wissen, warum len() anders sein soll. die erfinder müssen sich doch was dabei gedacht haben.

von del fange ich lieber gar nicht erst an, das ist ja offenbar sogar ein keyword

[Leonidas]

zu methoden ohne (): wie oft schreibt ihr () ohne inhalt? und wie oft braucht ihr die methoden selbst?

Oft, weniger oft. Aber du willst einmal OO so pur wie möglich und dann ist dir () egal.

module einzumischen und von klassen zu erben sind verschiedene dinge.

Ich sag ja das ich Mixins nicht verstehe

geht auch int.methods() oder type(var) == int?

Ja, seit Python 2.3 schon, vorher musste man halt type(0) oder type(int()) machen.

was benutzt man eigentlich in Python statt null oder nil? irgendein "nicht definiert" muss es doch geben...

Gibt es auch: None. Das wird inzwischen langsam zur einzigen Konstante von Python, denn beim Zuweisen von Werten an None gibt es SyntaxWarnings, die später sicher zu Errors werden.

meine frage bleibt: warum kein 'abc'.len()? wieso dieser seltsame umweg über __len__? das erweckt den eindruck, man würde mit einer definition von __len__ geheimnisvolle dinge tun, die Python unglaublicherweise ermöglicht. upper() ist doch auch eine echte methode (weil ja upper('abc') auf __upper__() umgeleitet wird.)
warum nicht auch len? ich will es ja nicht ändern, ich will bloß wissen, warum len() anders sein soll. die erfinder müssen sich doch was dabei gedacht haben.

Hmm, ich nehme halt einfach das ist auch für irgendeinen internen Spass gedacht, da Python wirklich mit den __ Funktionen unglaubliche Dinge macht. Ich nahme mal an das irgendeine von diesen unglaublichen __ Funktionen auf __len__ zurückgreift, aber keine auf upper zugreift.

von del fange ich lieber gar nicht erst an, das ist ja offenbar sogar ein keyword

Ja, kannst es aber auch als Funktion verwenden. Genauso wie print ein Keyword zu sein scheint. In meiner irb kann ich ja auch print 'abc' aufrufen, ohne probleme. Und in ipython kann ich sogar len als Keyword verwenden

[Dookie]

Nö, ein __hasattr__ gibts nicht, wie und wo Attribute gesucht und gefunden werden hängt ab ob es sich um newstyle- oder oldstyle-Klassen handelt. Bei oldstyle stehen alle Attribute in __dict__. Bei newstyle stehen die Namen von Attributen in __slots__, die Methoden sind extra definiert und dann gibts noch Properties, damit lassen sich Pseudoattribute definieren die z.B. Zur Laufzeit berechnet werden, oder auch readonly-Attribute lassen sich mit Properties verwirklichen.
Daß len eine Funktion ist, hat bei Python historische gründe, in den ersten Pythonversionen war eben noch nicht alles Objektorientiert. len() gibt ja nicht nur die Länge von Strings sondern auch von Listen, Tuples, Dictionaries und sogar von xrange-Objekten zurück. Es gibt ja auch noch (aus historischen Gründen) das modul strings, das aber praktisch kaum noch gebraucht wird.

Ausser None gibts auch noch die Konstanten True und False, die auch die einzigen Instanzen von bool sind.


Gruß

Dookie

[Milan]

Es gibt in meinen Augen keinen Unterschied zwischen Methoden, Methodenaufrufen und Attributen.

Ruby hat, wie Smalltalk, keine attribute. instanzvariablen sind nur innerhalb der klasse verfügbar und beginnen mit @. zugriffsmethoden gehen per attr_reader & friends. alles ist ein objekt, objekte haben nach außen nur methoden. vorteil: kapselung; nachteil: ein wenig mehr schreibarbeit
ich verstehe bei deinem code gar nicht, zu was das x jetzt gehört. wann/wie oft wird x 1 zugewiesen? zu wem gehört x?

Naja, x ist nun hier ein Klassenattribut, also eine Attribut, auf das alle Instanzen denselben Zugriff haben und Identität vorherrscht (zumindest bei Newstyle Klassen). Ist bei Konstanten sinnvoll, bei mutable Objects ist es sinnvoller bei der Initialisierung ein self.x= ... zu schreiben.

zu methoden ohne (): wie oft schreibt ihr () ohne inhalt? und wie oft braucht ihr die methoden selbst?
ich finde es gar nicht so schlimm, dass man in Ruby etwas mehr schreiben muss:

Code: Alles auswählen

foo.bar  # methodenaufruf
foo.method(:bar)  # methode

habe das noch nie gebraucht. musste erst in der doku nachschauen.

Methoden selbst brauche ich nicht oft, aber Funktionen. Das fällt dir wahrscheinlich in ruby nicht so auf, da alles mehr auf OO hinausläuft. Außerdem ist es für mich persöhnlich lesbarer, wenn man Klammern schreibt, vor allem wenn die Funktionen/Methoden optionale Argumente oder Keywords haben. In Ruby kann man doch aber wenigstens trotzdem Klammern setzen, oder?

print zB ist ja auch nur eine methode...da hat ja auch Python keine klammern.

Das ist ein Spezialfall, ich sehe es mehr als statement (print ! ), deswegen. Du kannst auch sys.stdout.write(...) schreiben, wenn du das lieber magst .

Code: Alles auswählen

>>>type(true)
<type 'bool'>
>>>type(0)
<type 'int'>
>>>class myint(int):'

geht auch int.methods() oder type(var) == int?

Was leistet int.methods? Wenn du eine Übersicht über alle Attribute haben willst rufst du dir(obj) und wenn du wissen willst obs Methoden sind rufst du callable(obj). Das hat hier wieder den Sinn, dass man auch Methoden als Attribute ansehen kann und grundsetzlich wieder als Argumente verwenden kann. Und ja, type(0)== int oder type(0) is int geht.

was benutzt man eigentlich in Python statt null oder nil? irgendein "nicht definiert" muss es doch geben...

Nimm stattdessen None.

Gute Frage, warum nicht? Das haben sich auch die Python Entwickler gedacht, deswegen macht len() genau das:

Code: Alles auswählen

>>>len('abc')
3
>>>'abc'.__len__()
3

Du siehst also das len() __len__() aufruft, das kannst du dann auch in deinen Klassen definieren und auch deine Klassen funktionieren dann mit len().

meine frage bleibt: warum kein 'abc'.len()? wieso dieser seltsame umweg über __len__? das erweckt den eindruck, man würde mit einer definition von __len__ geheimnisvolle dinge tun, die Python unglaublicherweise ermöglicht.

Naja, Objekte die eine Länge haben waren früher halt nur einige Builtin Typen. Wie das nun gekommen ist weiß ich nicht, aber vom Effekt her ist es mir egal wie ich es rufe. Es geht halt und da lege ich nicht direkt Wert darauf. Wer möchte kann ja wieder self.len=self.__len__ definieren . Nein, kleiner Spaß... Das ist in meinen Augen im Zusammenhang zur restlichen Philosophie zu sehen, wo alle Operatoren und Funktionen auf diese Weise in eigenen Klassen implementiert werden, dann machts schon wieder Sinn.

von del fange ich lieber gar nicht erst an, das ist ja offenbar sogar ein keyword

Richtig. Da macht es aber wirklich Sinn, denn del hat mehr als eine Bedeutung. Du kannst damit sowohl Referenzen auf Variablen vernichten als auch einzelne Elemente in Listen oder Dictionarys löschen.


Ich bin gerade dabei die Diskussion im Rubyforum zu lesen. Hochinteressant, muss ich sagen. OO mäßig ist Ruby Python wohl an Eleganz etwas voraus, aber allein deswegen würde ich nicht unbedingt umsteigen. Dafür brauchts bei mir doch noch ein wenig mehr, denn ich programmiere eher funktional, modular und lege Wert auf Iteratoren wo ich kann. Wie sieht es damit in Ruby aus? Gibt es auch sowas wie yield? Sowas wie Generator Expressions?

[mawe]

Hi!

Gibt es auch sowas wie yield? Sowas wie Generator Expressions?

Hihi! Klar gibt's bei Ruby yield. Das hat Python ja von Ruby geklaut Naja, jedenfalls war's bei Ruby schon vor Python da. List Comprehension und Generator Expression (gibt's doch erst in 2.4, oder?) sind Dinge die ich in Ruby schmerzlich vermisse.

Gruß, mawe