PEP8eroni

[Goswin]

Was sagt eure PEP8-Auslegung über die Namensgebung von Konstruktormethoden und -funktionen aus? mixed_Case weil Methode oder CamelCase wie der Defaultkonstruktor?

Und wie unterscheidet ihr zwischen den Namen von Konstruktorfunktionen, welche ein Objekt einer Klasse ausgeben sollen, und den Namen von Zuweisungsfunktionen, welche eine Klasse ausgeben sollen?

[bwbg]

Python nutzt __init__ als Initialisierungsmethode. Da gibt es keinen Raum für Auslegungen.

Sowas wie ein Default-Constructor gibt es in Python nicht, da Funktionen nicht überladen werden können.

Methoden sind Funktionen und Attribute der Klasse und damit lower_case_with_underscore.

Im Grunde lassen sich die Namenskonventionen auf drei Regeln herunterbrechen:

• UPPER_CASE_WITH_UNDERSCORE für Konstanten
• CamelCase für Klassen
• lower_case_with_underscore für Attribute und sonstige Namen

Ansonsten: Denk nicht so kompliziert!

Grüße ... bwbg

[cofi]

PEP8 ist keine Auslegungssache. Es ist sogar so eindeutig, dass es `pep8` gibt: https://pypi.python.org/pypi/pep8/1.4.3

Man sollte es nicht blind anwenden, aber man wird doch lieber blind, wenn man `mixed_Case_With_Underscores` sehen muss. Da gibt es nur noch eine Steigerung der Grausamkeit: Stroustrups "The C++ Programming Language".

[Goswin]

Methoden sind Funktionen und Attribute der Klasse und damit lower_case_with_underscore.

Bedeutet das:
Ihr unterscheidet *nicht* (zumindest nicht über die Groß-Klein-Unterstrich-Schreibung) zwischen Namen von Funktionen, welche Klassen ausgeben, und Namen von Funktionen, welche Objekte dieser Klassen ausgeben?

[pillmuncher]

Methoden sind Funktionen und Attribute der Klasse und damit lower_case_with_underscore.

Bedeutet das:
Ihr unterscheidet *nicht* (zumindest nicht über die Groß-Klein-Unterstrich-Schreibung) zwischen Namen von Funktionen, welche Klassen ausgeben, und Namen von Funktionen, welche Objekte dieser Klassen ausgeben?

Wenn du mit ausgeben meinst: zurückgeben (im Sinne von return), dann nein. Klassen sind ja auch nur Objekte in Python, und damit Instanzen/Exemplare von anderen Klassen, den Metaklassen:

Code: Alles auswählen

class Foo:
    pass

x = Foo()
assert x.__class__ is Foo
assert Foo.__class__ is type
assert Foo.__class__.__class__ is type


class MetaBar(type):
    pass

class Bar(metaclass=MetaBar):
    pass

y = Bar()
assert y.__class__ is Bar
assert Bar.__class__ is MetaBar
assert Bar.__class__.__class__ is type

Python 3.x

[/me]

Bedeutet das:
Ihr unterscheidet *nicht* (zumindest nicht über die Groß-Klein-Unterstrich-Schreibung) zwischen Namen von Funktionen, welche Klassen ausgeben, und Namen von Funktionen, welche Objekte dieser Klassen ausgeben?

Nein. Beides sind Funktionen. Was sie tun und was sie zurückgeben ist für die Schreibweise der Namensgebung irrelevant.

[snafu]

Funktionen, die Klassen zurückgeben, sind auch eigentlich eher selten. Wenn ich eine Fabrikfunktion haben möchte, die Objekte verschiedenen Typs liefern soll, wobei die Objekte ein bestimmtes Interface implementieren, dann würde ich eher Instanzen zurückliefern anstatt den puren Klassen. Wird ja in Sprachen wie Java auch nicht viel anders gehandhabt.

Man könnte halt in den Funktionennamen den Typen einbauen. So würde eine Funktion namens `get_parser(file_extension)` meinetwegen je nach Dateiendung einen fehlertoleranten HTML-Parser oder einen XML-Parser oder einen JSON-Parser zurückliefern und alle unterstützen mindestens die Methode `.parse()`. Und wenn kein passender Parser gefunden wurde, dann wird ein Fehler geworfen. Nur mal als Beispiel.

Was man halt genrell bei dynamisch typisierten Sprachen beachten muss, ist dass zum Teil mehr dokumentiert bzw (im Anwenderfall) mehr Doku gelsen werden muss, da eben der Rückgabetyp nicht eindeutig aus der Signatur hervorgeht. Auch das Abkürzen von Namen ist bei statisch typisierten Sprachen IMHO oft nicht so tragisch wie bei dynamisch typisierten. Zumindest nicht, wenn die Deklaration (eben mit der Typangabe) nahe genug an der darauf folgenden Verwendung steht und nicht erst 20 Zeilen später wieder auftaucht.

Hat also alles seine Vor- und Nachteile. Man sollte nur sehen, dass man sich auf das Konzept der gewählten Sprache auch wirklich einlässt und nicht zu übermäßig sein eigenes Ding durchzieht, nur weil man es anhand einer anderen Sprache so erlernt hat. Ich bin eigentlich ganz froh, dass ich *erst* Python und *dann* Java gelernt hab.