Das deutsche Python-Forum

Hallo,

nachdem sich mit Py3 ein paar Modulnamen geändert haben und sich Klassennamen innerhalb der Module nicht immer an CamelCase orientieren, würde mich mal interessieren, ob jemand von Euch weiß, ob es Gedanken oder sogar Pläne gibt, die Klassennamen innerhalb des 'datetime' Moduls zu CamelCaseinieren....

mutetella

Wenn man richtig konsequent sein möchte, dann müsste man theoretisch alle möglichen Builtin-Klassennamen überarbeiten. Die fangen ja irgendwie alle mit einem kleinen Buchstaben an...

Aber wenn es da mal eine Änderung geben sollte, dann vermutlich frühestens in Python 4.

mutetella hat geschrieben:nachdem sich mit Py3 ein paar Modulnamen geändert haben und sich Klassennamen innerhalb der Module nicht immer an CamelCase orientieren, würde mich mal interessieren, ob jemand von Euch weiß, ob es Gedanken oder sogar Pläne gibt, die Klassennamen innerhalb des 'datetime' Moduls zu CamelCaseinieren....

Ich gehe nicht davon aus, dass man innerhalb der Python 3-Linie die Standardbibliothek so umbaut. Das würde allem widersprechen was man bei Python bisher gemacht hat.

Ich mache das immer manuell, also zum Beispiel ``from datetime import date as Date, datetime as DateTime, timedelta as TimeDelta``.

Diese Kleinschreibungen nerven, denn es ist ja nun nicht ungewöhnlich, dass man zum Beispiel ein Datumsexemplar `date` nennen möchte. Genau so blöd ist das bei `socket`. Das Modul heisst `socket`, der Typ heisst `socket` und vielleicht möchte man ein Socket-Exemplar einfach mal `socket` nennen. Grmpf.

Sockets sind bei mir grundsätzlich immer Socken.

@BlackJack Also, ehrlich gesagt war die Namensgebung bisher immer mein geringstes Problem mit Sockets. Mich hat immer eher die furchtbar antike API gestört…

Nimm doch die Namensgebung als dezenten Hinweis, dass Programmierung mit rohen Sockets im Jahre des Herrn 2013 halt schon uncool ist Suche Dir doch eine Bibliothek, die von Sockets abstrahiert. Es gibt doch für Python bestimmt etwas ala Netty oder SuperSocket.

@lunar: Das löst das Problem mit Daten und Zeiten nicht. Oder sollte man da auch einfach sagen die sind uncool, mit denen spiele ich nicht.

BlackJack hat geschrieben:@lunar: Das löst das Problem mit Daten und Zeiten nicht. Oder sollte man da auch einfach sagen die sind uncool, mit denen spiele ich nicht.

Ja klar. Am 21.12.2012 sind wir ja alle auf eine höhere Bewusstseinsebene gehoben worden und existieren seitdem nur noch als transzendente Lichtgestalten. Wer wird sich denn da noch von solchen Dingen wie Raum und Zeit einschränken lassen?

Außerdem ist schöner Code doch eh zeitlos

lunar hat geschrieben:@BlackJack Also, ehrlich gesagt war die Namensgebung bisher immer mein geringstes Problem mit Sockets. Mich hat immer eher die furchtbar antike API gestört…

Nimm doch die Namensgebung als dezenten Hinweis, dass Programmierung mit rohen Sockets im Jahre des Herrn 2013 halt schon uncool ist Suche Dir doch eine Bibliothek, die von Sockets abstrahiert. Es gibt doch für Python bestimmt etwas ala Netty oder SuperSocket.

Es gäbe zum Beispiel Twisted. Aber ich denke mal, das weiß BlackJack auch und wird vermutlich seine Gründe haben, wieso er trotzdem direkt gegen die Socket-API programmiert. Je nach konkreter Aufgabenstellung will man vielleicht auch nicht immer gleich ein Framework als Abhängigkeit haben...

Die API von Twisted ist naja, genau wie der Name verspricht.

@snafu Twisted kenne ich… und eben deswegen habe ich es dediziert nicht erwähnt.

Um mal halb OT zugehen: Was gibt es denn für gleichwertige alternativen zu twisted? Wusste garnicht dass es bei euch so ein niedriges Ansehen hat...

Edit: Hmm ich gehe im Offtopic Forum Offtopic...