Das deutsche Python-Forum

@Francesco: Dein Schluss ist einfach nicht haltbar. Es gibt mehr englischsprachige Bücher weil es eine grössere Zielgruppe gibt, okay, aber warum dadurch die Wahrscheinlichkeit steigen sollte ein *gutes* Buch zu erwischen ist nicht nachvollziehbar. Man könnte ja sogar gegenteilig argumentieren, dass es mehr schlechte Bücher gibt, weil bei der grossen Zielgruppe sich jeder Depp als Autor versucht. Die Qualität von Büchern hängt ja nicht von der grösse der Zielgruppe, sondern vom können der Autoren ab.

Ich finde englische Fachliteratur auch oft besser, aber ich denke das hat nicht viel mit Wahrscheinlichkeitslehre zu tun, sondern eher mit dem Verständnis von Wissensvermittlung in den entsprechenden Kulturkreisen. Deutsche Fachliteratur gibt teilweise ganz gerne damit an wie präzise, knapp, und *unverständlich* man Sachverhalte ausdrücken kann, während bei englischer Fachliteratur oft Beispiele und Analogien zusätzlich zu den knappen formelhaften Sätzen genannt werden. Also "wir sind Elite, das soll nicht jeder verstehen" vs. "Joe der Automechaniker soll das auch verstehen können wenn er nicht auf den Kopf gefallen ist."

Francesco hat geschrieben: Ehm, was hoert sich da falsch an? 300 Mio. Amerikaner (vielleicht - xx Millionen spanischsprechende), 60 Mio. Briten, Australien, Südafrika, ...)

Warst du in Südafrika? Da kommt man häufig nicht allein mit Englisch weiter

@Blackjack
Nun ja, es wird mehr Bücher geben (sowohl schlechte als auch gute). Was ich da an den deutschen Büchern oft bemängle, ist der trockene Stil. Wenn ich an die Schulzeit zurückdenke, was besonders in technischen Sachen zugemutet wurde, das hat mir das Lernen schon recht vermiest. Ich habe schon einige englische Programmierhandbücher gesehen, und die haben oft Abbildungen, tw. auch recht lustige. Und oft ist es so, dass es zu einem Thema gar keine deutschen Bücher gibt, weil es sich aufgrund der geringen Zielgruppe gar nicht "auszahlt". Ich denke da an wxpython in Action zb.

vielen lieben Dank für die gute Resonanz.

Habe fürs Buch von Michael Weigend entschieden. Ich bin aber immer wieder erstaunt, wie stark die Abhängigkeit vom Internet fürs Erlernen einer Programmiersprache ist. Trotz dem dicken Buch bin ich oft erst durch Stöbern von Informationen im Internet "zufrieden". Ganz unabhängig in welcher Sprache die Erklärungen sind, sind die unterschiedlichen Ausdrucksweise einfach hilfreich. Wenn frau auf einer Seite das Thema nicht versteht, schlägt frau ne andere Seite auf und wenn frau Glück hat, ist die Beschreibung für eine verständlicher.

Ein Beispiel bzw. eine Frage

das Modul codecs.

It defines the following functions:
codecs.register(search_function)
codecs.lookup(encoding)
codecs.open(filename, mode[, encoding[, errors[, buffering]]])
usw..

Wie ist codecs in z.B. codecs.lookup(encoding) gemeint? Ist codecs hier ein vordefiniertes Objekt in der gleichnamigen Klasse codecs? Also, wie cout oder cin in C?

Im nächsten Abschnitt der Doku stehen dann ein paar Methoden folgender Form:
Codec.encode(input[, errors])

Also, Codec statt codecs. Wie ist Codec hier gemeint?

Als wäre das noch nicht genug:
class codecs.StreamReader(stream[, errors])
...

nun mit einem "class" davor.

Hilfe, Jungs..

Schönen Dank,

Eure Ratna

ratna_fong hat geschrieben:das Modul codecs.

It defines the following functions:
codecs.register(search_function)
codecs.lookup(encoding)
codecs.open(filename, mode[, encoding[, errors[, buffering]]])
usw..

Wie ist codecs in z.B. codecs.lookup(encoding) gemeint? Ist codecs hier ein vordefiniertes Objekt in der gleichnamigen Klasse codecs? Also, wie cout oder cin in C?

Wie in der Dokumentation steht ist es das Modul ``codecs`` das die Funktionen ``register``, ``lookup``, ``open`` etc. definiert.

ratna_fong hat geschrieben:Im nächsten Abschnitt der Doku stehen dann ein paar Methoden folgender Form:
Codec.encode(input[, errors])

Also, Codec statt codecs. Wie ist Codec hier gemeint?

Steht doch direkt oben drüber, muss man nur lesen:

7.8.1.1. Codec Objects hat geschrieben:The Codec class defines these methods which also define the function interfaces of the stateless encoder and decoder:

ratna_fong hat geschrieben:Als wäre das noch nicht genug:
class codecs.StreamReader(stream[, errors])
...

Da wird der Konstruktor der StreamReader-Klasse dokumentiert.

Leonidas hat geschrieben: Wie in der Dokumentation steht ist es das Modul ``codecs`` das die Funktionen ``register``, ``lookup``, ``open`` etc. definiert.

codecs.register(search_function)
Ist codecs hier ein Objekt? Um genauer zu sein, ein vordefiniertes Objekt? Gehe ich stark davon aus.

Leonidas hat geschrieben: Steht doch direkt oben drüber, muss man nur lesen:
The Codec class defines these methods which also define the function interfaces of the stateless encoder and decoder:
Codec.encode(input[, errors])

Hier gehe ich zwar ebenfalls stark davon aus, dass Codec ein Objekt ist. Da aber im vorigen Abschnitt "codecs" statt wie hier "Codec" verwendet wird, bin ich mir unsicher, vielleicht hat diese Differenzierung eine bestimmte Bedeutung?

Zu meiner letzten Frage:
class codecs.StreamReader(stream[, errors])
Dass dies ein Konstruktor ist, ist mir sogar klar, aber der Ausdruck "class codecs.StreamReader" macht mich stutzig. Ich habe mich gefragt, "was ist das? class, codecs. codecs ist doch ein Objekt, davor noch class, häää??"

@ratna_fong: Natürlich ist `codecs` ein Objekt -- alles in Python was man an einen Namen binden kann ist ein Objekt. Es ist das *Modul*. Du liest doch da gerade die Dokumentation zum `codecs`-Modul.

Und auch `Codec` ist ein Objekt, nämlich ein Klassenobjekt. Im Modul `codecs`. Dessen Dokumentation Du ja gerade liest.

Das ist Dokumentation und kein Quelltext. Das `class` steht da wahrscheinlich damit man die Signatur nicht für eine Funktion hält, sondern für den "Konstruktor"-Aufruf.

Du könntest auch mal eine Python-Shell bemühen und Dir das selbst "live" anschauen.

vielen Dank BlackJack und Leonidas,

codecs und codec scheinen tatsächlich vordefinierte Objekte der Klasse codecs zu sein. Wirklich wie cout oder cin bei C.
cout << = cout.ausgabemethode(parameter)

Also, wie:
codecs.open(parameters)


Nun, zu dieser Struktur:
class codecs.IncrementalEncoder([errors])
Ich glaube, das besagt:
1. Die Objekte der Klasse IncrementalEncoder sind von uns Programmierern selbst zu erstellen.
2. codecs ist die Basisklasse der Klasse IncrementalEncoder.

Danke für die Methoden- bzw. Konstantenliste des Objekts codecs, BlackJack.

Eure Ratna

ratna_fong hat geschrieben:codecs und codec scheinen tatsächlich vordefinierte Objekte der Klasse codecs zu sein. Wirklich wie cout oder cin bei C.

Erstens gibt es cout und cin nur bei C++ und zwiten ist ``codecs`` ein einfaches Modul, nicht spezielles. Und codecs.open nur eine simple Funktion in diesem Modul, auch nichts spezielles.

ratna_fong hat geschrieben:class codecs.IncrementalEncoder([errors])
Ich glaube, das besagt:
1. Die Objekte der Klasse IncrementalEncoder sind von uns Programmierern selbst zu erstellen.
2. codecs ist die Basisklasse der Klasse IncrementalEncoder.

Instanzen von IncrementalEncoder sind selbst zu erstellen, ja. Aber codecs ist nicht die Basisklasse sondern das Modul in dem die Klasse definiert ist.

Leonidas hat geschrieben: Erstens gibt es cout und cin nur bei C++ und zwiten ist ``codecs`` ein einfaches Modul, nicht spezielles. Und codecs.open nur eine simple Funktion in diesem Modul, auch nichts spezielles.

vielen Dank Leonidas,

mhh.. ich habe Deine Sichtweise verstanden, das Modul codecs definiert die Funktion open. Aber da man ja beim Coden folgendes schreibt:
codecs.open(...)
das erweckt einen Eindruck, codecs könnte ein Objekt sein.

Das ist jetzt für mich mal interessant, was codecs hier eigentlich ist. Wenn das tatsächlich mit "Objekt" nichts zu tun hat, dann kommt mir das sehr widersprüchlich mit dem objektorientiertem Paradigma, wie ich bisher gelernt und verstanden habe. Denn, der Bezeichner vor einem Punkt deutet eigentlich auf ein Objekt hin.

Vielleicht soll ich generell nicht all zu detailliert/kompliziert denken sondern einfach nur die Werkzeuge anwenden. Vielleicht ist dafür Python geschaffen, diese große Freiheit.

Gruss,

Eure Ratna

codecs ist ein Objekt, nur eben vom Typ module. Falls du es überlesen haben solltest: In Python ist alles was du an einen Namen binden kannst ein Objekt. Wenn es sinnvoll ist, dann bezeichnet man Dinge mit entsprechenden Namen. In den meisten Fällen wirst du ein Auto sicher "Auto" nennen und nicht "Ding", damit du weißt, dass du es zum Beispiel fahren kannst. Versuche das mal mit einem Baum-Ding
Sebastian

ratna_fong hat geschrieben:mhh.. ich habe Deine Sichtweise verstanden, das Modul codecs definiert die Funktion open. Aber da man ja beim Coden folgendes schreibt:
codecs.open(...)
das erweckt einen Eindruck, codecs könnte ein Objekt sein.

Natürlich ist das ein Objekt, denn Module sind auch Objekte.

ratna_fong hat geschrieben:mhh.. ich habe Deine Sichtweise verstanden, das Modul codecs definiert die Funktion open. Aber da man ja beim Coden folgendes schreibt:
codecs.open(...)
das erweckt einen Eindruck, codecs könnte ein Objekt sein.

Ein Modul ist ein Objekt, nur wird es eben nicht instanziiert, sondern importiert.

Vielleicht weil es schon instanziiert wurde? Wie werden Module in Python eigentlich "unter der Haube" implementiert? Warum verhalten sie sich wie Exemplare einer Klasse (wahrscheinlich weil sie auch wirklich Exemplare einer Klasse sind, aber welcher?)?

Ein Modul ist ein Objekt vom Typ types.ModuleType. Man kann auch einfach types.ModuleType aufrufen und in sys.modules ablegen und andere Module können es dann importieren. Man kann selbstverständlich auch davon erben und irgendein Verhalten implementieren.

Neben `types.ModuleType` kann man auch `imp.new_module()` verwenden um ein Modulobjekt selbst zu erzeugen. Und dann könnte man das Modul zum Beispiel mit ``execfile('something.py', a_new_module.__dict__)`` füllen, wenn man das Importieren nachahmen möchte.

das ist sehr interessant.

kann mir vielleicht einer nochmal erklären, was ein Modul eigentlich ist, aus meinem Standpunkt aus, nämlich:
A module is a file containing Python definitions and statements.

Dass ein Modul dann ein Objekt ist, das ist mir echt neu. Ich dachte, ein Modul, z.B. sys ist einfach eine .py-Datei. Ist das nicht so?

Gruss,

Eure Ratna

ratna_fong hat geschrieben:Ich dachte, ein Modul, z.B. sys ist einfach eine .py-Datei. Ist das nicht so?

Ja und nein. Es gibt beispielsweise schon C-Module die deiner Sichtweise wiedersprechen.
Dazu kommt, dass es innerhalb des Interpreters eben kein Verstaendnis von Dateien gibt sondern eben nur von Objekten (grob vereinfacht), beim importieren wird eben nach diesen "speziellen" py-Dateien gesucht und deren ausgewerteter Inhalt an ein neues Objekt gebunden (BlackJacks Snippet zeigt das gut).

Ein Modul ist primär ein Objekt, in dem irgendwelche Attribute zu finden sind. Diese Objekte werden in den allermeisten fällen erstellt indem der Interpreter eine ``.py``-Datei liest und aus den enthaltenen Definitionen und dessen Dateinamen ein Modul-Objekt konstruiert was an den Namen gebunden wird.

Wie BlackJack meinte: alles was man an Namen binden kann, ist in Python ein Objekt.

ratna_fong hat geschrieben:Dass ein Modul dann ein Objekt ist, das ist mir echt neu. Ich dachte, ein Modul, z.B. sys ist einfach eine .py-Datei. Ist das nicht so?

Ein Modul kann eine .py Datei sein muss es aber nicht, sys wird z.B. bei CPython afaik zur Laufzeit erstellt. Dann gibt es noch shared libraries (.so, .dll) die i.d.R. in C geschrieben sind, Module die von Python aus erst zur Laufzeit erstellt werden. Außerdem gibt es noch Packages die eigentlich auch nur Module, die können importiert werden selbst wenn sie gezippt sind.