[Python-de] urllib2 und tarfile

[Diez B. Roggisch]

On Mar 12, 2013, at 9:42 AM, Olе Streicher wrote:

> "Diez B. Roggisch" <deets at web.de> writes:
>> On Mar 12, 2013, at 7:46 AM, Olе Streicher wrote:
>>> Diez Roggisch <deets at web.de> writes:
>>>> Na, dann verrate doch mal: was *ist* professionell?
>>> Definierte und testbare Interfaces. Ging das nicht aus meiner Kritik
>>> hervor?
>> So wie mein Beispiel aus Java?
> 
> Das habe ich nicht gesagt.
> 
>> Also in meiner nicht-professionellen Erfahrungswelt hat man da genauso
>> Probleme mit Verhalten, dass anders ist, als man es qua Interface
>> erwartet haette.
> 
> Sicher ist auch Java dabei nicht perfekt und hat eine Reihe von
> Problemen mit seinen Interfaces. Das ändert aber nichts daran, dass
> Interfaces und statische Prüfungen ein sinnvoller Weg für gute
> Softwarequalität sind.

also erst ist Java kein gutes Beispiel, aber dann sind Interfaces und statische Prüfungen, die Java besitzt, sinnvoll. Hast du dafuer Belege, das die Qualitaet von Software damit korreliert? 

Also, wenn du nicht Java sagst, was sagst du dann? C++? C#? Irgendwas?

> 
>> Da haette ich mir jetzt schon ein bisschen mehr professionelle
>> Einsicht gewuenscht.
> 
> "Professionelle Einsicht" bedeutet für mich weniger ein
> "Java-vs.-Python"-Flamewar, sondern mehr eine Diskussion der
> zugrundeliegenden Konzepte. Und da sind Argumente in der Art "Auch Java
> hat seine Probleme" irgendwie unsinnig.

Ah. Und so eine Diskussion startet man sinnvoll mit "Python ist Sch*"? 

> 
>>>> Was IMHO übrigens nicht professionell ist, ist sich beständig über
>>>> dieselben Dinge zu beschweren.
>>> Wenn etwas auch nach drei Jahren noch ungeklärt ist: warum nicht?
>> 
>> Weil auch drei Jahre spaeter einen Wesenskern der Sprach nicht zu
>> akzeptieren irgendwie laecherlich ist?
> 
> Man könnte sich übrigens auch Typprüfung vorstellen, ohne auf
> Duct-taping zu verzichten: Wenn die Definition von urllib2.urlopen()
> beispielsweise formal enthalten würde, dass es "ein file-like Object,
> aber ohne tell() und foo(), aber mit bar()" enthält, und die Definition
> von tarfile.open() formal spezifiziert, dass der fileobj-Parameter die
> Methoden "read()" und "tell()" haben muss, wäre zum Einen das Raten
> zuende, zum anderen kann man die Kompatibilität auch unmittelbar
> automatisch prüfen.

Das ist eine etwas konfuse und natuerlich viel zu unkonkrete Umschreibung von statischer Typpruefung durch kleinteilig heruntergebrochene Interfaces. Die Java in der von mir zitierten io-packages durchaus hat, aber selbst die - wie ich schon belegt habe - sind nicht notwendigerweise wohldefiniert. Man koennte das jetzt als Hinweis darauf nehmen, dass es doch nicht so ganz einfach ist.

Python betreibt keine solche statisch Typpruefung. Und das es das nicht tut, sondern stattdessen auf Duck-Typing setzt, das  im uebrigen genau so definiert ist, dass es Schnittstellen und Verhalten *implizit* und letztlich nur zur Laufzeit erzwingt, ist inherent in Python. Eben ein Wesenskern. Das Gegenteil zu behaupten ist absurd.

> 
> Es ist also *kein* unveränderlicher Wesenskern der Sprache.

Und blau ist gruen. 

Wie ueblich ist alles, was du sagst: Python tut nicht was *ich* will, darum ist es doof, es ginge alles viel besser, aber einen Beleg für etwas besseres bleibst du genauso schuldig wie konkrete Vorschlaege fuer Verbesserungen. Sondern hast nicht naeher definierte "Vorstellungen" von einer schoeneren Welt. Ich hoffe, in der ist auch Weltfrieden dabei.

Insofern ist das schon von Beginn an keine Diskussion um Verbesserungen von Python, sondern einfach nur ein kleinlicher Ausbruch ueber einen der ueblichen Problemchen, die man beim programmieren so hat. Dass nur eine Zeile genuegt, das Problem zu loesen - irrelevant.

Diez