Das deutsche Python-Forum

blackbird hat geschrieben:Der Nachteil ist eben, dass man "alle Argumente" übergeben muss. Ich kann nicht sagen, übergibt parameter 1-3 normal, parameter 4-9 auslassen, 11 und 13 übergeben wir als keyword arg.

stimmt. hier bestimmt der entwickler der methode, welche argumente wie übergeben werden. (there should be one way to do it?)

Die Diskussion hatten wir vor kurzem in #python.de. Hier mal ein kurzer Einwurf:

Code: Alles auswählen

>>> class A(object): pass
...
>>> class B(object): pass
...
>>> def stub(self):
...     print self
...
>>> A.test = stub
>>> B.test = A.test
>>> A().test()
<__main__.A object at 0xb7d2632c>
>>> B().test()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unbound method stub() must be called with A instance as first argument (got nothing instead)

Das funktioniert dank explizitem self wunderbar.

da komme ich nicht mit. warum klappt das so nicht?

Und die Core Devs überraschen jedes Release mit tollen neuen Features

ich wünschte, es gäbe auch neuigkeiten in Ruby

murphy hat geschrieben:

blackbird hat geschrieben:

2.) end <-- da sind mir die einrückungen lieber

die vorteile von blockschlüsselworten haben offenbar für die entwickler praktisch jeder anderen sprache überwogen

Ist die Frage was diese Vorteile sind. Der Hauptvorteil dürfte sein, dass man einfacher eine (mehr oder weniger) kontextfreie Grammatik für den Parser so einer Sprache schreiben kann. Das wäre dann also ein Vorteil für den, der die Sprache implementiert. Die Entwickler von praktisch jeder anderen Sprache sind also einfach nur zu faul.

Der Hauptvorteil dürfte sein, dass man einfacher eine (mehr oder weniger) kontextfreie Grammatik für den Parser so einer Sprache schreiben kann.

Eine kontextfreie Grammatik für Python zu schreiben ist auch ohne weiteres möglich, wenn der Lexer ein bisschen intelligent ist (sprich vor allen Dingen Whitespace-Tokens nicht als ein Token, sondern als mehrere Whitespace-Tokens liefert, je nach Einrückung, sozusagen INDENT für einen Block, INDENT - INDENT für zwei, usw.). Ich muß mal schauen ob ich die ausgraben kann, aber ich hab eine mehr oder weniger vollständige LR(1)-Grammatik für Python in dieser Form geschrieben.

Wobei natürlich ein Teil des Blockchecks in der semantischen Phase versteckt ist.

BlackJack hat geschrieben:Die Entwickler von praktisch jeder anderen Sprache sind also einfach nur zu faul.

das ist nicht wahr. die gründe für redundante einrückungen und explizite end-tags liegen woanders.

es mag sein, dass das aus sicht der community eines der beliebtesten features von Python ist. fakt ist, dass praktisch jeder, der Python ablehnt, als erstes dieses argument anbringt. obwohl das lächerlich ist.

murphy hat geschrieben:fakt ist, dass praktisch jeder, der Python ablehnt, als erstes dieses argument anbringt. obwohl das lächerlich ist.

Gut das wir uns da einig sind. Denn dieses Argument hört sich für mich so typisch nach: "Kenn ich nicht, mag ich nicht" an. Es gibt Fälle wo das manchmal nervt, aber geschweifte Klammern nerven viel öfter.

Aber das ist eben so ein Problem, dass die Leute ihre Meinung schon vorher haben, ohne sind mit der Sprache auseinanderzusetzen (in Ruby ebenso wie in Python). "Ach, Ruby ist nur eine Skriptsprache..."

Ich werd mal etwas für Ruby 2 orakeln: Wenn die Leute anfangen zu vergleichen, dann werden sie immer Ruby 1.x mit Sprache X vergleichen, wie Ruby 2.x. Woher ich das weiß? Viele Vergleiche hängen nämlich bei Python 1.x fest und die Leute scheinen gar nicht gemerkt zu haben, das seitdem viele Jahre vergangen sind (oder sie haben alle vor jemanden abgeschrieben, der 1998 sich Python mal angesehen hat, was nichts positives über die Leute aussagt, die so Zeug immernoch quatschen).

Leonidas hat geschrieben:Ich werd mal etwas für Ruby 2 orakeln...

..., dass übrigens zusammen mit Hurd erscheint

*scnr*

Vor oder nach Perl 6

Es hat übrigens im neuesten Linux-Magazin gerade einen Artikel mit dem Titel:

Moderne Skriptsprachen im Vergleich

Wobei der "Vergleich" darin besteht, dass Perl, Ruby und Python nebeneinander gestellt werden, ohne gross etwas über die Unterschiede und deren Auswirkungen zu sagen. Ich verstehe ja, dass man sich als Magazin möglichst neutral verhalten muss, aber es gibt jetzt einmal Tatsachen, die man den Leuten nicht verschweigen sollte.

Ausserdem hat es noch einen Artikel über Ruby (Ruby-Workshop). Ich muss sagen mir persönlich gefällt die Sprache nicht. Sie ist zu sehr von Perl beeinflusst und hat diese ganzen mühsamen Sachen wie Klammern und begin/end (wie mittelalterlich) Anweisungen. Ausserdem ist die Syntax (wie bei Perl) für den Uneingeweihten völlig unverständlich, sobald es über eine Printanweisung heraus geht.

Schlussendlich muss ich sagen, dass ich müsste ich mich zwischen Ruby und Perl entscheiden müsste, sicher Ruby nehmen würde, da diese sicher weniger ein Flickwerk ist als Perl. Naja, mal schauen was wird. Vielleicht wird Perl 6 ja der oberhammer

Edit (Leonidas): An dieser Stelle schreit jemand "Kaaaaat!" und die Monteure beginnen das Threadmaterial zu schneiden. Rausgekommen ist ein Thread namens Gedanken zu Java und dieser ist übrig geblieben, nun ohne Outtakes. *g*

mal umgekehrt:

gibt es denn in Ruby irgendwas, was ihr gerne in Python hättet?
erzähl mir keiner, Python wäre perfekt!

Da wäre schon was: [wiki]Wunschliste[/wiki]
Wobei das nichts mit Ruby zu tun hat...

murphy hat geschrieben:mal umgekehrt:

gibt es denn in Ruby irgendwas, was ihr gerne in Python hättet?
erzähl mir keiner, Python wäre perfekt!

Rubyonrails? Obwohl, alles was in einer der grossen Scriptsprachen als grossartig empfunden wird, wird früher oder später auch für die anderen Sprachen implementiert. Von daher dürft dieser Bedarf normalerweise auf Ruby, Perl und Python Seite früher oder später immer gedeckt werden...

Und sonst gibt es ja bald parrot

Clython hat geschrieben:Rubyonrails? Obwohl, alles was in einer der grossen Scriptsprachen als grossartig empfunden wird, wird früher oder später auch für die anderen Sprachen implementiert. Von daher dürft dieser Bedarf normalerweise auf Ruby, Perl und Python Seite früher oder später immer gedeckt werden...

Siehe Routes:

Routes homepage hat geschrieben:Routes is a Python re-implementation of the Rails routes system for mapping URL's to Controllers/Actions and generating URL's.[/url]

Aber Ruby on Rails gibt es schon für Python, in zig Spielarten: TurboGears, Pylons, Django plus zig mehr oder weniger gute Workalikes wie Webware, Web.py, Python Web Modules etc.

Was gut wäre, wenn mal endlich Frameworks eingestampft werden würden, es sind inzwischen viel zu viele.

wenn Rails schon erwähnt wird: man kann offenbar all die meta-tricks, die in Rails drinstecken, nicht einfach so nach Python portieren. insofern fehlt also in Python schon ein wenig Ruby-magie; ganz besonders über singleton-methoden, erweiterung von basisklassen und blöcke (anonyme methoden , lambdas, ...) wird ja viel geredet. mixins sind auch noch ein thema - RoR ist voll davon.

die frage ist, ob jemand schonmal bedarf dafür gesehen hat, außerhalb von Rails-klonen. dass manche dinge einfach nicht "pythonic" sind, ist mir klar - aber das heißt ja nicht, dass man sie nicht nützlich sein können.

murphy hat geschrieben:insofern fehlt also in Python schon ein wenig Ruby-magie;

Das auch mit Absicht, denn Python ist eine Sprache die eher auf Magic verzichtet. So sieht es auch in den Projekten aus: Django beispielsweise hat gerade seine Magic entfernt und die Leute haben sich sehr darüber gefreut.

murphy hat geschrieben:ganz besonders über singleton-methoden,

Es gibt Singleton-Klassen.. ähm, ich meine Borg-Klassen.

murphy hat geschrieben:erweiterung von basisklassen

Dies war vor einiger Zeit (Python 2.1 oder so, also eigentlich vor langer Zeit) über einen Hack möglich, jedoch wurde dieser Hack dann entfernt. Es hätte scheinbar nicht dem Konzept entsprochen, wenn Programme ihre Basisklassen erweitern. So importiert man eine Lib, diese erweitert eine Basisklasse, man importirt noch eine, diese überschreibt die Erweiterung mit einenen Methoden und kabumm Nicht dass ich es nicht schon versucht hätte, das zu machen, letztendlich verstehe ich die Entscheidung der Python-Entwickler.

murphy hat geschrieben:und blöcke (anonyme methoden , lambdas, ...) wird ja viel geredet.

Ja, in Python 3000 sollte lambda abgeschafft werden. Nur ist keinem bis jetzt etwas besseres eingefallen, also wird es warscheinlich dabei bleiben. Ich nutze lambdas eigentlich nie, schon eher genistete Funktionen, obwohl ich die den Code ziemlich verworren machen. Jedoch will Python auch funktionalen Programmiersprachen entgegenkommen, zumindest soweit vertretbar.

murphy hat geschrieben:mixins sind auch noch ein thema - RoR ist voll davon.

Mixins - here we go

murphy hat geschrieben:die frage ist, ob jemand schonmal bedarf dafür gesehen hat, außerhalb von Rails-klonen.

Also ich nicht. Klar, es sind ganz lustige Features, aber ich kann bis jetzt auch gut ohne auskommen. Wenn man die aber gescheit implementiert, wer weiß. Inzwischen sind List Comprehensions auch schon Features geworden, die zwar nicht notwendig sind, aber doch Spaß machen und die ich gerne nutze.

murphy hat geschrieben:dass manche dinge einfach nicht "pythonic" sind, ist mir klar - aber das heißt ja nicht, dass man sie nicht nützlich sein können.

Ja. Jedoch muss man sich bei jeder Änderung an Python klar sein, dass jedes zusätzliche Feature den Python-Code komplizierter machen kann. Deswegen werden nur Features eingebaut, die wirklich, wirklich sinnvoll und durchdacht sind (okay meistens, nicht immer).