[Python-de] urllib2 und tarfile

[Olе Streicher]

"Diez B. Roggisch" <deets at web.de> writes:
>>> Ich weiß ja nicht wie das bei dir ist, aber ich denk mir schon dass
>>> tell()` oder `seek()` auf einem Stream ja semantisch schon irgendwie kaum
>>> Sinn machen.
>>  tell() hat doch durchaus sinn: selbst wenn man nicht (zurück-)spulen kann,
>> möchte man vielleicht wissen, wo man gerade ist.
> Dafuer einen Zaehler mitzufuehren ist zu kompliziert?

Es macht den Code komplizierter, ja.

> Und was heisst "wo man gerade ist" - seit man sich selbst mit dem
> Stream verbunden hat, oder [...]

Seit open().

>> Ein Code der Art
>> c = fd.read(1);
>> len = fd.read(1);
>> if c != MAGIC_START:
>> fd.seek(len, os.SEEK_CUR) # skip to next record

> Lass mich mal kurz überlegen. Ah, ich weiss:
> fd.read(len) statt fd.seek(len, os.SEEK_CUR)
> macht dasselbe.

Nein. read() liest, und seek() verändert den Positionszeiger (was
implizit zum Lesen führen kann, wenn es sich um einen Socket handelt).

> Und was genau ist daran besser, ein seek zu haben, dass potentiell mit einer
> Exception aussteigt, weil es eben nur vorwaerts moeglich ist? Diese Semantik
> wird bereits ausreichend von read erfuellt.

Die Idee von Python ist ja gerade, eine Exception erst dann zu werfen,
wenn sie auch relevant ist -- also bei einem seek, der nicht
funktioniert (weil rückwärts). Warum wird das hier nicht umgesetzt?

> Damit illustrierst du hier auch noch gleich selbst, dass einzig und
> alleine ein ausdefiniertes Interface nicht notwendigerweise eine
> Verbesserung darstellt. Denn statt "file like mit der Unterstuetzung
> von seek" ist es nun "file-with-seek-like, aber bitte nicht nur
> vorwärts-seeks, ich will's in alle Richtungen". Was also entweder auch
> wieder zur Laufzeit kracht, oder deine Interface-Definitionen nochmal
> feiner aufdroeselt, bis zur Unkenntlichkeit.

Warum "bis zur Unkenntlichkeit"?

>> "Use the source, luke!" stammt aus dem letzten Jahrtausend.

> "Wenn's compiliert, muss ich nicht testen" ebenfalls.

Klar. Deshalb sollte man auch beides tun. Was hat das mit dem Thema zu tun?

>>  Ein Programm von mir hat z.B. numpy, scipy, pyfits, matplotlib, pywcs,
>> pyds9, pyQt. Jedes dieser Pakete sowie Python selbst liegen in 2-3 halbwegs
>> aktuellen Versionen vor. Das macht 100e Kombinationen, die zu testen wären,
>> nur um sicherzustellen, dass nicht irgendein Objekt tief in einer der
>> Bibliotheken erzeugt wurde, und die Verwendung an anderer Stelle in dieser
>> Kombination nicht mehr kompatibel ist.

> Festzulegen, welche Versionen du unterztuetzt, waere zu einfach? 
> Machen alle anderen eigentlich.

Ja. Weil jeder auch andere Programme einsetzt. Wenn alle das gleiche
machen, dann will jedes Programm gerne seine eigenen Versionen von
numpy, scipy, pywcs, pyds9, pyQt usw. haben. Selbst wenn man das
durchführen kann, ist man als Anwender dann nur damit beschäftigt, sich
die passenden Paketversionen für seine Anwenderprogramme zu
beschaffen. Es sei denn, jedes Programm bringt die benötigten
Zusatzpakete gleich mit. Das wäre das Äquivalent zum statischen Linken.
Sehr modern heutzutage.

Für packages ist es noch schwieriger. Wenn ein package foo-1.0
unterstützt, ein anderes dagegen foo-1.01: wie kann ein Anwender beide
Pakete in einem Script einsetzen?

>>  Selbst C hat irgendwann gelernt, dass ein Header-File mit
>> int foo(double *bar, char **faz);
>> sinnvoller ist als ein
>> /* int foo(); (no need to declare this at all) */
>
> Kannst ja mal die WINE-Leute fragen, wie sehr sich die "stabile" win32-API mit
> einzelnen Builds von Windows aendert, und wie sehr sie dem
> hinterherprogrammieren muessen.

Was willst Du damit sagen? Das die Einführung von ANSI-C sinnlos war,
weil sie nicht zu perfekten Programmen geführt hat?

Ole