Plattformunabhängigkeit und getch(curses)

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.
BlackJack

Beitragvon BlackJack » Samstag 25. April 2009, 12:13

"Das war schon immer so" kann man nicht kritisieren? Insbesondere bei einer Version die explizit mit Rückwärtskompatibilität bricht!? Leere `dict`\s mit ``{:}`` wäre IMHO durchaus möglich gewesen um den weg für ``{}`` als leeres `set` freizumachen.
lunar

Beitragvon lunar » Samstag 25. April 2009, 12:36

BlackJack hat geschrieben:"Das war schon immer so" kann man nicht kritisieren? Insbesondere bei einer Version die explizit mit Rückwärtskompatibilität bricht!?

Ach bitte, du weißt, was ich meine. "{}" als leeres Wörterbuch ist schon lange Bestandteil der Python-Syntax. Jeder Python-Programmierer kennt das, jeder erwartet das.

Konsistenz aber ist kein Selbstzweck, sondern dient immer den Verständnis. Code wird aber nicht unbedingt verständlicher, wenn man lang vertraute Formen im Sinne der Konsistenz mit einer neuen Bedeutung belegt. Ein solcher Schritt schafft allenfalls Verwirrung, und es benötigt dann wieder einige Zeit, bis sich jeder daran gewöhnt hat.

"A Foolish Consistency is the Hobgoblin of Little Minds".
Benutzeravatar
HerrHagen
User
Beiträge: 430
Registriert: Freitag 6. Juni 2008, 19:07

Beitragvon HerrHagen » Samstag 25. April 2009, 13:08

Die Alternative wäre gewesen alles so zu lassen wie es ist - oder etwas in der Art wie man es auch schon von Strings kennt:
[code=]empty_set = s{}
empty_dic = {}[/code]
Die Umsetzung ist allenfalls etwas inkonsistent, da "{}" keine leere Menge, sondern ein leeres Wörterbuch erzeugt, aber das war bei Python schon immer so, und ist daher eigentlich kein Kritikpunkt.

Genau darin liegt das Problem. {} ist ein leeres dict, obwohl es der Logik nach nun eher ein set sein müsste. Konsistent hätte das leere dict so: {:} und das leere set so {} ausgesehen. "Das war schon immer so" ist ganz sicher kein Argument, schließlich ging es ja in Python 3 darum solche Inkonsistenzen auszuräumen. Gerade bei dict/et comprehensions finde ich die neue Syntax ein wenig unübersichtlich.

MFG HerrHagen

EDIT: Oh, BlackJack war schneller - und hatte offensichtlich die gleiche Idee :wink:
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Samstag 25. April 2009, 13:30

lunar hat geschrieben:
BlackJack hat geschrieben:"Das war schon immer so" kann man nicht kritisieren? Insbesondere bei einer Version die explizit mit Rückwärtskompatibilität bricht!?

Ach bitte, du weißt, was ich meine. "{}" als leeres Wörterbuch ist schon lange Bestandteil der Python-Syntax. Jeder Python-Programmierer kennt das, jeder erwartet das.

Jeder Python 2.x Programmierer, ja. Aber man kann kaum erwarten dass das ewig so bleiben würde. Schließlich nehme ich an, dass auch Neulinge auf Python 3.0 einsteigen und die haben für sowas kein Verständnis. Ebenso wie alle anderen in ein paar Jahren, wenn 2.x an Bedeutung verliert.

lunar hat geschrieben:"A Foolish Consistency is the Hobgoblin of Little Minds".

Damit lässt sich nicht alles rechtferigen. Sonst müssten wir ja sagen dass die Twisted-Libs gut designt sind ;)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Beitragvon lunar » Samstag 25. April 2009, 13:32

HerrHagen hat geschrieben:Die Alternative wäre gewesen alles so zu lassen

Also keine Literalform für Mengen? Das wäre aber auch inkonsistent, den jede andere elementare Container-Klasse (Tupel, List, Wörterbuch) hat eine Literalform ;) Außerdem ziemlich unkomfortabel, aber darum gehts ja offenbar gerade nicht.

wie es ist - oder etwas in der Art wie man es auch schon von Strings kennt:
[code=]empty_set = s{}
empty_dic = {}[/code]

Das wäre sogar noch inkonsistenter als der Verzicht. Zum einen hat kein anderes Containerliteral Typpräfixe, zum anderen ändern diese bei skalaren Literalen zwar Typ, nicht aber Verhalten von Objekten. Ob ich nun Zahlen mit oktal- oder hexademzimal-Präfix versehe, oder Zeichenkette mit "u" oder "r", es ändert sich nichts an deren Verhalten: Es bleibt immer eine Zahl, und immer eine Zeichenkette.

Das aus einem leeren Wörterbuch aber durch den magischen Buchstaben "s" eine Menge wird, also ein sich völlig anders verhaltendes Objekt, passt da nicht recht ins Schema.

Mit der Konsistenz ist eben so eine Sache ;)

Genau darin liegt das Problem. {} ist ein leeres dict, obwohl es der Logik nach nun eher ein set sein müsste. Konsistent hätte das leere dict so: {:} und das leere set so {} ausgesehen.

Siehe meine Antwort auf BlackJacks Posting ...

Gerade bei dict/et comprehensions finde ich die neue Syntax ein wenig unübersichtlich.

Was wäre denn die konsistente(!) und übersichtliche Alternative? ;) Typpräfixe sind inkonsistent, außerdem wird der Code dadurch nur bedingt übersichtlicher: Wenn du einen Doppelpunkt nicht siehst, dann wirst du auch das Präfix nicht sehen. Der Verzicht ist ebenfalls inkonsistent, außerdem auch unkomfortabel. Und andere Klammern gibt es auch nicht wirklich ...

EDIT: Oh, BlackJack war schneller - und hatte offensichtlich die gleiche Idee :wink:

Und ich hatte ihm sogar schon geantwortet ...
lunar

Beitragvon lunar » Samstag 25. April 2009, 13:42

Leonidas hat geschrieben:Jeder Python 2.x Programmierer, ja. Aber man kann kaum erwarten dass das ewig so bleiben würde. Schließlich nehme ich an, dass auch Neulinge auf Python 3.0 einsteigen und die haben für sowas kein Verständnis. Ebenso wie alle anderen in ein paar Jahren, wenn 2.x an Bedeutung verliert.

Anfänger haben für vieles kein Verständnis ... z.B. warum "('foo')" die Zeichenkette 'foo' erzeugt und kein einelementiges Tupel.
Benutzeravatar
HerrHagen
User
Beiträge: 430
Registriert: Freitag 6. Juni 2008, 19:07

Beitragvon HerrHagen » Samstag 25. April 2009, 14:18

Das aus einem leeren Wörterbuch aber durch den magischen Buchstaben "s" eine Menge wird, also ein sich völlig anders verhaltendes Objekt, passt da nicht recht ins Schema.

Wieso? Bei Bytes/Unicode ist das doch recht ähnlich. Zudem wäre man so zukunftssicher gewesen. Beispielsweise werden ja nun recht häufig namedtuple eingesetzt. Was passiert wenn man die gerne in die Syntax integriert hätte? Oder irgendein anderer colllection Typ? Mehr Klammern gibt die Tastatur nun mal nicht her. Mit einem Präfix wäre das ganze recht einfach.
Man hätte das set ja auch mit eckigen Klammern und Präfix machen können. Es ähnelt ja eher einer Liste als einem Dictionary. Dann ist die Diskrepanz zwischen kleiner Änderung in Syntax - große Auswirkungen auf Verhalten nicht ganz so groß. Ein frozenset wäre dann entsprechend mit runden Klammern, äquivalent zum Verhältnis Tuple/Liste.

Code: Alles auswählen

empty_set = s[]
empty_frozenset = s()


EDIT: OK, das ist natürlich Quatsch, weil dann nicht mehr zwischen Funktionsaufruf/ Set unterschieden werden könnte. Dann halt doch so:

Code: Alles auswählen

empty_set = s{}
empty_frozenset = f{}
lunar

Beitragvon lunar » Samstag 25. April 2009, 14:39

str und byte stellen geordnete Sequenzen dar und implementieren das Listen-Protokoll. Zwischen beiden Typen besteht darüber hinaus ein logischer Zusammenhang, da sie ineinander überführt werden können.

set() und dict() dagegen sind zwei völlig unterschiedliche Typen, die in keinem unmittelbaren Zusammenhang stehen und völlig verschiedene Protokolle implementieren. Das ist also mitnichten vergleichbar.

Auch sind Mengen keine Listen und ähneln ihnen auch nicht. MengenSie sind ungeordnet, und unterstützen daher weder Slicing noch Sortierung noch Einfügen. Die einzige Operation, die auf Listen und Mengen gleichermaßen funktioniert, ist die Iteration.

EDIT: OK, das ist natürlich Quatsch, weil dann nicht mehr zwischen Funktionsaufruf/ Set unterschieden werden könnte. Dann halt doch so:

Code: Alles auswählen

empty_set = s{}
empty_frozenset = f{}

Dazu sage ich jetzt mal nichts :roll:
Benutzeravatar
HerrHagen
User
Beiträge: 430
Registriert: Freitag 6. Juni 2008, 19:07

Beitragvon HerrHagen » Samstag 25. April 2009, 15:20

set() und dict() dagegen sind zwei völlig unterschiedliche Typen, die in keinem unmittelbaren Zusammenhang stehen und völlig verschiedene Protokolle implementieren. Das ist also mitnichten vergleichbar.

Und deswegen gibt man ihnen die, bis auf einem Doppelpunkt in der Mitte, die gleiche Syntax? Genau das ist doch das Problem!

Code: Alles auswählen

>>> {1,2,3}  # set
>>> {1,2}    # set
>>> {1}      # set
>>> {}       # dict !?!?

Ein Präfix macht den Unterschied meiner Meinung nach halt deutlicher sichtbar, da man nun mal von links nach rechts ließt und so den Unterschied direkt erkennt und nicht mitten in der Zeile in seinen Gedanken "zurückspringen" muss.

Code: Alles auswählen

>>> s{1,2,3}  # set
>>> s{1,2}    # set
>>> s{1}      # set
>>> s{}       # set

Du hast natürlich damit recht, dass das nicht ganz sauber ist. Aber das ist ja keine der Lösungen (set() find ich noch am besten). Ich wollte nur ausdrücken, dass ich diese Neuerung für eine der weniger gelungenen in Python 3 halte.

MFG HerrHagen
DasIch
User
Beiträge: 2404
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Beitragvon DasIch » Samstag 25. April 2009, 15:56

Du kannst schlecht Inkonsistenz kritisieren und eine Lösung präsentieren die noch inkonsistenter ist.
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

Beitragvon numerix » Samstag 25. April 2009, 17:12

HerrHagen hat geschrieben: {} ist ein leeres dict, obwohl es der Logik nach nun eher ein set sein müsste. Konsistent hätte das leere dict so: {:} und das leere set so {} ausgesehen.


Ja, das wäre eine gute Lösung gewesen. Wer sich an Python 2.x gewöhnt hat, gewöhnt sich irgendwann um. Immerhin gibt es auch anderes umzugewöhnen, sei es nun die Division mittels "/" oder range() oder input() oder oder ... , die plötzlich etwas anderes machen.
Warum also nicht mit noch mehr alten Zöpfen brechen und {} als leere Menge und {:} als leeres dict einführen?
Benutzeravatar
snafu
User
Beiträge: 5388
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Beitragvon snafu » Samstag 25. April 2009, 18:57

HerrHagen hat geschrieben:Mehr Klammern gibt die Tastatur nun mal nicht her.


Es gibt spitze Klammern (größer/kleiner). :)

(ohne jetzt dafür plädieren zu wollen, diese für den besagten Fall einzusetzen)
shcol (Repo | Doc | PyPi)
bords0
User
Beiträge: 166
Registriert: Mittwoch 4. Juli 2007, 20:40

Beitragvon bords0 » Samstag 25. April 2009, 22:26

BrainF**K-Interpreter können ja auch ziemlich kurz sein: https://www.spoj.pl/ranks/BRAINF_K/

An Perl (nur 132 Zeichen!) kommt man mit Python aber wohl nicht heran.
Benutzeravatar
darktrym
User
Beiträge: 680
Registriert: Freitag 24. April 2009, 09:26

Beitragvon darktrym » Samstag 25. April 2009, 22:55

Ich möchte mich noch bei allen recht herzlich bedanken, die dazu beigetragen haben meinen Thread vollzu"spam"men".

Gibts eigentlich Benchmarks mit dem man testen kann, wie schnell der Interpreter ist? Am bestens mit Vergleichwerten. Das 99 Bottle Programm ist recht I/O(wobei mehr O) intensiv. Ich hätte da noch ein paar Ideen in der Hinterhand. Diese bringen aber keine aussagekräftigen Werte, wenn das Programm in 3s(auf einen x41) schon beendet wird.

Und zu den Wettbewerbungen rundum die legendäre Programmiersprache Brainf***, wichtiger sind für mich die Lesbarkeit, Performanz, Speicherverbrauch, Plattformunabhängigkeit am wenigsten interessieren mich die Größe des Quellcodes oder irgendwelche Hacks mit i386 Opcodes.
„gcc finds bugs in Linux, NetBSD finds bugs in gcc.“[Michael Dexter, Systems 2008]
[url=https://bitbucket.org/amoibos]Bitbucket[/url], [url=https://github.com/amoibos/]Github[/url]
DasIch
User
Beiträge: 2404
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Beitragvon DasIch » Sonntag 26. April 2009, 00:55

Wenn du wirklich was performantes haben willst kommst du mit einem Interpreter nicht weit, ein Compiler ist da um einiges interessanter.

Wer ist online?

Mitglieder in diesem Forum: Baidu [Spider]