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
Könnte aus 'datetime' einmal 'DateTime' werden?
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit 
)
)
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.
Aber wenn es da mal eine Änderung geben sollte, dann vermutlich frühestens in Python 4.
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.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....
-
BlackJack
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.
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.
-
lunar
@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.
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.-
BlackJack
@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?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.
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...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