Fragen über Fragen
Wir haben uns ausnahmsweise mal tagsüber zusammengesetzt, um uns anhand von ein paar Fragen über Python zu unterhalten.
Inspiriert von "My Python Development Environment, 2020 Edition" versuche ich hier gerade mal Dinge in einem Github-Repository zu sammeln, die nützlich sein können, wenn man eine Python Entwicklungsumgebung aufsetzen will. Momentan ist das etwas maclastig, weil ich üblicherweise auf Macs arbeite. Aber wenn jemand für Linux oder Windows ähnliche Tipps hat, freue ich mich natürlich immer über pull requests :). Hier gehts zum Repository.
Shownotes
Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de
News aus der Szene
Fragen
- Home Assistant
- alt.sysadmin.recovery manpages
- Not invented here (NIH)
- Python Modules / Packages
- Borg Pattern
- Python Classes/Objects
- classmethod staticmethod
- Primer on Decorators
- functools.wraps
- Closures
- Mixins
- Monkeypatching
- Function argument unpacking
- Lambda expressions
- Container datatypes - UserList / UserDict etc
- Shallow and deep copy operations
- Redux
- Object serialization: pickle marshal shelve
- Introspection: help dir
- Thread-based parallelism
- asyncio - Asynchronous I/O
- Coverage.py
- Profiling
- kcachegrind
Picks
Öffentliches Tag auf konektom
-
lioman on 12. Januar 2020 19:22 reply
Das ist das tatsächlich der hauptusecase für die knappen 80 Zeichen. Wir hatten erst immer auf 120 vergrößert. Inzwischen sind wir wieder beim Default. Diffs egal, ob im Browser oder lokal beim entwickeln sind einfacher zu lesen. Vor allem hat man ja auch nicht immer noch zwei große Monitore angeschlossen.
-
Jürgen on 3. März 2020 20:14 reply
Toller Anwendungsfall für `classmethods` sind `factories`.
Und Reeeespekt. Gar nicht so einfach so viele Konzepte aus dem Stand heraus zu erklären, gerade wenn man sonst gar nicht darüber nachdenkt!
-
Jochen on 4. März 2020 06:23 reply
Ohja stimmt, sowas in der Art, oder? https://github.com/python/cpython/blob/eb8ac57af26c4eb96a8230eba7492ce5ceef7886/Lib/collections/__init__.py#L1038
Da braucht man die Klasse natürlich für. Danke auch :).
-
-
Alpengreis on 20. Mai 2020 22:09 reply
Wieder einiges gelernt, danke!
-
Alpengreis on 9. Juli 2020 21:46 reply
- Betreffend IO.Multiplexen und dem Verteilen auf mehrere CPUs:
Threads (oder Async IO) für IO-lastige Sachen ... das ist mir soweit klar - könnte man dann aber für CPU-lastige Dinge nicht das Multiprocessing-Modul verwenden, gemäss folgender Webpage z.B.? ...
https://timber.io/blog/multiprocessing-vs-multithreading-in-python-what-you-need-to-know/
- Betreffend random.randinit(1,10):
Da reicht dies eben nicht, sondern der Zufallsgenerator muss auch jeweils initialisiert werden mit: random.seed()
-
Jochen on 10. Juli 2020 08:07 reply
Ja, wenn man CPU-bound ist, baucht man mehrere Prozesse in Python. Aber den Empfehlungen der verlinkten Seite würde ich jetzt nicht so unbedingt folgen (die ist fachlich eher so meh). Schau dir mal das concurrent.futures modul an:
https://docs.python.org/3/library/concurrent.futures.html
Bücher, in denen gut beschrieben wird, was man da so machen kann sind Effective Python oder Fluent Python.
Was auch super ist, gerade wenn man Last auch über mehrere Maschinen verteilen möchte, ist dask:
https://youtu.be/ods97a5Pzw0
-
-
Jochen on 10. Juli 2020 08:12 reply
Echt, man muss seed immer aufrufen? Ich kenne das eher so, dass man seed immer mit dem gleichen Integer (viele nehmen die Jahreszahl) aufruft, um reproduzierbare Ergebnisse zu bekommen, wenn man irgendwo zufällig Dinge aufteilt oder so..
-
Alpengreis on 11. Juli 2020 17:50 reply
Ob das wirklich so ist, weiss ich ehrlich gesagt auch nicht. Aber da Dominik eben gesagt hatte, er bekommt immer den gleichen Wert raus, wäre das in diesem Fall wohl die Lösung??
Ich werde das auf jeden Fall demnächst eh testen, da ich ein kleines Projekt habe, in das ich "random" noch einbauen muss ...
-
Alpengreis on 14. Juli 2020 03:06 reply
Ja, Du hast schon recht, dass mit dem gleichen Integer reproduzierbare Ergebnisse "forciert" werden, wie z.B. mit:
import random
for i in range(2):
random.seed(2020)
for i in range(20):
print(random.random())
print()Im Gegensatz zu Folgendem:
import random
for i in range(2):
random.seed()
for i in range(20):
print(random.random())
print()Aber eben auch das Gegenteil ist der Fall, weil bei Nicht-Verwendung es offenbar sein kann, dass immer die gleichen Werte herauskommen (je nach System), siehe z.B. hier:
https://stackoverflow.com/questions/33806022/random-randint2-12-returns-same-results-every-time-its-run-in-python
Wegen dieser Gefahr habe ich mich perslönlich dazu entschlossen, immer zuerst den Zufallsgenerator zu initialisieren (natürlich NICHT mit gleicher Ganzzahl), sondern eben nur mit (), dann wird laut:
https://pynative.com/python-random-seed/
zuerst eine Betriebssystemspezifische Zufallsquelle - und wenn das fehlschlägt - die aktuelle Systemzeit verwendet.
Ich selbst hatte zwar immer andere Werte bei meinen bislang nur kurzen Tests ohne random.seed, das MUSS aber eben scheinbar nicht immer so sein und deshalb ist mir wohler, jeweils ein "random.seed()" zu verwenden.
-
-
-
Alpengreis on 9. Juli 2020 21:47 reply
Ah ja, eine EDIT-Funktion für die Beiträge hier wäre auch noch schön :-)
-
Jochen on 10. Juli 2020 08:09 reply
Ja, edit wäre schön, aber dafür müsste man sich dann einloggen können (was auch ginge, aber hmm... mal drüber nachdenken) :). Wenn ich nur mal schnell was ändern soll, kann ich das auch einfach so machen..
-
Alpengreis on 11. Juli 2020 17:51 reply
Ist ja auch nichts schlimmes, OBWOHL ... bei meinen Tipp-Feeehlern manchmal :-)
-
-
Alpengreis on 14. Juli 2020 22:01 reply
PS: Ich hatte übrigens den Code INKL. Leerzeichen hier gepastet ... die werden aber anscheinend verschluckt, wie auch gewollte Leerzeilen, um Abschnitte übersichtlicher darzustellen ...
-
Alpengreis on 15. Juli 2020 00:01 reply
PPS:
Und auch die Replies scheinen (manchmal) nicht an der richtigen Stelle zu erscheinen ...So, nun genug gemeckert ... aber es ist ja nur konstruktiv gemeint!!
-
Jochen on 16. Juli 2020 13:05 reply
Nee, ist gut. Hilft dabei uns dazu zu bringen, dass das hier mal weitergeht :).
-
Alpengreis on 17. Juli 2020 17:47 reply
Oder vielleicht geht es ja (als Workaround sozusagen) mit "Non-Breakable-Spaces" und "break"? Das geschützte Leerzeichen "Alt+0160" ist wohl nicht so geeignet dazu. Mal nur kurz testen, wenn Du erlaubst (sehe es eben noch nicht in der Vorschau-Ansicht) ... (sonst einfach löschen bitte):
1) Test nur mit "Non-Breakable-Spaces":
Zeile 1 - uneingerückt
Zeile 2 - sollte eingerückt sein (4 "Non-Breakable-Spaces" verwendet)
Zeile 3 - uneingerückt2) Test mit "Non-Breakable Spaces" und zusätzlich vorangehendem/abschliessendem code-Attribut, um Monospace-Font zu verwenden:
<code>
Zeile 1 - uneingerückt
Zeile 2 - sollte eingerückt sein (4 "Non-Breakable-Spaces" verwendet)
Zeile 3 - uneingerückt
</code>3) Hier noch ein Test für Newlines mit "Non-Breakable-Spaces" mit folgendem "br":
<br>
<br>
Oberhalt dieser Linie sollten 2 Newlines eingefügt worden sein ...-
Alpengreis on 17. Juli 2020 17:47 reply
Nope, das war nix, sorry!
-
-
-
-
Jochen on 16. Juli 2020 13:04 reply
Ja, die Formatierungsmöglichkeiten sind hier sehr rudimentär. Vielleicht mal ein
https://github.com/discourse/discourse dranklemmen oder so.
-
-
-
Alpengreis on 11. Juli 2020 17:53 reply
Ok, besten Dank, auch für den Link!
-
Johannes Mueller on 6. November 2024 02:56 reply
Hallo : )
Ich war auf Ihrer Webseite python-podcast.de welche ich sehr ansprechend finde, mir sind jedoch ein paar technische Fehler aufgefallen.
Ich bin auf ein paar versteckte Technische- und Ladezeit-Fehler auf Ihrer Website gestoßen das führt auch bei Google zu einer schlechteren Auffinbarkeit für python-podcast.de ,die sich negativ auf Ihre Sichtbarkeit und die Benutzerfreundlichkeit auswirken könnten.
Diese Probleme sind oft schwer zu finden, Sie können Tools wie
*entfernt* nutzen
um heraus zu finden was gerade Besucher und Kunden kostet?Beste Grüße aus Stuttgart
Johannes Müller-
Jochen Wersdörfer on 7. November 2024 15:48 reply
Hmm, ist das jetzt Spam oder nicht? Habe mal den Link entfernt, aber lasse den Kommentar drin 😄.
-
scatty on 23. Dezember 2019 20:39
Die Zeilenumbrüche von black führen zu lesbareren Diffs. Vor allem bei Code Review kann man dadurch auf einen Blick sehen, was sich genau geändert hat.
Ich musste mich auch erst daran gewöhnen, aber mittlerweile möchte ich es nicht mehr missen.