Python 3000 alpha1 ist draußen!...

BlackVivi · Freitag 31. August 2007, 22:47

LINK!

Ladet es mal und gebt

print "Hello World!"

ein!^_^

Edit (Leonidas): Titel angepasst.

Y0Gi · Freitag 31. August 2007, 23:27

Du meinst die (irgendwie in der Praxis abstoßende) Tatsache, dass `print` von einem Statement zu einer Funktion "degradiert" wurde?

BlackVivi · Freitag 31. August 2007, 23:34

Y0Gi hat geschrieben:Du meinst die (irgendwie in der Praxis abstoßende) Tatsache, dass `print` von einem Statement zu einer Funktion "degradiert" wurde?

Joa, schon....

So abstoßend find ich's aber nich. Hab ein paar Zeilen Code geschrieben und irgendwie lässt's sich besser lesen...

Außerdem find ich bei dem neuen Print die Argumente end und sep total toll.

BlackJack · Freitag 31. August 2007, 23:37

Also hier das korrekte Beispül:

Code: Alles auswählen

bj@s8n:~$ python3.0
Python 3.0a1 (py3k, Aug 31 2007, 21:20:42)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> täst = 'Hallo Welt!'
>>> print(täst)
Hallo Welt!

BlackVivi · Freitag 31. August 2007, 23:49

Python 3000 gefällt mir ziemlich gut. Wird aber sicherlich noch eine Zeit dauern, bis die ganzen Bibliotheken in PEP3000 portiert werden.

BlackJack · Samstag 1. September 2007, 09:35

Python 3.0 wird ja auch noch eine Zeit auf sich warten lassen. Da bleibt also noch Zeit. Ich persönlich warte erst einmal auf Python 2.6, da soll es ja eine Möglichkeit geben, Programme so laufen zu lassen, dass man auf Inkompatibiliäten mit 3.0 hingewiesen wird. Da kann man dann langsam anfangen zumindest Teile von Anwendungen so umzuschreiben, dass sie auf beiden Versionen laufen. Eventuell ist es ja sogar möglich es soweit anzupassen, dass das Umwandlungsskript `2to3.py` den Rest besorgt und man für den Übergang mit *einer* Quelltextbasis auskommt.

gerold · Samstag 1. September 2007, 10:47

Y0Gi hat geschrieben:Du meinst die (irgendwie in der Praxis abstoßende) Tatsache, dass `print` von einem Statement zu einer Funktion "degradiert" wurde?

Schade, ich hatte mich schon so an Python gewöhnt...

mq · Samstag 1. September 2007, 11:03

*kratz* vllt. sollte man noch erwaehnen, dass das die Alpha 1 ist, das hat bisher keiner getan.

Nebenbei sind die ganzen Aenderungen (auch print) schon ewig bekannt, wieso regt ihr euch da jetzt drueber auf? Oh, und Unicode-Identifier stinken, da fangen die Leute sofort an, Zeichen einzubauen, die der Grossteil der Welt (u.A. ich) nicht auf der Tastatur hat, was die Programme deutlich schwerer editierbar macht...

gerold · Samstag 1. September 2007, 11:15

Hallo lumax!

lumax hat geschrieben:Nebenbei sind die ganzen Aenderungen (auch print) schon ewig bekannt

Ich habe mich schon damals darüber aufgeregt...
--> http://www.python-forum.de/post-20044.html#20044

print hat jeder schon irgendeinmal gehört und jeder versucht sich zuerst mit print "Hallo". Warum soll man solche Erfolgserlebnisse erschweren? Es gibt Befehle, die so einfach wie möglich gehalten werden müssen. Ich finde sogar, print soll es egal sein, ob es mit oder ohne Klammern aufgerufen wird.

(http://www.python-forum.de/post-20065.html#20065)

lg
Gerold

BlackJack · Samstag 1. September 2007, 11:47

@lumax: Das halte ich für Panikmache. Jemand der Wert darauf legt, das sein Quelltext "international bearbeitbar" bleibt, wird bei der ASCII Untermenge bleiben.

mq · Samstag 1. September 2007, 12:12

BlackJack hat geschrieben:@lumax: Das halte ich für Panikmache. Jemand der Wert darauf legt, das sein Quelltext "international bearbeitbar" bleibt, wird bei der ASCII Untermenge bleiben.

Klar, das ist etwas uebertrieben, die meisten werden schon weiterhin ASCII-Identifier benutzen. Aber ich bin sicher, dass ich frueher oder spaeter ueber solchen Code stolpern werde.

penguin-p · Samstag 1. September 2007, 14:07

gerold hat geschrieben:print hat jeder schon irgendeinmal gehört und jeder versucht sich zuerst mit print "Hallo". Warum soll man solche Erfolgserlebnisse erschweren? Es gibt Befehle, die so einfach wie möglich gehalten werden müssen. Ich finde sogar, print soll es egal sein, ob es mit oder ohne Klammern aufgerufen wird.

Das stimmt, trotzdem ist es schlicht inkonsequent, ein eigenes Schlüsselwort für print zu führen, wenn es doch genauso einfach und ohne wirklichen Mehraufwand seitens des Programmierers als Built-In Function implementiert werden kann.
Damit wird die Zahl der Schlüsselworte minimiert und die Sprache insgesamt logischer und konsistenter.
Außerdem ist damit die Frage geklärt, wieso für Bildschirmausgaben ein solcher Sonderweg existiert, nicht aber für Tastatureingaben, was ja eigentlich nur der umgekehrte Weg ist. Aber input und raw_input sind schon seit je her Built-Ins.

mq · Samstag 1. September 2007, 15:22

penguin-p hat geschrieben:Aber input und raw_input sind schon seit je her Built-Ins.

raw_input? Welches raw_input?

BlackVivi · Samstag 1. September 2007, 15:43

lumax hat geschrieben:
penguin-p hat geschrieben:Aber input und raw_input sind schon seit je her Built-Ins.
raw_input? Welches raw_input?

Er meint wohl input. Und mit input meint er eval(input()). Jeder macht mal einen Fehler

penguin-p · Samstag 1. September 2007, 16:57

Hach mein geschätztes raw_input *schnief*

Was ich aber noch viel tragischer finde ist, dass True und False in Python3000 Schlüsselwörter werden. Das war immer so ein lustiger Zeitvertreib:

Code: Alles auswählen

>>> a = True
>>> True = False
>>> False = a
>>> True
False
>>> False
True

mq · Samstag 1. September 2007, 17:30

penguin-p hat geschrieben:Hach mein geschätztes raw_input *schnief*

Was ich aber noch viel tragischer finde ist, dass True und False in Python3000 Schlüsselwörter werden. Das war immer so ein lustiger Zeitvertreib:
Code: Alles auswählen
>>> a = True
>>> True = False
>>> False = a
>>> True
False
>>> False
True

Das ist doch erst dann richtig lustig, wenn du die builtins monkeypatchst und damit True und False auch in allen anderen Modulen verkehrt rum funktionieren

Sr4l · Samstag 1. September 2007, 18:25

Ich fand es zuerst ganz schlecht das `print` zu einer Funktion wurde.

Bin aber nun froh das es so ist, ein Anwendungsfall:

Code: Alles auswählen

sr4l@LARS:~$ python3.0
Python 3.0a1 (py3k, Sep  1 2007, 03:28:18) 
[GCC 3.4.6 (Ubuntu 3.4.6-5ubuntu1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print("Test")
Test
>>> def print(value):
...     handle = open("output.txt","a")
...     handle.write(value)
...     handle.close()
... 
>>> print("Test")
>>>

Ich kann also das `standard` print zum Beispiel einfach überschreiben und dann alles was sonst geprintet wurden wäre in eine Datei um leiten oder ähnliches.

Die viele gute Sachen bei Python bleiben ja immer noch.

veers · Samstag 1. September 2007, 18:48

Du kannst print auch jetzt umleiten in dem du stdout umleitest.

BlackVivi · Samstag 1. September 2007, 19:06

Sr4l hat geschrieben:Ich kann also das `standard` print zum Beispiel einfach überschreiben und dann alles was sonst geprintet wurden wäre in eine Datei um leiten oder ähnliches.

Die viele gute Sachen bei Python bleiben ja immer noch.

Wie umständlich

!

Code: Alles auswählen

fl = open("foo.txt", "w")
print("foobaaaar!!!", file=fl)
fl.close

Leonidas · Samstag 1. September 2007, 19:18

veers hat geschrieben:Du kannst print auch jetzt umleiten in dem du stdout umleitest.

Genau. Entweder sys.stdout umeiten oder (Achtung, dämliche Syntax) ``print >>sys.stdout "Irgendwas`` wobei man ``sys.stdout`` gegen ein file-like-Objekt tauscht.

Ich werde mit dem Python 3.0 testen erst anfangen wenn jemand es für Debian paketiert, damit ich es Backporten kann. So spannend ist es nun auch nicht, denn im SVN war es schon lange verfügbar, also hätte man es sich schon vorher laden können.