python vs. ruby (kein trolling)

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

mawe hat geschrieben:Naja, und wieso sollte das in Ruby nicht funktionieren?
Keine Ahnung, vielleicht meinte blackbird ja doch etwas anderes.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

mawe hat geschrieben:Naja, und wieso sollte das in Ruby nicht funktionieren?

Code: Alles auswählen

def gaga(a=2, b=3)
  puts a, b
end

gaga()
gaga(a=12, b=122)
Das ist aber neu oder? Als ich das letzte mal danach gesucht hab wurde eine Lösung über hashses vorgeschlagen, sie alles andere als fein war.
TUFKAB – the user formerly known as blackbird
mawe
Python-Forum Veteran
Beiträge: 1209
Registriert: Montag 29. September 2003, 17:18
Wohnort: Purkersdorf (bei Wien [Austria])

blackbird hat natürlich vollkommen recht. Erklärung siehe hier
murphy
User
Beiträge: 60
Registriert: Samstag 30. Oktober 2004, 01:34
Wohnort: Berlin
Kontaktdaten:

blackbird hat geschrieben:1.) fehlende keyword args (nein, hash ist kein ausweg)
warum nicht?
es stimmt, die funktionalität fehlt bisher und die diskussionen darüber, wie das in Ruby 2 aussehen soll, sind längst nicht beendet. allerdings benutzen Rails-entwickler den ganzen tag fröhlich keyword-argumente ohne probleme sieht dann so aus:

Code: Alles auswählen

start_form_tag :controller => '/entry',  :action => 'search'
gibt es einen anwendungsfall, der mit Ruby nicht ging? was hat dich gestört? vielleicht gibt es ja doch eine bessere lösung.
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 :)
Django arbeitet sogar mit "endfor" und sowas, was mich letztens extrem erschreckt hat. Rails benutzt einfach embedded Ruby als template-sprache.
kann aber gut sein, dass ich was nicht verstanden hab- kenne Django nicht.
3.) fehlendes "self". Ist zwar sicher anfänglich ungewohnt, aber es ist explizit und pythonic. Ist mir lieber als das "@" gefummel
und ich hab mich so bemüht, diese self vs. @-sache zu begraben ^^
was @-gefummel sein soll, kann ich jetzt aber nicht verstehen. bitte fakten :)
4.) fehlende dekoratoren
hätte ich neulich vielleicht gut verwenden können. sowas fehlt Ruby.
5.) { x| ... } konstrukte, find ich nicht so toll. liest sich wie lisp
wie smalltalk, meinst du sicher; da sieht es so aus:

Code: Alles auswählen

positiveAmounts := allAmounts select: [:amt | amt isPositive]
diese blöcke sind nach meinung vieler Ruby-geeks das beste feature der sprache. vielleicht schaust du sie dir nochmal genauer an.
es gibt auch Python-leute, die Codeblöcke gern in Python hätten. und ich bin sicher, dass man das irgendwie in Python einbauen könnte. gibts dazu nicht ein PCP? why hatte darüber berichtet.

ich frage übrigends nach verbesserungsvorschlägen, weil die Python-community im prinzip die einzige ist, von der Rubyisten vorschläge akzeptieren ^^
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

murphy hat geschrieben:
blackbird hat geschrieben:1.) fehlende keyword args (nein, hash ist kein ausweg)
warum nicht?
es stimmt, die funktionalität fehlt bisher und die diskussionen darüber, wie das in Ruby 2 aussehen soll, sind längst nicht beendet. allerdings benutzen Rails-entwickler den ganzen tag fröhlich keyword-argumente ohne probleme sieht dann so aus:

Code: Alles auswählen

start_form_tag :controller => '/entry',  :action => 'search'
gibt es einen anwendungsfall, der mit Ruby nicht ging? was hat dich gestört? vielleicht gibt es ja doch eine bessere lösung.
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.
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 :)
Django arbeitet sogar mit "endfor" und sowas, was mich letztens extrem erschreckt hat. Rails benutzt einfach embedded Ruby als template-sprache.
kann aber gut sein, dass ich was nicht verstanden hab- kenne Django nicht.
1.) rails template sind nicht sandboxed, weswegen auch gerade die django templates eifrig nach rails portiert werden. (Liquid) 2.) hat die template engine nix mit der Sache zu tun. 3.) ist das ein persönlicher Punkt, warum _ich_ ruby nicht mag ;-)
3.) fehlendes "self". Ist zwar sicher anfänglich ungewohnt, aber es ist explizit und pythonic. Ist mir lieber als das "@" gefummel
und ich hab mich so bemüht, diese self vs. @-sache zu begraben ^^
was @-gefummel sein soll, kann ich jetzt aber nicht verstehen. bitte fakten :)
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. Das objektmodel von python ist sehr frei und mächtig. Es gibt sehr viele Konstruktionen wo es ohne self gar nicht gehen würde. Bestes beispiel sind metaklassen, wo ich mehr als nur ein self haben kann.
5.) { x| ... } konstrukte, find ich nicht so toll. liest sich wie lisp
wie smalltalk, meinst du sicher; da sieht es so aus:

Code: Alles auswählen

positiveAmounts := allAmounts select: [:amt | amt isPositive]
diese blöcke sind nach meinung vieler Ruby-geeks das beste feature der sprache. vielleicht schaust du sie dir nochmal genauer an.
es gibt auch Python-leute, die Codeblöcke gern in Python hätten. und ich bin sicher, dass man das irgendwie in Python einbauen könnte. gibts dazu nicht ein PCP? why hatte darüber berichtet.
Meinst du das "with" statement? Wie auch immer. Es geht mir darum, dass die Syntax nicht leicht lesbar ist.

Wie gesagt. Ich bin glücklich bei Python gelandet und sehr zufrieden damit. Und die Core Devs überraschen jedes Release mit tollen neuen Features und die PyPy Leute überraschen uns jede Woche mit neuer Geschwindigkeit (ok, nicht ganz so schnell, aber es wird). Was will man mehr :D
TUFKAB – the user formerly known as blackbird
murphy
User
Beiträge: 60
Registriert: Samstag 30. Oktober 2004, 01:34
Wohnort: Berlin
Kontaktdaten:

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 :)
BlackJack

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. ;-)
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

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. ;-)
--- Heiko.
murphy
User
Beiträge: 60
Registriert: Samstag 30. Oktober 2004, 01:34
Wohnort: Berlin
Kontaktdaten:

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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Leonidas hat geschrieben:Ich werd mal etwas für Ruby 2 orakeln...
..., dass übrigens zusammen mit Hurd erscheint :wink:

*scnr*
TUFKAB – the user formerly known as blackbird
Clython
User
Beiträge: 151
Registriert: Samstag 21. August 2004, 13:58
Wohnort: Schweiz, BE-2500

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 :twisted:

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*
murphy
User
Beiträge: 60
Registriert: Samstag 30. Oktober 2004, 01:34
Wohnort: Berlin
Kontaktdaten:

mal umgekehrt:

gibt es denn in Ruby irgendwas, was ihr gerne in Python hättet?
erzähl mir keiner, Python wäre perfekt! ;)
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Clython
User
Beiträge: 151
Registriert: Samstag 21. August 2004, 13:58
Wohnort: Schweiz, BE-2500

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 :D
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
murphy
User
Beiträge: 60
Registriert: Samstag 30. Oktober 2004, 01:34
Wohnort: Berlin
Kontaktdaten:

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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten