Typescript / Javascript -> Python

[nimbus_]

Moin,
ich versuche gerade ein Script in typescript / javascript zu Python zu konvertieren. Bin auch schon recht weit.
Allerdings wird jetzt folgende Datenstruktur definiert und benutzt, bei der ich einfach nicht weiß, wie sie korrekt in Python aussieht ... kann jemnd bitte helfen?

Code: Alles auswählen

export interface EUPOIInformation {
  phone: string;
  waypointID: number;
  lang: 1;
  src: 'HERE';
  coord: {
    lat: number;
    alt: number;
    lon: number;
    type: 0;
  },
  addr: string;
  zip: string;
  placeid: string;
  name: string;
}

habe z.B. folgendes probiert (ich weiß, oben ist eher Definition unten Deklaration, aber es geht ja ums Prinzip ... gibt auch nicht direkt eine Meldung, aber funktioniert scheinbar nicht wie gewünscht - woran liegts?

Code: Alles auswählen

poiinfo = {
        'phone': '',
        'waypointID': 0,
        'lang': 1,
        'src': 'HERE',
        'coord': {'lat': 0, 'alt': 0, 'lon': 0, 'type': 0},
        'addr': '',
        'zip': '',
        'placeid': '',
        'name': ''}

[Sirius3]

Wie soll es denn "funktionieren"?

[lvlanson]

Ich würde hier nicht ein einfaches Dictionary nehmen, wenn du eine strengere Typisierung hier vornehmen willst.

Meiner Meinung nach wäre hier eine Klasse sinnvoll, die du mit einer Funktion

Code: Alles auswählen

to_dict()

ausstatten kannst, welche dir dann ein Dictionary zurück gibt.

So hast du den Vorteil, dass du gekapselt eine Typisierungsprüfung vornehmen kannst, falls das nötig ist.

Beispielsweise könnte man so etwas machen.

Code: Alles auswählen

class EupoInformation:


	def __init__(phone = None, waypointID = None, coord_lat = None, coord_alt = None):
		# Ich lasse einige Attribute der weg, das Prinzip sollte klar sein
		self.phone 		= phone if isinstance(phone, str) else None
		self.waypointID 	= waypointID if isinstance(phone, int) else None
		self.lang 		= 1
		self.coord 		= dict()
		self.coord["lat"] 	= coord_lat if isinstance(coord_lat, int) else None
		self.coord["alt"]	= coord_alt if isinstance(coord_lat, int) else None
						
	def to_dict():
		out = {	phone: self.phone,
				waypointID: self.waypointID,
				lang: 1,
				coord: self.coord}
		return out

Liebe Grüße,
Thomas

[Sirius3]

@lvlanson: wenn Du eine strengere Typisierung willst, dann benutze kein Python. Die Klasse, wie Du sie geschrieben hast, ist nicht so toll, weil bei einem Fehler würde ich eine Fehlermeldung erwarten, und nicht, dass ein Attribut einfach nur den Wert None bekommt. Für coord benutzt Du dann doch wieder ein Wörterbuch. Das ist nicht sehr konsequent. Die to_dict-Funktion ist dann nichtmal mehr gültige Pythonsyntax.

[__blackjack__]

Ich würde das `attr`-Modul verwenden. Da bekommt man die Umwandlung in ein Wörterbuch einfacher, und hat auch gleich einen Ansatzpunkt für Validierungungen und Konvertierungen beim erstellen der Objekte.

[lvlanson]

@lvlanson: wenn Du eine strengere Typisierung willst, dann benutze kein Python. Die Klasse, wie Du sie geschrieben hast, ist nicht so toll, weil bei einem Fehler würde ich eine Fehlermeldung erwarten, und nicht, dass ein Attribut einfach nur den Wert None bekommt. Für coord benutzt Du dann doch wieder ein Wörterbuch. Das ist nicht sehr konsequent. Die to_dict-Funktion ist dann nichtmal mehr gültige Pythonsyntax.

Ja das stimmt. Ist auch mehr als Einstiegsidee gedacht. Manchmal ist es trotzdem unausweichlich in Python mit strenger Typisierung zu arbeiten

[__blackjack__]

@lvlanson: In ganz wenigen Fällen und sicher nicht *so* wie in Deinem Beispiel. Das nimmt man in wenigen Fällen wo man bei unterschiedlichem Datentyp auch anderen Code laufen lassen will, was in objektorientierter Programmierung ein „code smell“ ist, und entsprechend selten kommt das vor. Wer routinemässig mit `isinstance()` den Typ von Funktions- oder Methodenargumenten testet, will eindeutig kein Python verwenden.

[lvlanson]

@lvlanson: In ganz wenigen Fällen und sicher nicht *so* wie in Deinem Beispiel. Das nimmt man in wenigen Fällen wo man bei unterschiedlichem Datentyp auch anderen Code laufen lassen will, was in objektorientierter Programmierung ein „code smell“ ist, und entsprechend selten kommt das vor. Wer routinemässig mit `isinstance()` den Typ von Funktions- oder Methodenargumenten testet, will eindeutig kein Python verwenden.

Ich weiß nicht ob ich dieser Einschätzung beipflichten würde.

Zufällgerweise habe ich ein Video gerade gesehen, was über ein solches Vorgehen spricht. Das würde ich mal mit OP teilen. Es geht um die Bibliotheken dataclasses und attr

Ich teile das Video dazu.

https://youtu.be/vBH6GRJ1REM

[__blackjack__]

@lvlanson: Bei dem Video habe ich nicht lange schauen müssen. Der hat im ”normalen” Beispiel schon mit Typannotationen überall angefangen. Und kurz danach macht er alle Attribute mit zwei Unterstrichen ”private”. Der will also auch gar keinen Python verwenden sondern eigentlich eine andere Programmiersprache. So überhaupt kein empfehlenswertes Video.

[lvlanson]

@lvlanson: Bei dem Video habe ich nicht lange schauen müssen. Der hat im ”normalen” Beispiel schon mit Typannotationen überall angefangen. Und kurz danach macht er alle Attribute mit zwei Unterstrichen ”private”. Der will also auch gar keinen Python verwenden sondern eigentlich eine andere Programmiersprache. So überhaupt kein empfehlenswertes Video.

Was spricht dagegen diese Attribute private zu machen? Verstehe deine Kritik nicht. Verstehe auch nicht, warum Python nur "auf die eine Art und Weise" zu verwenden ist. Es ist eine Programmiersprache, die objektorientierung unterstützt. Weshalb sollte man die Variablen nicht private machen sollen?

[Sirius3]

Es gibt kein "privat" unter Python. Doppelte Unterstriche haben in seltenen Fällen (Mehrfachvererbung) ihre Berechtigung. Ein einfacher Unterstrich sagt dem Nutzer der Klasse: "lass mal die Finger von"; und das reicht als Konvention.

[bords0]

Es gibt kein "privat" unter Python. Doppelte Unterstriche haben in seltenen Fällen (Mehrfachvererbung) ihre Berechtigung.

Ich dachte immer, das wäre, um Namenskollisionen mit Unterklassen zu verhindern (evtl. auch versehentliche solche Kollisionen). Dass das bei Mehrfachvererbung auch verwendet wird, habe ich noch nirgends gelesen. (Ernsthaft verwendet habe ich doppelte Untertriche noch nie.)

Hast du einen Link zu doppelten Untertrichen bei Mehrfachvererbung? Haben dann die Basisklassen gleiche Attribute, die kollidieren? Klingt interessant (und extrem ungewöhnlich, aber das mag an meiner begrenzten Erfahrung liegen).

[Sirius3]

Bei einfacher Vererbung weiß man ja, welche Attribute die Basisklasse verwendet und kann so Kollisionen vermeiden.

Zum Video:
weil total_ordering etwas langsamer ist, definiert er lieber alle Vergleichsoperationen: "Premature optimization is the root of all evil"
Vor allem stellt sich mir die Frage, warum er Kommentare nach dem Inhalt sortieren will?

[kbr]

In dem Video steckt eine Menge YAGNI um die Vorteile von Dataclasses zu zeigen, wenn man dies denn alles bräuchte. Inklusive type-annotations, die bei Dataclasses zwingend sind. Leider wird nicht erwähnt, dass die Instanziierung von Dataclasses sehr teuer und nur sinnvoll für langlebige Objekte ist, die häufig gebraucht werden. Und wenn "private" Attribute außerhalb eines Vererbungskontextes verwendet werden, wird sofort klar, dass hier Vorgehensweisen aus anderen Programmiersprachen auf Python angewandt werden, auch wenn dies dem Konzept von Python widerspricht. Das gleiche bei type-checking; dies ist in Python zwar möglich für den Notfall, üblicherweise aber ein code-smell oder Entwurfsfehler. Auch NotImplemented bei einem fehlgeschlagenem Vergleich aufgrund von unterschiedlichen Typen auszulösen, ist aus meiner Sicht ein solcher. Entweder ist es implementiert oder es wird ein TypeError ausgelöst. Dann wird auch sofort klar, wo das Problem liegt. Für jemanden, der idiomatisches Python lernen möchte, wird dieses Video den Weg dorthin verlängern.