Vorstellung, erster Beitrag und Frage

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.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@derkai74: Keine kryptischen Abkürzungen in Namen. `kl`? `gr`? Ich rate mal ”klein…” und ”gross…”? Das wird nirgends sichergestellt. `dif`?

Bei beiden Funktionen ist es überraschend, dass die als Argumente *Texte* erwarten und keine `date`/`datetime`-Objekte.

Bei beiden ist die Anpassung um 1 verwirrend bis falsch. Die Differenz zwischen Heute und Heute ist 0 Tage und nicht 1 Tag. Und wenn ich zu Heute einen Tag addiere habe ich Morgen und nicht immer noch Heute.

`neues_datum()` beschreibt keine Tätigkeit und `hinzu` ist ein komischer Name für einen Wert.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
derkai74
User
Beiträge: 39
Registriert: Montag 27. Dezember 2021, 22:14

ok, Danke für Deine Rückmeldung.

1) kryptische Abkürzungen. Richtig geraten. Ich habe es geändert.
2) Die Differenz der Tage ist von mir falsch ausgedrückt.
Es geht nicht um die Differenz, sondern Anzahl der Tage zwischen
zwei Daten. Ich habe den Namen der Funktion korrigiert.
3) Ich habe über eine if Anweisung sichergestellt, dass die Benutzereingaben
überprüft werden. Ob es bei dem "Fehlerhinweis" in dieser Form bleibt,
muss ich mir später noch überlegen. War das so gemeint?
4) Ja, die Addition von einem Tag zu heute IST morgen.
Da habe ich mich wohl selber überlistet.
5) neues_datum beschreibt keine Tätigkeit.
Meinst Du damit, dass ich den Namen der Funktion so benennen soll,
dass die "Tätigkeit", also der Sinn der Funktion sinnvoller beschrieben ist?
Hab ich gemacht.

Herausgekommen ist dabei das hier:

Funktion 1:

Code: Alles auswählen

# Anzahl der Tage zwischen 2 Datumsangaben
def anz_tage (kleines_datum, grosses_datum):
    kleines_datum = datetime.strptime(kleines_datum, "%d.%m.%Y")
    grosses_datum = datetime.strptime(grosses_datum, "%d.%m.%Y")
    if grosses_datum >= kleines_datum:
        return 1 + (grosses_datum - kleines_datum).days
    else:
        return "Das Ende Datum ist größer als das Anfangsdatum."
Funktion 2:

Code: Alles auswählen

# Datum um Anzahl Tage zu verändern
def ber_neues_datum (datum, addieren):                           # Tage sind als int einzulesen
    datum = datetime.strptime(datum, "%d.%m.%Y")
    return (datum + timedelta(days=(addieren)))
Bei beiden Funktionen ist es überraschend, dass die als Argumente *Texte* erwarten und keine `date`/`datetime`-Objekte.
Da liegt vielleicht noch ein grundsätzliches ? bei mir vor.

Ich gehe ja davon aus, dass der Nutzer das Datum später in der Form
dd.mm.YYYY eingeben wird. So weit ich es verstanden habe, wird für
datetime, date usw ja aber ein Datum im Format YYYY-mm-dd benötigt.

Ist das falsch?

Wenn ich die Benutzereingabe -> 15.01.2022 eingebe, dann wird ja ein string eingelesen.
Muss ich dann nicht irgendwo umwandeln?

auch wenn auf die schnelle etwas "kryptisch":

Code: Alles auswählen

# Datum Benutzeringabe umwandeln in rechenbares Datum
def umw_datum_b (ben_eingabe):
    z_schritt = datetime.strptime(ben_eingabe, "%d.%m.%Y")
    return datetime.date(z_schritt)
ergibt: 2022-01-15
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Du bestätigst, dass kryptische Abkürzungen schlecht sind, benutzt sie dann aber munter weiter `umw`? Und was soll das `b` bedeuten? Wer ist Ben? Und der z-Schritt? Neben Ben gibt es auch noch Ber, ist das nun die Abkürzung für Berta oder Bärbel?
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@derkai74: Ad 5) Ja das war gemeint und `anz_tage()` ist ja auch wieder keine Tätigkeit. Dabei geht es zum einen darum, das der Leser weiss was die Funktion tut, und zum anderen dass der Leser weiss, dass es sich um eine Funktion handelt und nicht um einen eher passiven Wert. Oder aus Sicht von Werten: Wenn die Funktion nicht die Tätigkeit beschreibt, sondern eher wie ein Wert klingt, am Ende vielleicht sogar noch wie ein guter Name für den Wert den das Ergebnis dieser Funktion haben könnte, dann ”verliert” man diesen Namen für Werte. Dafür ist die erste Funktion ja ein gutes Beispiel. Mal die Abkürzung kurz ausser acht gelassen, wenn man die Anzahl der Tage ausrechnet und an einen Namen binden möchte, bietet sich ja irgendwie `anzahl_tage` dafür an. Nur heisst jetzt dummerweise die Funktion schon so und so was wie ``anzahl_tage = anzahl_tage(startdatum, enddatum)`` verwirrt im besten Fall nur den Leser, führt aber auch dazu das man nach dieser Zeile, zumindest im gleichen Namensraum, die Funktion nicht mehr benutzen kann, weil an den Namen jetzt eine Zahl gebunden ist und nicht mehr die Funktion.

Da habe ich eben gerade nebenbei auch gleich noch verraten was ich für bessere Namen als `kleines_datum` und `grosses_datum` halte, nämlich `startdatum` (oder `anfangsdatum`) und `enddatum`. Und als Funktionsname dann vielleicht `berechne_tagesanzahl()`. Bei der Funktionssignatur ``def berechne_tagesanzahl(startdatum, enddatum):`` hat der Leser sehr wahrscheinlich eine gute Vorstellung davon was die Funktion tut, was die Argumente bedeuten, und was die Funktion als Ergebnis liefert.

Eine Zahl *oder* eine Zeichenkette mit Fehlermeldung als Rückgabewert ist keine sinnvolle API. Für Fehler sind Ausnahmen da.

`addieren` ist auch kein guter Name für das alte `hinzu`. Erst mal ist das ja eine Tätigkeit, der Benutzer könnte sich also wundern was für eine Funktion er da übergeben soll, und dann sagt doch auch der Name nicht was die Bedeutung von dem Wert ist. Im simpelsten Fall könnte man das einfach `anzahl` oder `anzahl_tage` oder `tage` nennen, je nach dem was für einen Funktionsnamen man wählt und ob man in Kombination dann zumindest gut erahnen kann was da an der Stelle als Argument erwartet wird. Also beispielsweise ``def addiere_tage(datum, anzahl):`` wäre IMHO recht aussagekräftig.

Ja klar musst Du ein als Text eingegebenes Datum zum rechnen in ein Datumsobjekt umwandeln. Aber nicht in den Funktionen die mit Datumsangaben rechnen sollen. Das würde früher oder später zu einem schwer zu durchschauenden sinnlosen hin und her konvertieren zwischen Datumsobjekten und Zeichenketten führen. Zudem ist die `addiere_tage()`-Funktion ja auch ”asymmetrisch”, das heisst die erwartet ein Datum in den Argumenten und liefert ein Datum als Ergebnis — aber das Argument ist eine Zeichenkette und das Ergebnis ein Datumsobjekt. Das ist überraschend.

Ungetestet:

Code: Alles auswählen

from datetime import timedelta as TimeDelta


def berechne_tagesanzahl(startdatum, enddatum):
    if enddatum < startdatum:
        raise ValueError(
            f"enddatum ({enddatum!r}) < startdatum ({startdatum!r})"
        )

    return (enddatum - startdatum).days + 1


def addiere_tage(datum, anzahl):
    return datum + TimeDelta(days=anzahl)
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
derkai74
User
Beiträge: 39
Registriert: Montag 27. Dezember 2021, 22:14

Vielen Dank __blackjack__ für Deine ausführliche Antwort.
Ich denke, ich habe jetzt verstanden, was Du meinst.
Aktuell habe ich nichts Neues beizutragen.

Außer vielleicht, warum Du timedelta as TimeDelta importiert hast.
War das n Test? :)

Ich werde jetzt erstmal die nächste Lektion lernen.

Nochmals vielen Dank.

Kai
Benutzeravatar
Dennis89
User
Beiträge: 1124
Registriert: Freitag 11. Dezember 2020, 15:13

Vermutlich weil 'timedelta' eine Klasse ist und die schreibt man in PascalCase-Schreibweise laut dem Python Style-Guid.

Die Klasse siehst du hier:
https://github.com/python/cpython/blob/ ... me.py#L442

Python Style-Guid:
https://www.python.org/dev/peps/pep-0008/#class-names

Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

@Dennis89,

der Style-Guide ist dafür da, dass man sich selbst daran orientieren kann und eine Grundlagen hat um mit anderen Entwicklern reibungslos zusammenzuarbeiten.
Das heißt nicht, dass man bestehenden Code irgendwie gerade biegen sollte.
In diesem Fall würde es nur Verwirrung stiften. Man sieht es dem timedelta ja nicht an, dass es eigentlich eine Klasse ist.
Sieht man TimeDelta dagegen irgendwo in einer langen Passage im source code, würde man annehmen, dass es einen anderen Ursprung, als die vom datetime Modul zur Verfügung gestellte Klasse hat.
Wenn man das konsequent durchziehen wollte, müsste man das bei vielen klein-geschriebenen Python-Klassen machen. Willst du jedes mal im Python source code schauen ob du gerade eine versteckte Klasse importiert hast, die gegen die Konvention klein geschrieben wurde?
Hier im Forum sieht man ja auch oft Code-Schnippsel aus dem Zusammenhang geschnitten. Da würde "TimeDelta" nur unnötige Fragen aufwerfen.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@rogerb: Ich mache das bei `datetime` aber tatsächlich wegen der Namenskonvention, weil insbesondere bei `date` es total sch…e ist das der Typ `date` es einem unmöglich macht den Namen für ein konkretes Datum zu verwenden. Also beispielsweise wenn `addiere_tage()` aus dem Beispiel oben englisch benannt wäre, möchte ich mir nicht krampfhaft irgendeinen Namen für das erste Argument ausdenken müssen, nur weil die #&%+*, die das `datetime`-Modul implementiert haben, meinten sie müssten eine Klasse `date` nennen:

Code: Alles auswählen

def add_days(date, count):
    return date + TimeDelta(days=count)
Streng genommen müsste man dafür `timedelta` nicht umbenennen, wobei das ja das gleiche Problem hat, aber ein ``from datetime import date as Date, timedelta`` sähe ja auch komisch/inkonsistent aus, also benenne ich beim `datetime`-Modul alle Typen um wenn ich die importiere, und nicht nur die, die ich gerade als Namen für Exemplare von den jeweiligen Typen verwende.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
Dennis89
User
Beiträge: 1124
Registriert: Freitag 11. Dezember 2020, 15:13

Hallo,
rogerb hat geschrieben: Montag 17. Januar 2022, 23:19 Willst du jedes mal im Python source code schauen ob du gerade eine versteckte Klasse importiert hast, die gegen die Konvention klein geschrieben wurde?
Ich will eigentlich gar nichts :D
Ich habe mir nur überlegt, wieso __blackjack__ den Namen umbenannt hat. Mit den Links wollte ich euch meine Idee/Begründung aufzeigen und euch das Suchen ersparen.

Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
Benutzeravatar
sparrow
User
Beiträge: 4164
Registriert: Freitag 17. April 2009, 10:28

Insbesondere bei datetime.datetime macht das ebenfalls Sinn.

Code: Alles auswählen

from datetime import datetime as DateTime
macht klar, ob es ich um das Modul "datetime" handelt oder um die darin enthaltene Klasse.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

__blackjack__ hat geschrieben: Dienstag 18. Januar 2022, 01:27 @rogerb: Ich mache das bei `datetime` aber tatsächlich wegen der Namenskonvention, weil insbesondere bei `date` es total sch…e ist das der Typ `date` es einem unmöglich macht den Namen für ein konkretes Datum zu verwenden.
Das ist meiner Meinung nach eine übertriebene Auslegung der Namenskonvention. Und wenn ich mal weiterlese ist dein Grund ja auch eher praktischer Natur. Denn du machst das ja sicher nicht bei allen kleingeschriebenen Klassennamen, die aus Python kommen.

"from operator import itemgetter as Itemgetter" ?

Für mich ist der Alias-Import eigentlich nur eine Notlösung um Namenskonflikte aufzulösen. Wenn "import numpy as np" nicht quasi ein *muss* wäre, würde ich das wohl auch nicht verwenden.
Insbesondere Namen, die direkt aus Python kommen, würde ich eigentlich nie umbenennen. Die Gefahr, dass es Verwirrung stiftet ist mir zu groß.

Wenn ich versuche eine größere Menge Fremdcode zu verstehen und mich durch die Module klicken muss, nervt es doch schon mal, wenn eine Klasse im importierenden Modul plötzlich einen anderen Namen als im Ursprungsmodule hat. Wenn die jetzt noch an ein anderes Modul durchgereicht wird und da wieder einen anderen Namen bekommt, ... (alles schon gesehen)

Dass bestimmte kleingeschriebene Instanz-Namen wie "date" nicht mehr zur Verfügung stehen, hat mich auch schon gestört. Andererseits ist man dann aber auch gezwungen aus dem eher generischen "date" ein "startdate" zu machen.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@rogerb: Nee, generell mache ich das tatsächlich nicht. Hauptsächlich bei `datetime`. Bei einigen Sachen weiss man ja auch gar nicht, oder erwartet zumindest nicht 100%ig, dass es eine Klasse ist. In `itertools` ist einiges, was zwar eine klein geschriebene Klasse ist, aber genau so gut eine Funktion sein könnte. Davon leitet ja auch niemand etwas ab, sondern kombiniert das in dem man es mit anderen `itertools` und `map()`, `zip()`, `filter()` & Co zusammenstöpselt.

Gerade im `operator`-Modul gibt aber auch Namen die so schlecht sind, dass ich die tatsächlich in/für lesbare(m|n) Code umbenenne. So etwas wie ``from operator import ge as (is_)greater_or_equal`` findet man da bei mir schon mal. In dem Fall um zu verhindern das ein Leser überhaupt erst suchen muss was `ge` denn bedeuten mag und wo das denn her kommt, denn ich gehe davon aus, dass `is_greater_or_equal()` *deutlich* weniger Fragezeichen aufwirft als `ge()` und damit eine Umbenennung gerechtfertigt ist.

Ich glaube das einzige was ich sonst noch recht regelmässig umbenenne, weil es den Code wo es verwendet wird deutlicher macht, ist in `pytest`-Unittests ``from contextlib import ExitStack as does_not_raise`` um es in parametrisierten Tests als ”Gegenstück” zu `pytest.raises()` zu verwenden.

Und natürlich die Klassiker wie `tk`, `np`. Ich denke ``ctypes as ct``, ``sqlalchemy as sa``, und ``pyparsing as pp`` sind nicht so geläufig, habe ich aber auch hier und da bei anderen gesehen. Der Grund bei all *diesen* Beispielen ist ja letztendlich dass man beim schreiben schon weiss, man wird sehr sehr viele Namen aus diesen Modulen verwenden, weiss aber noch nicht welche das genau sind.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
derkai74
User
Beiträge: 39
Registriert: Montag 27. Dezember 2021, 22:14

ok, ich habe weitergemacht.

Mal sehen, ob ich was gelernt habe und aus dem Code ersichtlich ist,
was ich wollte und was dabei rausgekommen ist.

Für Anregungen bin ich wie immer sehr dankbar.
Ich bin der Meinung, dass es zumindest funktioniert.

Besten Dank vorab - und nun, Feuer frei

Code: Alles auswählen

[
# Funktionen berechnen ausgehend von einer Benutzereingabe vom Typ
# Datum dd.mm.YY den jeweils Monatsletzten und Monatsersten
# Format datetime

from datetime import datetime
from dateutil.relativedelta import relativedelta
# ------------------------------------------------------------------
def berechne_monatsletzten (datum):
    return datum + relativedelta(day=31)

def berechne_monatsersten (datum):
    #return datum + relativedelta(months=-1, day=1) # Monatserster Vormat
    return datum + relativedelta(day=1)

# --------------------- T E S T -------------------------------
eingabe_datum = datetime.strptime(input("Datum: "), "%d.%m.%Y")
monatsletzter = berechne_monatsletzten(eingabe_datum)
print(monatsletzter)

monatserster = berechne_monatsersten(eingabe_datum)
print(monatserster)/code]
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

Ja, die besondere Herausforderung ist natürlich Schaltjahre richtig zu behandeln. passt aber!
Man könnte bei der Ausgabe noch die Zeitangabe weglassen. Es geht ja nur um Tage, oder?


Fun-Fakt: relativedelta ist auch 'ne Klasse, die auch noch von "object" erbt.
Benutzeravatar
Dennis89
User
Beiträge: 1124
Registriert: Freitag 11. Dezember 2020, 15:13

Dann könnte man falsche Eingaben abfangen, 'monatsletzter' und 'monatserster' braucht man eigentlich nicht definieren, das könnte man direkt in die 'print'-Funktion schreiben.
Was du dir angewöhnten kannst/solltest, auf Modulebene gehört kein ausführbarer Code. Hier werden nur Konstanten, Funktionen und Klassen definiert. Üblicherweise steht das, was bei dir gerade auf Modulebene steht, in einer Funktion mit dem Namen 'main'. Aufgerufen wird die Funktion mit:

Code: Alles auswählen

if __name__ == '__main__':
    main()
Ok erwirscht, diese Ausnahme darf/muss auf Modulebene stehen. Die sorgt dafür dass du das Programm in andere importieren kannst, ohne dass das automagisch gestartet wird.

Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
derkai74
User
Beiträge: 39
Registriert: Montag 27. Dezember 2021, 22:14

meinst Du mit ausführbarem Code das hier, was da nicht rein gehört?

Code: Alles auswählen

eingabe_datum = datetime.strptime(input("Datum: "), "%d.%m.%Y")
monatsletzter = berechne_monatsletzten(eingabe_datum)
print(monatsletzter)

monatserster = berechne_monatsersten(eingabe_datum)
print(monatserster)/code]

Das wird da auch nicht "drin" bleiben bzw. wird in Kommentar gesetzt werden.
Mehr oder weniger für mich, um schnell mal zu probieren.
Aber falls das gemeint war, danke ich Dir für den Hinweis.
derkai74
User
Beiträge: 39
Registriert: Montag 27. Dezember 2021, 22:14

rogerb hat geschrieben: Donnerstag 20. Januar 2022, 22:30 Ja, die besondere Herausforderung ist natürlich Schaltjahre richtig zu behandeln. passt aber!
Man könnte bei der Ausgabe noch die Zeitangabe weglassen. Es geht ja nur um Tage, oder?


Fun-Fakt: relativedelta ist auch 'ne Klasse, die auch noch von "object" erbt.
Vielen Dank auch für diesen Hinweis.
Muss gestehen, aktuell noch ein wenig Bahnhof.
Das ist aber gut.
Ich werde es mir ansehen und versuchen zu verstehen.

Für "mein" Projekt habe ich so weit erst einmal viel geschafft, da ich viel mit Datum werde rechnen müssen.

Ja, es geht "nur"um Tage.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Ich war mal neugierig und habe versucht zu schauen bei wie vielen Klassen aus der Standardbibliothek der Name komplett klein geschrieben ist. Von 2203 Klassen die kein Implementierungsdetail sind und die nicht in `builtins` sind (Python 3.7 unter Linux) sind 145 komplett klein geschrieben. Hier die Liste:

Code: Alles auswählen

Classes: 2203
Classes with lower case name: 145
p abc.abstractclassmethod
p abc.abstractproperty
p abc.abstractstaticmethod
c array.array
p asynchat.async_chat
p asynchat.simple_producer
p asyncore.dispatcher
p asyncore.dispatcher_with_send
p asyncore.file_dispatcher
p asyncore.file_wrapper
c audioop.error
p binhex.openrsrc
p calendar.different_locale
p collections.defaultdict
p collections.deque
p contextlib.closing
p contextlib.nullcontext
p contextlib.redirect_stderr
p contextlib.redirect_stdout
p contextlib.suppress
p csv.excel
p csv.excel_tab
p csv.unix_dialect
p ctypes.c_bool
p ctypes.c_byte
p ctypes.c_char
p ctypes.c_char_p
p ctypes.c_double
p ctypes.c_float
p ctypes.c_int
p ctypes.c_long
p ctypes.c_longdouble
p ctypes.c_short
p ctypes.c_ubyte
p ctypes.c_uint
p ctypes.c_ulong
p ctypes.c_ushort
p ctypes.c_void_p
p ctypes.c_wchar
p ctypes.c_wchar_p
p ctypes.py_object
p datetime.date
p datetime.datetime
p datetime.time
p datetime.timedelta
p datetime.timezone
p datetime.tzinfo
p distutils.command.bdist.bdist
p distutils.command.bdist_dumb.bdist_dumb
p distutils.command.bdist_rpm.bdist_rpm
p distutils.command.bdist_wininst.bdist_wininst
p distutils.command.build.build
p distutils.command.build_clib.build_clib
p distutils.command.build_ext.build_ext
p distutils.command.build_py.build_py
p distutils.command.build_py.build_py_2to3
p distutils.command.build_scripts.build_scripts
p distutils.command.build_scripts.build_scripts_2to3
p distutils.command.check.check
p distutils.command.clean.clean
p distutils.command.config.config
p distutils.command.install.install
p distutils.command.install_data.install_data
p distutils.command.install_egg_info.install_egg_info
p distutils.command.install_headers.install_headers
p distutils.command.install_lib.install_lib
p distutils.command.install_scripts.install_scripts
p distutils.command.register.register
p distutils.command.sdist.sdist
p distutils.command.upload.upload
p enum.auto
p filecmp.dircmp
p ftplib.error_perm
p ftplib.error_proto
p ftplib.error_reply
p ftplib.error_temp
p functools.partial
p functools.partialmethod
c grp.struct_group
c itertools.accumulate
c itertools.chain
c itertools.combinations
c itertools.combinations_with_replacement
c itertools.compress
c itertools.count
c itertools.cycle
c itertools.dropwhile
c itertools.filterfalse
c itertools.groupby
c itertools.islice
c itertools.permutations
c itertools.product
c itertools.repeat
c itertools.starmap
c itertools.takewhile
c itertools.zip_longest
p macpath.norm_error
p mailbox.mbox
c mmap.mmap
p netrc.netrc
c nis.error
p operator.attrgetter
p operator.itemgetter
p operator.methodcaller
p os.stat_result
p os.statvfs_result
p os.terminal_size
c parser.st
p platform.uname_result
p poplib.error_proto
c posix.sched_param
c posix.times_result
c posix.uname_result
c posix.waitid_result
c pwd.struct_passwd
c pyexpat.xmlparser
p re.error
c resource.struct_rusage
p sched.scheduler
c select.epoll
p shlex.shlex
p shutil.usage
p signal.struct_siginfo
p socket.gaierror
p socket.herror
p socket.socket
p socket.timeout
c spwd.struct_spwd
p struct.error
c termios.error
c time.struct_time
p typing.typing.io
p typing.typing.re
p urllib.request.ftpwrapper
p urllib.response.addbase
p urllib.response.addclosehook
p urllib.response.addinfo
p urllib.response.addinfourl
p warnings.catch_warnings
p weakref.finalize
c xxlimited.error
c xxsubtype.spamdict
c xxsubtype.spamlist
c zipimport.zipimporter
c zlib.error
Das "p"/"c" vor den Namen bedeutet ob die Klasse in Python oder in C geschrieben ist. Da wollte ich schauen, ob das vielleicht ein Muster ergibt, weil die eingebauten klein geschriebenen Namen, wo das klein schreiben ja ”normal” ist, alle in C implementiert sind.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

Ein Muster erkenne ich da jetzt aber nicht.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Das was in itertools, contextlib oder operator angeboten wird, fühlt sich für mich mehr nach Funktionen an. Wirklich störend sind datetime und socket.
Antworten