|
|
|
|
|
|
|
|
|
|
|
|
|
Dann hör auf, Zahlen zu addieren 
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
| |
| Code: |
list(map(add, liste1, liste2))
|
|
Ohne import:
| |
| Code: |
[sum(x) for x in zip(liste1, liste2)]
|
|
Die Waffe ist immer so scharf wie man sie führt. Ähnlich meinem Hosenskalpell.
| |
Du musst deine Waffe wohl mal wieder etwas schärfen:
list(map(sum, zip(liste1, liste2)))
|
|
|
|
|
|
|
|
|
|
|
|
list um generators finde ich immer inhärent ätzend und vergesse es ständig.
|
|
|
|
|
|
|
|
|
|
|
Was macht den Unterschied aus?
Hey, you do your experiments - I do mine!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
list um generators finde ich immer inhärent ätzend und vergesse es ständig.
| |
ja, kommt glücklicherweise nicht so oft vor, dass man nicht mit dem Generator weiterarbeiten könnte
| | Zitat von Wraith of Seth
Was macht den Unterschied aus?
| |
Zwei Zeichen weniger 
/oder bezieht sich das auf Oli? Über einen Generator kannst du wie über eine Liste iterieren, direkter Zugriff auf ein Element geht aber nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von red am 06.03.2021 13:39]
|
|
|
|
|
|
|
|
|
|
Generators werden lazy ausgewertet und man kann nur zum nächsten Element gehen, nicht zu irgendeinem. Das ist grandios wenn man nicht alles auf einmal berechnen (bzw. eine Datei einlesen, Speicher allokieren, ...) möchte, aber erlaubt keinen wahlfreien Zugriff. list() drumherum werdet den Generator einmal komplett aus, bis er (hoffentlich) sagt "meine Liste ist fertig" und speichert alle Ergebnisse, dass wahlfreier Zugriff möglich ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 06.03.2021 13:40]
|
|
|
|
|
|
|
|
Cool, danke. TIL.
Kanonische Transformationen sind Symplektomorphismen im Phasenraum.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
list um generators finde ich immer inhärent ätzend und vergesse es ständig.
| |
Immer. Immmmmmer.
|
|
|
|
|
|
|
|
|
|
|
Ist tuple um einen Generator besser?
Edit: mit welcher python Version arbeitest du eigentlich SBI? Sicherlich 2.6 oder so
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von PutzFrau am 06.03.2021 14:06]
|
|
|
|
|
|
|
|
|
Also mal ernsthaft: Ist Python das neue JavaScript? Wird einem der grauenhafte Syntax nicht irgendwann zu blöd?
// Jetzt abgesehen vom Generator Syntax, das kommt ja auch quasi überall vor. Aber so generell. Ich würde mir die Haare ausrupfen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 06.03.2021 14:13]
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Ist tuple um einen Generator besser?
Edit: mit welcher python Version arbeitest du eigentlich SBI? Sicherlich 2.6 oder so
| |
Der neuesten, irgendwas 3iges hats inzwischen auf allen Systemen. Aber ich nutze das auch nur für glue code und so.
¤: Java schreibe ich ja auch keines mehr  Jedenfalls beruflich.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 06.03.2021 14:20]
|
|
|
|
|
|
|
|
|
| | Zitat von derSenner
Also mal ernsthaft: Ist Python das neue JavaScript? Wird einem der grauenhafte Syntax nicht irgendwann zu blöd?
| |
Ich finde Python besticht eigentlich durch recht einfache Syntax, die wenn dann manchmal für Bibliothek-Design eher zu simpel ist und einschränkt. Abgesehen von fehlgeleitetem Klammerfetisch sehe ich ehrlichgesagt nicht so recht, was gerade an der Syntax grauenhaft sein soll. Wenige Sonderzeichen, wenig Magie.
Aber ja, Python ist in zwei ganz wichtigen Aspekten wie JavaScript: Erstens gibt es in der Sprache sehr viele Altlasten, die vermutlich nur schwer loszuwerden sind. Es gibt wenig gescheites etabliertes Tooling und einige Design-Entscheidungen die in den 90ern sicherlich modern waren. Und zweitens, viel schlimmer: Wenn man nach Python-Hilfe im Internet sucht sind quasi alle vorgeschlagenen Lösungen entweder wirklich schlecht oder zumindest veraltet. Als Konsequenz ist die "mittlere Codegüte" im Python-Universum nicht sonderlich hoch. Schade. Als illustrierende und einfache Beispiele empfehl ich mal die Suche nach der Handhabung von Pfaden (os vs. pathlib) oder Stringformatierung (% vs. format vs. f-String). Zur Ehrenrettung sei aber gesagt, dass Python tolle und moderne Dokumentation hat, man müsste sie nur lesen.
Zu dem Thema: Ich bin letztens über einen alten Talk gestolerpt, der ein wenig auf die Historie von Javascript eingeht und erklärt warum eigentlich alles so schlimm ist. Sehr erleuchtend.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 06.03.2021 14:59]
|
|
|
|
|
|
|
|
|
JS, respektive besser TS, ist gar nicht das schlimme, sondern alles drumrum. Vor allem alte Browser sind halt eifach absolut grausam. Die Sprache an sich ginge ja.
¤: Und halt npm, ne. Webpack auch der Graus.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.03.2021 15:01]
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Erstens gibt es in der Sprache sehr viele Altlasten, die vermutlich nur schwer loszuwerden sind.
| |
Da gab's vor >10 Jahren doch so einen Release, der nicht backwards-kompatibel war...
Ich finde Python sehr nice als Glue code für effiziente numerische C/C++/Rust (geil Mann, ja bitte) Bibliotheken. Oder vielleicht auch Python-only für Webserver oder wenn man Stringschubser ist (SBI, bitte kommentieren). Man ist unglaublich produktiv, kann sehr schnell Protoypen erstellen, die standard library ist unglaublich umfangreich (NumPy ist de-facto Teil davon), es gibt eine riesige Community, gerade für wissenschaftliche und numerische Bibliotheken, die eine große Menge an Code bereitstellt. Dazu gibt es einen der besten CLI parser in der stdlib (argparse). (Hier sei für JVM picocli empfohlen. Der erste CLI parser, den ich besser als argparse finde)
Hier sind einige der Punkte, die mich am meisten an Python stören:
Whitespace Bedeutung ist halt echt eine verdammt schlechte Idee. Ich mag Python ganz gerne, aber das sorgt für Bugs, die hart zu debuggen sind. Schlimmer nur in YAML.
Tooling1: Python Code zu schreiben ist super komfortabel, aber Distribution war lange Zeit eine Qual, da man meist auf irgendwelche nativen Bibliotheken aufbaut, oder selbst native Bibliotheken für Python erstellt. Das hat sich drastisch verbessert mit Conda, ist aber bei weitem nicht so komfortabel wie, zum Beispiel, in Java oder Rust.
Tooling2: Es gibt oft viele Lösungen, die sich teilweise ergänzen. Das ist ziemlich unübersichtlich und für den Anfänger nur schwer nachzuvollziehen. Z.B. distutils vs setuptools vs pip vs conda vs poetry oder setup.py vs pyproject.toml etc
GIL macht Python Parallelisierung kompliziert.
Davon ab: Ghyle, ja bitte
edit: Noch einen ganz großen pain point vergessen: import mit side-effects, aber das geht in anderen Sprachen auch, z.B. in Java when static code ausgeführt wird, wenn die Klasse geladen wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von PutzFrau am 06.03.2021 15:30]
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
z.B. in Java when static code ausgeführt wird, wenn die Klasse geladen wird.
| |
Ich möchte festhalten, dass der Typo sehr witzig und bekannt ist.
Jehova! Jehova!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
(SBI, bitte kommentieren)
| |
Flächendeckendes ack. Aber was ist denn ein Stringschubser überhaupt?
¤: Python auf dem Webserver bin ich kein Fan, weil es sich eifach nicht so empfiehlt für die Sachen die wir machen. Kann ich also nicht viel zu sagen. Ich denke für simple APIs und schnelles prototyping aber schwer zu schlagen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.03.2021 15:51]
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
was ist denn ein Stringschubser überhaupt?
| |
Weiß ich auch nicht, aber irgendwas muss ich ja sagen, seitdem Java7 passé ist 
|
|
|
|
|
|
|
|
|
|
|
Vermutlich jemand, der mit einem Stringly Typed System arbeitet. 
Aber mal im Ernst: Bugs durch Whitespace in Python? Ich hatte früher welche in Java ("Haha, ich ja nur ne if mit einer Zeile im Block, da kann man Klammern weglassen. Ups!"), aber in den letzten 6 Jahren habe ich nicht einen einzigen Bug gesehen, der durch Whitespacing verschuldet war. Durch meine Inkompetenz hingegen ...
|
|
|
|
|
|
|
|
|
|
|
Ich habe definitiv einige gefixt (nicht meine, ich schreibe ja nie bugs hehe)
|
|
|
|
|
|
|
|
|
|
|
Doofe Frage: Aber was genau ist damit gemeint? Ich weiß ja, dass Whitespace doofer zu sehen ist als, sagen wir, fehlende Semikolons oder sowas, aber der einzige wirklich entscheidende Whitespace in Python ist doch die Einrückung? Was macht die so schwer zu sehen?
...kein Mensch kann sie wissen, kein Jäger erschießen.
|
|
|
|
|
|
|
|
|
|
|
|
Tabs vs Spaces? Python geht an sich auch mit Tabs. Spaces sind nur Konvention. Mixen ist immer doof, bei Python ist's extra kacke.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 06.03.2021 16:44]
|
|
|
|
|
|
|
|
|
Falsche Einrückung kann Fehler erzeugen, die in Sprachen mit geschweiften Klammern so nicht passieren würden bzw. das Tooling könnte mit auto-indent die Fehler offensichtlich machen.
| |
| Code: |
print("block 1")
if True:
print("block 2")
if True:
print("block 3")
print("wieder block 2, aber versehentlich zu weit eingerückt")
|
|
Würde so mit {} nicht passieren oder wäre zumindest einfacher zu erkennen durch automatische Einrückung in der IDE.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
Tabs vs Spaces. Python geht an sich auch mit Tabs. Spaces sind nur Konvention.
| |
Oder gemischt. Und solche Konstrukte gehen auch:
| |
| Code: |
if blub:
bleb
else:
blib
|
|
Aber so etwas nicht:
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Falsche Einrückung kann Fehler erzeugen, die in Sprachen mit geschweiften Klammern so nicht passieren würden bzw. das Tooling könnte mit auto-indent die Fehler offensichtlich machen.
| |
| Code: |
print("block 1")
if True:
print("block 2")
if True:
print("block 3")
print("wieder block 2, aber versehentlich zu weit eingerückt")
|
|
Würde so mit {} nicht passieren oder wäre zumindest einfacher zu erkennen durch automatische Einrückung in der IDE.
| |
| |
| Code: |
print("block 1")
if True:
print("block 2")
if False:
print("block 3")
print("wieder block 2, aber versehentlich zu weit eingerückt")
block 1
block 2 |
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Oder gemischt.
| |
Jo, siehe Edit.
|
|
|
|
|
|
|
|
|
|
|
Jo, True war Platzhalter für beliebige condition. Aber danke für den Fix, wird damit vermutlich verständlicher.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Falsche Einrückung kann Fehler erzeugen, die in Sprachen mit geschweiften Klammern so nicht passieren würden bzw. das Tooling könnte mit auto-indent die Fehler offensichtlich machen.
| |
Da hab ich eher viele Fehler dieser Art in anderen Sprachen gesehen: "Warum wird B gedruckt???"
| |
| Code: |
if (false)
print "A";
print "B"; |
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
Jo, True war Platzhalter für beliebige condition. Aber danke für den Fix, wird damit vermutlich verständlicher.
| |
Ach jetzt verstehe ich es erst, dachte du meinst die letzte Zeile gehöre wieder zum zweiten Block trotz tiefer indentation. Wieso würde man auch so einen Fehler machen :-)
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXIII |
