Python 3.7.0 is now available (and so is 3.6.6)

Gute Links und Tutorials könnt ihr hier posten.
Antworten
Benutzeravatar
ThomasL
User
Beiträge: 1366
Registriert: Montag 14. Mai 2018, 14:44
Wohnort: Kreis Unna NRW

Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Tholo
User
Beiträge: 177
Registriert: Sonntag 7. Januar 2018, 20:36

Einen Interessanten Artikel zu Py3.7 hab ich auf Heise Dev gelesen.

Ich persönlich kann die "großen" Neuerungen in 3.7 nicht fassen. Da ich keine Berührungspunkte bisher habe. Aber der Dekorator @Dataclass sieht schon mal sehr Interessant aus. Man spart sich das Initialisieren.

Code: Alles auswählen

from dataclasses import dataclass

@dataclass()
class Produkt:
    name: str
    preis: float
    anzahl: int = 0

    def gesamt_wert(self) -> float:
        return self.preis * self.anzahl

test = Produkt(name= "lala",preis= 0.3, anzahl= 2)
print(test.gesamt_wert())
Built-in breakpoint pep 553
In Sachen debugger bin ich völlig Unbedarft. Habt ihr dazu Meinungen? Ich arbeite mit Pycharm (Pro weil ich remote Interpreter [Pi´s, Odroid´s] anspreche) Da gibt es doch so was ähnliches oder? Nun ist es halt built-in.


pep 562 customization-of-access-to-module-attributes versteh ich überhaupt nicht. Es wird nur 1 bestimmtes Attribut aus dem Modul geladen und wenn es nicht vorhanden ist, aus dem Modul Ordner? Könnt ihr mir das vielleicht Erläutern?

Was denkt ihr über 3.7?
Benutzeravatar
ThomasL
User
Beiträge: 1366
Registriert: Montag 14. Mai 2018, 14:44
Wohnort: Kreis Unna NRW

Bzgl. des neuen Moduls dataclasses hatte ich mir die Tage schon einen Talk von Trey Hunner angeschaut.
https://www.crowdcast.io/e/fresno-easier-classes

Ich denke mal, wie immer werden diese Neuerungen Zeit brauchen, bis sie ankommen.
Habe mal in einer VM 3.7 installiert und versucht, ein paar der Module mit denen ich so arbeite, zu installieren.
Einige haben da so ihre Probleme. Also erstmal warten angesagt, bis diese angepasst sind.
Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Tholo: Re customization-of-access-to-module-attributes: Man kann halt in Modulen mit `__getattr__()` und `__dir__()` sagen was passiert wenn auf nicht vorhandene Attribute des Moduls zugegriffen wird und wenn mit `dir()` abgefragt wird welche Attribute es gibt. So wie man das auf eigenen Datentypen auch jetzt schon machen kann wenn man diese beiden Methoden in der Klasse implementiert. Ist ”Magie” die man normalerweise nicht braucht, aber wenn man sie braucht ist es praktisch.

Die `breakpoint()`-Funktion ersetzt im groben die beliebte Zeile ``import pdb; pdb.set_trace()``. Mit ein paar praktischen Konfigurationsmöglichkeiten. Wie das abschalten ohne den Aufruf aus dem Quelltext nehmen zu müssen, oder das man da auch andere Debugger einhängen kann.

Was ich so über die 3.7 denke: Hey, die 3er hat jetzt die gleiche Minor-Version wie die 2.7, die ich noch nahezu ausschliesslich einsetze. Und `dataclasses` sieht so aus als wenn diese doofe typing endgültig „pythonisch“ wird und das damit irgendwie nicht mehr meine Sprache ist. :evil: Bin gespannt was mit der 2.7 in etwas weniger als zwei Jahren passiert.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Tholo
User
Beiträge: 177
Registriert: Sonntag 7. Januar 2018, 20:36

Ich hab gerade mal mich durch ein paar Blogs gearbeitet. Weitere Infos zu 3.7
Hierbei realpython.com und das Thema Breakpoint wird auf Hackermoon besprochen
Muss mir das mal in Ruhe zu gemühte führen.

@blackjack
Was meinstz du mit "doofen" Typing? Ich hab keine präpython coding Erfahrung. Aber ich denke mir, du bist mit Codeschnipseln aus anderen Sprachen in Python rein unzufrieden oder?

@ThomasL
Mein "neusten" liebstes Spielzeug ist Pipenv in Pycharm (zZ die EAP Version, noch nicht Stable) Das arbeiten mit Venv und Pip innerhalb der Venv wird zum Augenschmaus. Zumindest für mich als Anfänger. Daher hab ich gleich eine 3.7 pipenv erstellt aber mit ähnlichen Erfahrungen. Bei Gelegenheit will ich mal Kivy-nightbuild in 3.7 ausprobieren.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Tholo: Mit doofem Typing meine ich, dass das immer mehr und mehr nach Java aussieht und Python immer mehr Richtung ”optionale” statische Typisierung geht.

Ich würde Deine Produktklasse zum Beispiel ungern mit `float` verwenden, Du schreibst das ja aber im Grunde mit der Typisierungsinfo so vor. Warum kein `float`? Nun ja, ich bin halt der Meinung das wenn man 10 verschiedene Produkte a 10¢ kauft, man einen summierten Gesamtpreis von genau einem Euro haben sollte und nicht ungefähr ein Euro:

Code: Alles auswählen

#!/usr/bin/env python
from __future__ import absolute_import, division, print_function
from decimal import Decimal
from attr import attrs, attrib


@attrs
class Product(object):
    name = attrib()
    price = attrib()
    count = attrib(0)
    
    @property
    def total_price(self):
        return self.price * self.count


def main():
    for i, price in enumerate([0.10, Decimal('0.10')]):
        products = [
            Product('Widget Mk{}'.format(i), price, 1) for _ in range(10)
        ]
        total = sum(p.total_price for p in products)
        print(format(total, '.50f'), total == 1)


if __name__ == '__main__':
    main()
Ausgabe (vielleicht für den ein oder anderen der sich noch nicht näher mit `float` beschäftigt hat überraschend):

Code: Alles auswählen

0.99999999999999988897769753748434595763683319091797 False
1.00000000000000000000000000000000000000000000000000 True
Und in dem Quelltext sieht man dann auch gleich warum mich Dataclasses auch in Python 3.7 nicht vom Hocker hauen würden: das `attr`-Modul kann das alles auch schon seit Jahren, auch mit Python 2.7, und es kann noch mehr als Dataclasses.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Bezeichnender ist es, dass seit sieben Minor-Versionen immer noch versucht wird, den Fehler, über alles Unicode drüberzustülpen, weiter auszubügeln.

Bei Dataclasses habe ich mir gedacht, warum landet ein Modul mit viel Magie in der Standardbibliothek? Das mischen von Klassenattributen mit Instanzattributen wird sicher auch wieder zu lustigen Effekten bei Anfängern führen.

@Tholo: die Einführung von Typeannotations haben genau dazu geführt, was ich befürchtet hatte. Anfänger bekommen von Lehrern, die vorher Java unterrichtet haben, eingebleut ihren ganzen Code mit Type-Boilerplate zuzumüllen. Vorteil: Keiner

Magic-Functions auf Modulebene sind ganz nett, hab ähnliches schon durch Klassen simuliert.

Viel interessanter sind eigentlich die kleinen Änderungen:
- bytes.fromhex ignoriert Leerzeichen
- collections.namedtuple() now supports default values.
- datetime.fromisoformat
Benutzeravatar
DeaD_EyE
User
Beiträge: 1012
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Ich nutze Python 3.7 schon produktiv und hab dann komischerweise noch direkt einen Bug in meinem Programm gefunden.

Lediglich für Numba musste ich noch den release candidate von llvmlite und numba installieren.
Alles andere funktioniert bis jetzt wunderbar und die Prozesse starten sogar etwas schneller als zuvor auf dem embedded System.

Was mir besonders gefällt, ist jetzt die Möglichkeit mit asyncio.run() coroutinen direkt auszuführen.

Python 2.7 wird man entsorgen, ob es euch gefällt oder nicht. Niemand wird sich antun den Code weiterhin für uns kostenlos zu pflegen.
Es wird sicherlich Unternehmen geben, die dann Python 2.7 weiterhin anbieten, dafür aber Geld verlangen. Drauf verlassen würde ich mich aber nicht.

Mir soll es egal sein. Python 2.7 nutze ich schon lange nicht mehr.


PS: datetime.fromisoformat cool. Da muss ich mal gleich iso8601 wieder entfernen :-)
@Tholo: die Einführung von Typeannotations haben genau dazu geführt, was ich befürchtet hatte. Anfänger bekommen von Lehrern, die vorher Java unterrichtet haben, eingebleut ihren ganzen Code mit Type-Boilerplate zuzumüllen. Vorteil: Keiner
Echt jetzt?! Vielleicht sollte denen mal jemand erklären, dass das eher für Libraries genutzt wird.
Ein 500 Zeilen langes Programm mit Typeannotations zu versehen, halte ich für übertrieben. Der Code sieht dann auch so hässlich aus!
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@DeaD_EyE: Aber Lehrer/Dozenten wollen halt das man an den Übungsaufgaben und dem was sie vortragen sieht, dass sich über die Typen Gedanken gemacht wurde. Die meisten die nicht mit Lisp oder Scheme die Grundlagen gelernt haben, kommen ”pädagigisch” eher so aus der Richtung Pascal und später dann Java, wo statische Typisierung eine gaaaaanz wichtige Sache ist. Wenn man das nicht macht, stürzt der Himmel ein! Je komplizierter und spezifischer die Typsysteme sind, um so besser. Man muss das alles gleichzeitig so genau und präzise als auch so generisch wie möglich verwendbar *formal* spezifizieren. Nur dann sind Inf-Lehrer/-Profs richtig glücklich. :-)
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Tholo
User
Beiträge: 177
Registriert: Sonntag 7. Januar 2018, 20:36

__blackjack__ hat geschrieben: Samstag 30. Juni 2018, 13:01 Ich würde Deine Produktklasse zum Beispiel ungern mit `float` verwenden, Du schreibst das ja aber im Grunde mit der Typisierungsinfo so vor. Warum kein `float`? Nun ja, ich bin halt der Meinung das wenn man 10 verschiedene Produkte a 10¢ kauft, man einen summierten Gesamtpreis von genau einem Euro haben sollte und nicht ungefähr ein Euro
Das Beispiel ist nicht von mir sondern aus dem Heise Dev Artikel. Dort wurde das Float mit Euros im übrigen auch diskutiert. Hab es aber nicht umgestellt, da ich es für mich Beispiel als ausreichend angesehen habe.
https://pypi.org/project/money/ wurde da genannt
DeaD_EyE hat geschrieben: Samstag 30. Juni 2018, 13:32
@Tholo: die Einführung von Typeannotations haben genau dazu geführt, was ich befürchtet hatte. Anfänger bekommen von Lehrern, die vorher Java unterrichtet haben, eingebleut ihren ganzen Code mit Type-Boilerplate zuzumüllen. Vorteil: Keiner
Echt jetzt?! Vielleicht sollte denen mal jemand erklären, dass das eher für Libraries genutzt wird.
Ein 500 Zeilen langes Programm mit Typeannotations zu versehen, halte ich für übertrieben. Der Code sieht dann auch so hässlich aus!
Really? Genau damit habe ich mich heute in einem Buch von Paul Berry (O´Reilly Verlag) beschäftigt.

Code: Alles auswählen

def search4letters(phrase: str, letters: str='aeiou') -> set:
    """Return a set of the 'vowels' found in 'phrase'."""
    return set(letters).intersection(set(phrase))
Und ihr mein nun, dass die Annotation nicht diesen Stellenwert haben sollten? Sondern eher ein guter DocString oder?
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@Tholo: welchen Mehrwert sollten diese komischen Dinge nach Pfeilchen oder : denn haben? Sie schränken nur die eigentlichen Nutzen der Funktionen ein, da letters ein String sein muß, kein Set, kein Iterable, keine Liste, ...

Hier spart man sich also nicht nur unnötige Tipparbeit, erhöht die Lesbarkeit sondern erweitert auch noch die Anwendbarkeit.

Code: Alles auswählen

def search_for_letters(phrase, letters='aeiou'):
    """Return a set of the letters found in 'phrase'."""
    return set(letters).intersection(phrase)
Benutzeravatar
ThomasL
User
Beiträge: 1366
Registriert: Montag 14. Mai 2018, 14:44
Wohnort: Kreis Unna NRW

Also ich habe extra noch mal nach recherchiert da ich das hier im Kopf hatte bzgl. Annotations:

What are Function annotations?
Function annotations are arbitrary python expressions that are associated with various part of functions.
These expressions are evaluated at compile time and have no life in python’s runtime environment.
Python does not attach any meaning to these annotations.

They take life when interpreted by third party libraries, for example mypy.
Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@ThomasL: Die Frage ist was ist ”Python” hier? Der Interpreter interpretiert die nicht weiter, aber Guido sagt das ist für Typannotationen, das `typing`-Modul in der Standardbibliothek ist für Typannotationen, Data Classes interpretieren das als Typannotationen, das Standarddokumentationswerkzeug (Sphinx) interpretiert das als Typannotationen, die Beispiele in der Python-Dokumentation zeigen Typannotationen, IDEs interpretieren das als Typannotationen aus, und Werkzeuge wie `mypy` und `pytype` gehen davon aus, dass es Typannotationen sind.

Da jetzt zu sagen das Python den Annotationen keine inhaltliche Bedeutung gibt, ist schon ein wenig irreführend. Wenn man das für etwas anderes verwendet, kämpft man gegen die Standardbibliothek, diverse Werkzeuge, und die Erwartung des Lesers an. Das mag ja theoretisch möglich sein, macht aber mehr Ärger als es bringt.

In der Zeit als Guido noch gesagt hat, guckt mal, hier habt ihr neue Syntax für die es noch keinen Verwendungszweck gibt, denkt euch mal was schönes aus, hat es zudem kein bekannteres Projekt tatsächlich für irgend etwas genutzt. Oder habe ich da irgendwas verpasst? Kennt jemand etwas? Ich glaube einen Parsergenerator habe ich mal gesehen, der Annotationen für etwas anderes als Typinformationen verwendet hat.

Das mit der Syntax die für nix gut ist, fand ich sowieso von Anfang an bizarr bis suspekt wenn ich daran denke wie die Devs und Guido sich sonst immer gesträubt haben gegen neue Syntax solange es nicht eine sehr gute Begründung und einen Anwendungszweck im Vorfeld gab.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Benutzeravatar
ThomasL
User
Beiträge: 1366
Registriert: Montag 14. Mai 2018, 14:44
Wohnort: Kreis Unna NRW

also ich hatte mal vor Monaten diesen Talk bzgl. "Type hints" aus 2015 von Guido angeschaut, war ganz informativ
https://www.youtube.com/watch?v=2wDvzy6Hgxg

bzgl. Dataclasses ist dieser Talk hier von Raymond Hettinger ein Mustview:
https://www.youtube.com/watch?v=T-TwcmT6Rcw
Ich bin Pazifist und greife niemanden an, auch nicht mit Worten.
Für alle meine Code Beispiele gilt: "There is always a better way."
https://projecteuler.net/profile/Brotherluii.png
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Angesichts der Fortschritte, die statisch typisierte sprachen machen (zb rust und kotlin), kann ich den Wunsch, da voran zu kommen, durchaus verstehen. Denn so wie es aussieht konvergiert die Entwicklung: die statischen erlauben immer deklarativerer Ausdrucksweisen. Und die dynamischen wollen immer effizientere Ausführung erzielen, und haben dabei Vorteile wenn es typannotationen gibt. PyPy ist zwar toll, aber der jit warmup nicht für jeden anwendungszweck erträglich, und die Ergebnisse auch schwerer vorhersagbar. Und angesichts der sich deutlich verlangsamenden CPU-Geschwindigkeitssteigerung ist das “free lunch” halt vorbei. Da muss man effizienter mit den resourcen umgehen.

Insofern sehe ich das alles nicht so dramatisch.
Benutzeravatar
sls
User
Beiträge: 480
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Country country = new Zealand();

Der "rein informative" Gehalt der Typ-Annotations war für mich als Java-Entwickler erstmal positiv, da ich nichts kaputt machen kann und sofort erkenne, welcher Datentyp an eine Methode / Funktion oder Klasse zu übergeben sind, und besonders, was diese dann ggf. zurückliefern. Das Problem mit Docstrings ist einfach, dass diese so unterschiedlich gehalten werden können, je nach verwendetem Dokumentationsframework. Typ-Annotations können helfen, Code besser zu verstehen in dem Elemente zur Vereinheitlichung eingeführt werden.

Die Schwächen der Typ-Annotations sind, paradoxerweise, gleichzeitig die von mir ursprünglich ausgemachten Vorteile: rein informativ. Es hilft mir gar nichts, wenn ich statt einem int einen float übergebe, und mir das erst in der Code-Logik um die Ohren fliegen *kann*. Was mich schon immer genervt hat ist Code anderer, die eine Variable mit Typ X initialisieren der dann 100e Zeilen später in Typ Y umgebügelt wird. Leider ist Rust noch nicht so weit, dass man damit Rest-APIs in Produktion schreiben möchte. Hier kann ich zumindest bestimmten, ob ein Datentyp statisch oder dynamisch typisiert ist respektive mutable oder eben nicht. Vielleicht sollte man über sowas auch mal in Python nachdenken.
When we say computer, we mean the electronic computer.
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

@sls: Mir gehen diese type-annotations gehörig auf den Zeiger. Sie erschweren die Lesbarkeit und bringen keinen Mehrwert, eher betrachte ich sie als Einschränkung. Ich kann verstehen, dass Umsteiger von statisch typisierten Sprachen in Python zunächst große Unsicherheit oder auch Haltlosigkeit verspüren, da die Sicherheit der Typ-Prüfung durch einen Compiler entfällt und ihnen somit eine Schutzmaßnahme zu fehlen scheint, die spätere Runtime-Fehler zu vermeiden hilft. Dieser Eindruck täuscht.
Antworten