Fragen über Fragen

, Jochen

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

Picks

Öffentliches Tag auf konektom

  • scatty on 23. Dezember 2019 20:39 reply

    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.

  • 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ückt

            2) Test mit "Non-Breakable Spaces" und zusätzlich vorangehendem/abschliessendem code-Attribut, um Monospace-Font zu verwenden:
            <code>
            Zeile 1 - uneingerückt
            &nbsp;&nbsp;&nbsp;&nbsp;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":
            &nbsp;<br>
            &nbsp;<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 😄.

cancel reply

Return to blog