[Python-de] Python3 und "file"-Objekte

Bernd Nawothnig Bernd.Nawothnig at t-online.de
Sa Mär 2 14:06:14 CET 2013


On 2013-03-02, Stefan Schwarzer wrote:
>>> Mach keinen Typecheck sondern prüfe auf das Interface:
>>>
>>> if hasattr(source, "read"):
>>>     ...
>> 
>> Was natürlich keineswegs dasselbe ist. Tausende von Klassen können
>> eine Methode read haben, ohne dabei auch nur im entferntesten vom Typ
>> file zu sein.
>
> Prinzipiell ist das richtig. Glücklicherweise geht es aber
> bei den meisten Anwendungsfällen nur darum, zwei Typen zu
> unterscheiden. :-) Das heißt, so lange du keinen String-Typ
> mit einer `read`-Methode hast, sollte alles glatt gehen.
>
> Natürlich kann man darüber diskutieren, ob man ein
> Interface, das abhängig vom Typ eines Objekts
> unterschiedlichen Code ausführt, überhaupt haben will.

Richtig. Das würde ich auch eher in Frage stellen.

> Besser finde ich zwei (oder gegebenenfalls mehr)
> Funktionen/Methoden, die Objekte unterschiedlicher Typen
> erwarten. Man sieht diesen Ansatz zum Beispiel bei den
> "Konstruktoren" `datetime`, `fromtimestamp` und
> `fromordinal` in der `datetime.datetime`-Klasse.
>
> Im konkreten Fall geht es aber wohl erst mal "nur" um
> die grundsätzliche Python-3-Kompatibilität und nicht um
> Refaktorierung.

Warum will man überhaupt Python2 Abwärtskompatibilität?

Bis auf weniges kann ich alle Änderungen in Python3 nachvollziehen und
würde niemals wieder zu Python2 zurück wollen.

Z.B. schreibe ich in Python3 ausdrücklich kein

class A(object):
    ...

mehr.

class A:
    ...

ist kürzer und besser lesbar. Und die Anwender *sollen* das
ausdrücklich gar nicht mit Python2 ausführen können, denn die Zukunft
gehört eindeutig Python3. Zwei Versionen zu unterstützen, kostet
unnötig Wartungszeit und geht an der offiziellen Zielsetzung vorbei.




Bernd


Mehr Informationen über die Mailingliste python-de