Suche leicht verständliche OSS

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
ford
User
Beiträge: 19
Registriert: Dienstag 2. Januar 2018, 19:07

Hey,

ich bin derzeit dabei Python zu lernen. Ich habe nun einen Kurs auf Udemy durch gemacht. Nun kann das eigentlich lernen beginnen. Also ich suche ein Projekt welches gut und eher einfach verständlich geschrieben ist.
Würde halt die Stufe Code lesen betreten, damit ich danach Code schreiben kann bzw es lernen kann...

Kennt da jemand eins, gibt es vlt irgendwo ne gute Liste?

Vielen Dank
LG ford
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Du kannst zb einfach durch die standardbibliothek von Python selbst schauen. Oder auf github ein Projekt suchen das etwas tut, das dich interessiert.
Benutzeravatar
ford
User
Beiträge: 19
Registriert: Dienstag 2. Januar 2018, 19:07

Danke, standardbibliothek ist ne gute Idee. Aber bei irgendeinem interessanten Projekt weiß ich ja nicht ob das nun gut geschrieben ist oder nicht und eigne mir evtl. schlechten Stil an, oder ist meine Überlegung gerade falsch? :)
Benutzeravatar
pixewakb
User
Beiträge: 1409
Registriert: Sonntag 24. April 2011, 19:43

Es gibt wie bei Literatur Vorlieben - ich würde PEP8 lesen (umzusetzen versuchen) und dann mal in kleinere Projekte reinschauen, die interessant sein könnten.
Hart mit Bart
User
Beiträge: 25
Registriert: Dienstag 30. Oktober 2018, 12:05

Was spricht denn gegen ein eigenes Projekt? Ich habe auch gerade erst mit Python angefangen, nachdem ich einen Einsteigerkurs (Youtube Video, 4+ Stunden) durchgearbeitet habe. Dann habe ich mir ein eigenes Projekt gewählt (ein kleines Spiel auf Textbasis). Was du als nächstes lernst, ergibt sich dann von selbst aus der Notwendigkeit heraus, deinem Script neue Funktionen zu geben.
Schlechten Stil gewöhnst du dir gar nicht erst an, wenn du ab und zu jemanden über dein Script drüberschauen lässt. Zum Beispiel hier im Forum.

Ich weiß natürlich nicht, welches Grundlagenwissen du dir bis jetzt angeeignet hast und wo du letztendlich hin willst. Mit Python kann man sich da offenbar stark auf ein Gebiet spezialisieren. Davon abhängig ist natürlich auch, welche Art von Projekt du für dich wählst. Es sollte schon realistisch bleiben. Das beugt Frustration vor und erhält die Langzeitmotivation.
Für mich ist das die beste Art zu lernen, wenn auch etwas unstrukturiert. Fremde Quelltexte lesen ist immer so eine Sache. Ob deren Stil nämlich so viel besser ist als deine, steht in den Sternen. Kommt natürlich sehr auf die Quelle an. Und ich präge mir am besten Lösungen ein, wenn ich den fehlerhaften Code selbst fabriziert habe.

Nur ein paar Gedanken, von Anfänger zu Anfänger.
Benutzeravatar
pixewakb
User
Beiträge: 1409
Registriert: Sonntag 24. April 2011, 19:43

+1 Die Idee finde ich gut, so habe ich das auch eigentlich gelernt. (Du könntest noch zu User Group-Treffen gehen, wenn es welche gibt. Manchmal kann man von den Leuten Quellcode sehen oder aber mal in ihre Github-Accounts schauen...)
Benutzeravatar
ford
User
Beiträge: 19
Registriert: Dienstag 2. Januar 2018, 19:07

Danke, ich hab mich jedoch gegen ein eigenes Projekt entschieden weil ich andere nicht nerven möchte. Also diese keinen hässlichen Code zur Verbesserung geben möchte..
3ch lange vor dem Congress) mit nem TickTackToe angefangen, jedoch war da ein Bug drin den ich nicht gefunden habe. Entweder diesen beheben oder was vlt leichter ist: das Projekt komplett neu zu schreiben wäre interessant. Auch wenn es vermutlich interessanter wäre das Projekt zu debuggen, da ich somit etwas was ich vor ner Weile nicht geschafft habe verbessern kann...

Ich habe halt vor kurzem einen WebCrawler programmiert und dieser Code war nicht schön. Habe ihn dann hier verbessern lassen und habe mich dann dumm gefühlt. :D


Hier ist der Code vor der Verbesserung: https://github.com/ford42/CrawlerHeise/ ... 1cb46ff4c4 und hier nachdem ein User ihn umgeschrieben/verbessert hat: https://github.com/ford42/CrawlerHeise/
Also wenn jemand Lust hat kann er ihn ja mal anschauen. Nicht um ihn zu verbessern, das wurde ja schon gemacht sondern um ein Bild von meiner noch vorhandenen Unfähigkeit zu machen. :)


Vielen Dank
LG ford

PS: So eine User-Group wäre schon nice, aber das ist da wo ich wohne nicht möglich. Ich kann auch nicht zum erfa oder Hacker-Space kommen. Die sind immer unter der Woche und da könnt eich frühestens um 3 morgens daheim sein und um 6:50 muss ich wieder aufstehen um in die Ausbildung zu gehen und da bringt mir Python leider nicht wirklich viel...
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Danke, ich hab mich jedoch gegen ein eigenes Projekt entschieden weil ich andere nicht nerven möchte. Also diese keinen hässlichen Code zur Verbesserung geben möchte..
Den Ansatz bzw. Gedankengang halte ich für _komplett_ falsch. Lerning by Doing ist 100x effektiver als lesen und nichts machen. Bei Learning by Doing macht man aktiv Fehler und kann diese aktiv verbessern. Da bleibt mehr hängen als beim reinen Lesen.
Und "nerven" kannst du so wie so nicht. Foren wie diese basieren auf freiwilliger Mitarbeit. Falls z.B. mich etwas nervt, dann ignoriere bzw. deabonniere ich den Thread einfach. Fertig, nerven abgestellt.

Ob Code von anderen gut ist oder nicht kannst du so wie so als Anfänger nicht beurteilen. "Safe" bist du IMHO nur, wenn du bekanntermaßen etablierten Code wie z.B. die Python Standard Libs liest. Oder von flächig etablierten Projekten wie z.B. Flask, request, SQLAlchemy usw. Der ist aber wahrscheinlich so komplex, dass du den als Einsteiger eh' nicht durchblickst. Von daher...

Ein sehr gutes Buch, was genau in die Richtung geht, ist übrigens: The Hitchhiker's Guide to Python: Best Practices for Development
Sehr lesenswert.

Auch für ambitionierte Einsteiger sehr empfehlenswert für einen breiteren Überblick: https://pymotw.com/3/

Gruß, noisefloor
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Man sollte vielleicht noch dazu sagen, dass es den „Hitchhiker's Guide to Python“ auch legal, online als HTML zum lesen gibt. Und es gibt dort doch tatsächlich ein Kapitel das Projekte zum Lesen von gutem Code vorschlägt: https://docs.python-guide.org/writing/reading/ :-)
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Wobei die Auswahl IMHO mit Vorsicht zu genießen ist. Habe mir allein mal die __init__.py von requests angesehen, wo bereits einige fragwürdige Dinge gemacht werden:
  • Eigene Funktionen zum Prüfen von installierten Versionen anstatt die Möglichkeiten von pip zu nutzen
  • Ein starker Hang zur Verwendung von assert-Statements im Produktivcode
  • Massig Imports, die erst nach der Definition von Funktionen kommen
Also ich finde das nicht so empfehlenswert. Gerade für Anfänger nicht, da diese möglicherweise unreflektiert den Codestil übernehmen.
Benutzeravatar
ford
User
Beiträge: 19
Registriert: Dienstag 2. Januar 2018, 19:07

Danke euch! :))
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@snafu: Was ist gegen ``assert``\s einzuwenden?
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

snafu hat geschrieben: Donnerstag 1. November 2018, 10:22 Ein starker Hang zur Verwendung von assert-Statements im Produktivcode
Wo sollen die denn sonst stehen? Du schreibst doch hoffentlich keinne assert-Statements(!) in Test-Code? Die werden bei Angabe des -o -Argumentes an den Python-Interpreter rausgeworfen. Womit sie sich nicht mehr im Produktivcode befinden, und gleichzeitig Tests kaputt sind ;)
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@__deets__: Jetzt wo ich so drüber Nachdenke: Vielleicht haben ja `pytest`/`nose` tatsächlich dazu geführt, dass es Leute gibt, die denken das ``assert`` (nur) für Unit-Tests ist. Denn da stehen die natürlich auch massenhaft. :-)
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Assertions gehören in Tests oder können beim Debuggen hilfreich sein. Sie sind aber kein Ersatz an Stellen, wo eine reguläre Exception sinnvoller ist.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das ist mit einer solchen Absolutheit ausgedrueckt Unfug. Ein assert im Code dokumentiert eine Annahme ueber eine Invariante, die verhindert, dass eine unklare Exception spaeter tiefer im Code ausgeloest wird, oder gar ein unbemerktes Fehlverhalten auftritt. Selbstverstaendlich sollte man sie nicht zur Flusskontrolle benutzen. Aber ob dein Programm nun mit einem IndexError oder einem AssertionError abbricht, ist unerheblich. Und sich die Muehe zu machen, anwendungsspezifische Exceptions zu erstellen, wenn sie keine *sinnvolle* Behandlung ermoeglichen, ist verlorene Zeit, die besser in guten Code gesteckt wird.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

In dem von mir monierten Modul (https://github.com/requests/requests/bl ... _init__.py) werden durchgängig asserts bei den Versionsprüfungen verwendet. Der Aufrufer prüft entsprechend auf einen AssertionError. Klar kann man das so machen: Es scheint nur intern benutzt zu werden und als Programmierer kann man damit schön faul sein, weil man weniger Hirnschmalz für passende Exceptions benötigt (wie ja schon angesprochen wurde). Ein Beispiel für vorbildlichen Code, den man Anfängern ans Herz liegt, ist das jedoch nicht. Einfach weil es streng semantisch gesehen kein Anwendungsfall für eine typische Zusicherung ist. Zumindest habe ich das nicht so gelernt...
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@snafu: Vielleicht erklärt sich das ja zusammen mit Deiner Bemerkung das für solche Abhängigkeiten ``pip`` zuständig ist. Denn wenn es das ist, und dort alles korrekt geregelt ist, dann dürfen diese Zusicherungen nicht auslösen. Also sind das genau die Fälle für die Zusicherungen gedacht sind: Sachen die eigentlich *nie* schief gehen können, weil sonst intern etwas falsch gemacht wurde, was ein Benutzer der Bibliothek nicht fixen kann/sollte. Denn wenn diese Versionsprüfungen schief laufen, dann müssen ja die Autoren von `requests` ihre `setup.py`/`requirements.txt`/… anpassen.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ich stimme dir zu, dass die Verwendung von asserts wie in dieser Zeile https://github.com/requests/requests/bl ... t__.py#L88 kritisch ist. Das haette ich wahrscheinlich nicht so gemacht.

Allerdings gibt es durchaus mildernde Begleitumstaende: der gesamte Code dient letzlich dazu, eine Warnung auszuspucken, und scheint extrem lokaler Natur zu sein. Es ist also kein *oeffentliches* API. Sondern eine Abkuerzung, um sich eine Kaskade von

if <cond>: raise Exception

Aufrufen zu sparen. Kann man machen. Muss man aber nicht. Und klar, diese feinziesielierten Unterschiede erkennte der Anfaenger auch eher nicht.

Deswegen sind asserts im Produktivcode noch immer kein Codesmell. Das ist halt ein Fall von Kontrollfluss via assert. Und auf diese sehr generelle Aussage bezogen sich meine Antworten.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Noch als Nachtrag zu meiner Vermutung: ”Früher” waren `urllib3` und `chardet` ”vendorized”, d.h. `requests` hat da Kopien von in der eigenen Package-Struktur mitgeliefert, da waren die Versionen und damit die Prüfung tatsächlich komplett `requests`-Interna.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Antworten