Die Zukunft von Python

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Also wenn ich das so lese ... wird es mir ganz anders.

Was mich hatl stört, und immer stören wird, sind Veränderunge, dessen Sinn für den Anwender nur jener ist, daß er sich Umstellen muß.

Damit mein ich eben solche Dinge wie das ändern von 'Print' in 'write'(??) oder das mit dem input() ect..

Wenn sich Jemand länger mit der Sprache beschäftigt, oder neue Anfängt, so wie ich, muß er diese erst lernen.
Aber Sinn und Ziel des Ganzen ist es doch, die Sprache irgendwann recht gut zu beherschen, um endlich so richtig zum programmieren anfangen zu können.
Da sind Umstellunge in Form von Namensänderungen unnötiger Lernaufwand, finde ich.
Auch habe ich keine Lust ältere Scripte dann umzuändern (aus 'Print' was weis ich zu machen).
Nunja, ich könnte ja dann einfach bei 2.4.1 bleiben, aber wie sieht es auf dauer mit der Kompatibilität mit den anderen BS es dann aus?
Und wieso 2.4.1? Wieso nicht noch älter?

Ich würde es eher begrüßen und fände es auch wichtig, wenn man mehr auf die privaten Spieleentwickler eingehen würde und standardmäßig an Grafikoptionen was besseres mitreinpackt, als dieses Tkinter.
Dort solte, finde ich, was gemacht werden.
Den das fehlen von Transparenz, oder die fehlende Möglichkeit zum laden von BMP schreckt meiner Meinung nach mehr Leute ab, als die Tatsache, das mnache Befehle 'Print' heißen, und nicht anders.

Auch entwickelt es sich anderweitig mit den vielen Möglichkeiten das Ganze zu tode, finde ich.
Wenn man ein Problem lösen will, könnte man meinen, daß es die Lösung schon gibt. Wobei die Suche nach dem richten Befehl länger dauern kann, als es einfach mit paar anderen Befehlen selbst zu schreiben.
Vieles was da in Python drin ist, scheint mir eher belastend zu sein, als einfach. Und auch nicht auf jeden 100 % zutreffend, aber dafür um so verwirrender, wenn es darum geht, etwas vordefinertes anderweitig zu benutezn, weil vermutlich oft mehres dafür in Frage käme aber zugleich anderweitig als schwierig herrausstellt.

Der einzige Sinn wäre höchstens die Compatibilität, was den Namen und Befehlen zu anderen Sprachen betrifft.
Aber ich kann mir nicht vorstellen, daß man sich für eine Programmiersprach nur wegen identischen Namen entscheidet.
Macht zwar den Wechsel leichter ... aber dies allein wird kaum der Grund sein. Außerdem macht es auch dann den Wechsel weg von Python zur anderen Sprache ebenfalls leichter.
Ich hatte Heute eine andere Programmiersprache ausprobiert, die wiederum ganz andere Befehle hatte. Aber sie schien eben anderweitig interesant zu sein, was Deren Grafischen Möglichkeiten betrifft.
Leider hat ein Turitoral der anderen Programmiersprache meine Gerätedriver abgeschossen. Und sowas sollte nun wirklich nicht vorkommen.
Ansonsten ... wer weis, wärt Ihr mich vielleicht los geworden?
Eben wegen den Änderungen, die da scheibar kommen sollen. Das schreckt mich einfach ab.
Unwichtiges wird da, so sehe ich das, geändert, aber das wichtige scheint keinem zu interessieren.

Und noch was:
Wenn ich zurfrieden bin, hört man meist nichts.
Wenn mir aber was nicht paßt (zb. das Essen nicht schmeckt), dann fange ich an, mich bemerkbar zu machen.
Ich finde es riskant, auf die zu hören, denen Etwas nicht paßt, ohne dabei all Diejenigen, die nichts sagen, als Stille Zufriede zu betrachten. Nämlich jene Stille Zufriedene, die dann meist nach der Änderunge gehen, so zumindest mein Eindruck aus einem ONline-Spiel.
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
mawe
Python-Forum Veteran
Beiträge: 1209
Registriert: Montag 29. September 2003, 17:18
Wohnort: Purkersdorf (bei Wien [Austria])

Hi!

Blackbird, Du verbindest "print" mit dem Drucken auf Papier, ich verbinde "write" mit dem Schreiben in eine Datei ;) Der Name ist historisch bedingt (genauso wie, dass das erste Element eines Arrays den Index 0 hat. Das verwirrt Programmieranfänger sicher auch etwas). Aber jeder weiss was mit print gemeint ist.

Erwin, Dein Post klingt etwas depressiv ;).
Tk ist wahrscheinlich bei Python dabei, weils relativ klein ist. Ich finde auch, dass es am einfachsten zu bedienen ist. Es gab und gibt immer wieder die Diskussion wxPython statt Tk zu nehmen ...

BTW: Welche andere Programmiersprache hast Du Dir denn angesehen?

Gruß, mawe
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

BlackJack hat geschrieben:...
Ich verstehe auch nicht warum die Leute immer so versessen auf "Compiler" und/oder "EXE"n sind. Dann sollen sie doch bitte eine andere Sprache nehmen.
Ganz einfach:
Exe.Dateien lassen sich leichter verteilen.
Unkompiliertes wengier, weil dann auch der Interpreter mit muß. Weil es ist ja nicht sicher, ob Jeder den hat.
Wenn man also nur so vor sich hinprogrammieren will oder innerhalb einer Art geschlossenen Gemeinschaft, ist es nur noch wegen der Geschwindigkeit eine Exe-Datei von Interesse.
Aber wenn man seine Programme maximal unters Volk bringen will, dann geht dies eben nur mit Exe-Dateien.

mawe hat geschrieben:...
Erwin, Dein Post klingt etwas depressiv ;).
Tk ist wahrscheinlich bei Python dabei, weils relativ klein ist. Ich finde auch, dass es am einfachsten zu bedienen ist. Es gab und gibt immer wieder die Diskussion wxPython statt Tk zu nehmen ...

BTW: Welche andere Programmiersprache hast Du Dir denn angesehen?
...
Bin auch etwas depresiv.
Ich will mehre Spielideen umsetzen, muß aber erst eine Sprache lernen.
So weit so gut. Geht eben nicht anders.
Aber dann gibt es so viele.
Und Python ... hat eben für meine Bedürfnisse leider paar Nachteile, was sich erst später rausstellte. Hm.. naja, aber nichts ist perfekt.
Hinzu kommt, in den Büchern wird zwar behandelt, wie man, naja, irgendwas macht, aber nicht wenn es um Grafiken geht. Anders ausgedrückt: Spieleentwicklerfeindlich.
Und nun muß ich hören, daß vieles geändert wird.
Und dafür habe ich mich jetzt 4-6 Wochen rumgeplagt?

Was ich mir angeschaut hatte, war PureBasic.
Das eine Turitoral war recht nett. Und es ging sofort daraum, ein Grafikspiel zu entwickeln, wenn auch ein ganz kleines Arcade-Spielchen.
Beim Zweiten ging es mehr wiederum um Übungen mit Grafik. Aber beim 3. Teil gab es eben Driverkonflikte. Durfte alles neu starten. :roll: Das wirkt alles andere als Vertrauenserweckend auf mich. Und ich dachte immer, sowas ähnmliches wäre C/C++ vorbehalten.
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
mawe
Python-Forum Veteran
Beiträge: 1209
Registriert: Montag 29. September 2003, 17:18
Wohnort: Purkersdorf (bei Wien [Austria])

Hi Erwin!

Spieleentwicklung ist wohl nicht die Hauptanwendung von Python ;) Wenn Du Dich aber umsiehst, es gibt dafür kaum etwas komfortableres als Pygame. Ich spreche leider nicht aus Erfahrung, ich hab mit Pygame noch nie etwas gemacht.
Erwin hat geschrieben: Und nun muß ich hören, daß vieles geändert wird.
Und dafür habe ich mich jetzt 4-6 Wochen rumgeplagt?
Alles was Du bis jetzt gelernt hast, wird für Dich in Zukunft nützlich sein. Die Änderungen die hier angesprochen werden betreffen ja eine Python-Version, die noch Jahre auf sich warten lassen kann. Du kannst also einfach Python so wie es jetzt ist weiterlernen und noch jahrelang damit programmieren :)

Gruß und gute Nacht, mawe
XT@ngel
User
Beiträge: 255
Registriert: Dienstag 6. August 2002, 14:36
Kontaktdaten:

Erwin hat geschrieben:Exe.Dateien lassen sich leichter verteilen.
Unkompiliertes wengier, weil dann auch der Interpreter mit muß. Weil es ist ja nicht sicher, ob Jeder den hat.
Wenn man also nur so vor sich hinprogrammieren will oder innerhalb einer Art geschlossenen Gemeinschaft, ist es nur noch wegen der Geschwindigkeit eine Exe-Datei von Interesse.
Aber wenn man seine Programme maximal unters Volk bringen will, dann geht dies eben nur mit Exe-Dateien.
Ist doch heute wirklich kein Problem mehr.
Siehe .Net/Mono, Java sowas kann ich mit nem installer mitliefern bzw. downloaden lassen.

Wenn Du Spiele unter Windows entwickeln willst (ernsthaft) kommst Du meiner Meinung nach an c/c++ und DirectX nicht vorbei.
Ich bekomm auch kein c++ programm hin wenn ich nicht meine beiden Bücher neben mir liegen habe.
Ich kanns einfach nicht so schnell runterschreiben wie PHP oder Python.
BlackJack hat geschrieben:versessen auf "Compiler" und/oder "EXE"n sind. Dann sollen sie doch bitte eine andere Sprache nehmen
Kann ich nur zustimmen, für jedes Problem die richtige Sprache. Wenn man ein bisschen mehr Erfahrung hat einfach mal einen Blick über den Tellerrand werfen und schaun mit welche Sprache man sein Problem am besten lösen kann.

Gute Nacht
Andreas
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ich finde nicht, dass man Grafikfunktionen einbauen sollte, denn diese gibt es ja in Modulen, und um ehrlich zu sein, nutze ich auch Tkinter nicht, also könnte man Tkinter auch ausgleidern. Zusammen mit so tollen Sachen wie lib-old..

Was die grafischen Sachen angeht ist pygame gar nicht mal schlecht, wenn es nicht grad an den beschränkungen der libSDL leidet. Aber dann hat man halt Workarounds, z.B. dass man ein Bild nicht zweimal rotiert, sondern immer das Ursprungsbild. An sich ist pygame jedoch nach etwas einarbeitung ziemlich einfach zu nutzen, schwer ist es dann halt die ganzen Tricks für Spieleprogrammierung zu finden.

Solche pygame-Ausrutscher sind zB:
Rechtsverschiebung, Verschiebung nach unten, Verwischung (kann man auch konstruktiv nutzen) oder eben auch diese rotation. Ich kann euch sagen, die Bildstörungen die ich mit pygame generiert habe waren schon ziemlich witzig :)

Statische Typen bringen uns einem Compiler nicht näher, denn sie sind nur Optional. Dann muss der Compiler so oder so dynamitsche Typen unterstützen. Aber es gibt ja auch für Lisp Compiler, Lisp ist eine Sprache mit dynamischen Typen, ist ja auch kein unlösbares Problem. Das liegt zum großen Teil daran, dass es keine große Priorität hat, einen Python Compiler zu schreiben.

Davon mal abgesehen haben EXEn und ELFs auch Nachteile, so brauchen die einen msvcrt und die anderen libc. Und bei mir ist (war) es oft so, dass libc zu alt ist, deswegen freue ich mich immer über Pakete, die nicht kompiliert sind.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Olliminatore
User
Beiträge: 55
Registriert: Montag 30. Mai 2005, 16:03
Wohnort: schönsten Stadt Deutschlands
Kontaktdaten:

Ich bin absolute dafür das ':' wegzulassen, nicht nur weil ich es häufig vergesse :?.
Das "Gegen" Argument für die Lesbarkeit in den Editoren , ist denke ich "nur" ein Problem der Editoren. :roll:

Und sonst finde ich auch die meissten Änderungen in PEP3000 sehr gut.
Es wird auch ein Schritt einsteigerfreundlicher, über die meissten hier angesprochenen Sachen bin ich als Anfänger in Python gestolpert.

Das ist erstmal alles was ich als "fast noch" Anfänger beisteuern kann.
[size=84][url=http://de.wikipedia.org/wiki/Jamba]Love Jamba[/url] <!--Olliminatore-->input<?/> [url=http://www.spreeblick.com/blog/index.php?p=324]Boycott Jamba[/url][code]def olliminiert(optimiert, eliminiert, terminiert):[/code][/size]
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Olliminatore hat geschrieben:Ich bin absolute dafür das ':' wegzulassen, nicht nur weil ich es häufig vergesse :?.
Das "Gegen" Argument für die Lesbarkeit in den Editoren , ist denke ich "nur" ein Problem der Editoren. :roll:
In Ruby ist das nicht und.. ich schreibe es dort dauernd hin, was mir einen SyntaxError einbringt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich hab noch einen...

Ich finde das .sort() ein bischen doof... Man kann es z.B. nicht so benutzen:

Code: Alles auswählen

keys = my_dict.keys().sort()
Es muß immer ein Zweizeiler sein:

Code: Alles auswählen

keys = my_dict.keys()
keys.sort()
Etwas verwirrend finde ich auch, das das zum None führt:

Code: Alles auswählen

keys = my_dict.keys()
keys = keys.sort()

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
joe

jens hat geschrieben:Ich finde das .sort() ein bischen doof...
Nimm sorted().
joe
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Das ist eine gute Idee... Nur sorted() gibt's erst in Python 2.4 :(
Somit fällt es bei mir für CGI Programmierung erstmal unterm Tisch (Python v2.2.1)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Guck mal auf NeuereVersionen, dort findest du unter "Die Builtins" auch einen Link zu Backposts einiger neuerer Python Builtins.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ne, auf dem V-Server ist Python 2.4 drauf, aber bei Hosteurope leider nur die alte Version :twisted:

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ach, jens, was hindert dich auf die Seite zu gehen, und den Link zu pflücken?

Na dann mach ichs, hier der Link. Dort siehst du, dass sum(), bool(), enumerate(), reversed(), sorted() und Sets implementiert werden. Und zwar so, dass du es auch aus python 2.2 verwenden kannst, du musst nur einen *-Import machen (wobei er mir hier eigentlich gerechtfertigt vorkommt).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

jens hat geschrieben:Ich hab noch einen...

Ich finde das .sort() ein bischen doof... Man kann es z.B. nicht so benutzen:

Code: Alles auswählen

keys = my_dict.keys().sort()
Der Entscheidungsgrund dafür war, das alle Methoden, die ein Objekt verändern, statt ein neues zurückzugeben, keinen Rückgabewert haben bzw. das implizite `None` eben.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Leonidas hat geschrieben:Ach, jens, was hindert dich auf die Seite zu gehen, und den Link zu pflücken?
Naja, weil ich an debian-backports dachte und nicht daran, das ein "nur" ein python-source-backport ist ;)

Das ist super cool - Danke!

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:Der Entscheidungsgrund dafür war, das alle Methoden, die ein Objekt verändern, statt ein neues zurückzugeben, keinen Rückgabewert haben bzw. das implizite `None` eben.
Das finde ich aber gar nicht so dumm, denn dann kann man sich immer sicher sein, dass es so ist.

Was ich noch geändert haben würde: die Modul importe so umbauen, dass beim Import des Modules das Modul auch wirklich wieder importiert wird, statt das Modul das noch vielleicht im Programm rumspukt wiederzuverwenden. reload(modulname) finde ich irgendwie nicht besonders..
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

Leonidas hat geschrieben:Was ich noch geändert haben würde: die Modul importe so umbauen, dass beim Import des Modules das Modul auch wirklich wieder importiert wird, statt das Modul das noch vielleicht im Programm rumspukt wiederzuverwenden. reload(modulname) finde ich irgendwie nicht besonders..
Wie soll das denn funktionieren? Wenn ich ein Modul in zwei anderen Modulen importieren, dann möchte ich gerne das gleiche Modul in beiden haben und nicht in beiden eine neu geladene Kopie.

In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:Wie soll das denn funktionieren? Wenn ich ein Modul in zwei anderen Modulen importieren, dann möchte ich gerne das gleiche Modul in beiden haben und nicht in beiden eine neu geladene Kopie.
Wieso? Wenn du in beiden Modulen Objekte erzeugst, sind es verschiedene Objekte, auch wenn alle Parameter beim erstellen gleich waren. Warum sollte das bei Modulen anders sein?
BlackJack hat geschrieben:In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.
Ich finds einfach unlogisch, dass man ein Modul nicht neu laden kann, wenn man import modul macht. Das ist besonders ärgerlich im interaktiven Modus, wenn man ein Modul testet und gleichzeitig schreibt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

BlackJack hat geschrieben:In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.
Bei meinem "Astronauten Thema" :wink: habe ich so eine Fragestellung. Und zwar geht es darum, wenn man zB. einen Server laufen hat und man einzelne Module verändert, erweitert, hinzufügt, wie man eben diese zur Laufzeit nachladen kann, ohne Neustart des Servers.

Tabellar
Antworten