[Python-de] urllib2 und tarfile

[Diez B. Roggisch]

On Mar 14, 2013, at 12:17 AM, Olе Streicher wrote:

> Marek Kubica <marek at xivilization.net> writes:
>> Wenn man aus der Haskell und ML-Ecke kommt kann man auch sagen, dass es
>> schön wäre wenn Java ein gutes Typsystem hätte dass man statisch
>> verifizieren kann. So Sachen wie QuickCheck sind mit Java nicht
>> machbar, sollten wir jetzt alle nur noch professionelle
>> Haskell-Software schreiben weil das Typsystem nunmal strikt mächtiger
>> ist?
> 
> Ich sehe zumindest in der Java-Welt eine gewisse Diskussion darüber, wie
> das Typsystem zu verbessern wäre. Bei Python (bzw.: de.comp.lang.python)
> wird ja schon der Versuch einer Diskussion abgebürstet mit 
> 
> | Weil auch drei Jahre spaeter einen Wesenskern der Sprach nicht zu
> | akzeptieren irgendwie laecherlich ist?

Siehe meine andere mail.

> 
>> 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? Und was heisst "wo man gerade ist" - seit man sich selbst mit dem Stream verbunden hat, oder seit der begonnen hat zu existieren im Universum, oder seit dem letzten Record, oder… das ist mit anderen Worten protokollabhaengig, und gehoert nicht ins interface.

> 
> seek() funktioniert dann natürlich nur vorwärts -- aber das kann für
> manche Zwecke schon reichen. Zum Bleistift dafür, ein urllib2-Objekt an
> ein Tarfile zu verfüttern. Das wäre voll im Sinne von Python (nämlich
> Exceptions erst dann zu werfen, wenn die Probleme auch relevant werden).
> 
> 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
> else:
>   pass # process magic record
> 
> würde natürlich auch bei Streams einen Sinn haben, warum denn nicht?

Lass mich mal kurz überlegen. Ah, ich weiss:

fd.read(len) statt fd.seek(len, os.SEEK_CUR)

macht dasselbe.

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. 

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.

> 
>>> Es ist also *kein* unveränderlicher Wesenskern der Sprache.
>> Also geht es dir um die Dokumentation?
> 
> Nein. Um eine formale, testbare Beschreibung des Interfaces.

-> Typpruefung, macht Python nicht, ist Wesenskern. 

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

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

> ... und mit jeder neuen Version von Python oder eine Bibliothek muss die
> komplette Unit-Test-Suite durchlaufen, damit man sich einigermaßen
> sicher zu sein, ob noch alles läuft? Wenn ich etwas für Kundenrechner
> schreibe, wo die genaue Version der Pakete nicht bekannt ist, soll ich
> alle möglichen Kombinationen durchprobieren?

Ja. Und ja, wenn du das unterstuetzen willst. Und in dem Absatz darfst du uebrigens Python auch gerne mit Java, C++, .NET und allem anderen ersetzen. Eine Sprache oder Oekosystem, dass zur gleichen Zeit Fortentwicklung von APIs und Bibliotheken erlaubt und gleichzeitig Stabilitaet allen jemals geschriebenen Codes garantiert gibt es nicht. 

> 
> 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.

> 
> 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) */
> 
> Warum wohl? Hätte eine grobe Beschreibung und "use the source!" nicht
> gereicht?

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.



Diez