pickle gibt convert error von string to float

[birkenfeld]

Wieso nicht?

Ich versuche die Sachen die als schlecht in Python angesehen werden, zu vermeiden. Erstmal weil ich schönen Code schreiben will den auch andere schön und brauchbar finden. Zweitens kann es ja mal sein das ich mich einem Projekt anschließe und dann sollte man sich ja schon größtenteils an PEP8 halten und Sachen vermeiden die nicht als gut angesehen werden.

Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.

Außerdem wenn es ehe in Py3K wegkommt, benutze ich das dann lieber ehe nicht, da ich in diesen Fall darauf auch verzichten kann und beim umstieg weniger umschreiben muss. -- Aber eine Begründung wollte ich dennoch vorher gerne gehaben, die ich nun habe.

Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen (wenn man es nicht für den eigentlichen Einsatzzweck den bitshifting nutzt)?

Was hat der Bitshifting-Operator mit der speziellen Syntax von print zur Ausgabe an beliebige Streams zu tun?

[sape]

Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.

Naja das was BlackJack ja schon gesagt hat. Finde ich irgendwie logisch die Begründung von ihm.

Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.

Welches Konvertierungstool?

Was hat der Bitshifting-Operator mit der speziellen Syntax von print zur Ausgabe an beliebige Streams zu tun?

Nichts hat das damit zu tun und habe ich ja auch nicht gesagt. Aber es sieht gleich aus und kann dann zur Verwirrung führen, weil es zwei Sonderfälle für ein Operator gibt der in zwei fällen unterschiedliche Bedeutung hat. Naja, mich persönlich stört es in dem Fall von >> ehe nicht, da ich kaum Code sehe wo das verwendet wird.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen? Das würde mich ja dann doch interessieren.

lg

[birkenfeld]

Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.

Naja das was BlackJack ja schon gesagt hat. Finde ich irgendwie logisch die Begründung von ihm.

Also dass es ein Speziallfall ist, den man sich merken muss?
Ehrlich gesagt, man kann gar nicht darauf kommen, dass >> in "print >>a" ein Bitshifting-Operator ist, denn letzterer ist ein binärer Operator, während das hier höchstens ein unärer sein kann. (Ist er aber nicht, es ist *kein* Operator, sondern ein Syntaxelement. Und als solches auch nicht schwerer zu merken als z.B. die Bedeutung von ":" in Slices.)

Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.

Welches Konvertierungstool?

Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen? Das würde mich ja dann doch interessieren.

`print >>a, b, c, d` sieht schöner aus als `a.write("%s %s %s\n" % (b, c, d))`.

Und gerade wenn man einem Programm, was ursprünglich nur print verwendet, die Ausgabe in beliebige Streams beibringen will, sehr viel schöner umzuschreiben.

[sape]

Interessant. Erstens habe ich den ersten Abschnitt von dir nicht gewusst und das Beispiel von dir ist überzeugend. Danke dir für die Klarstellung.

Dan hätte ich aber noch einer Frage: Warum wird das dann abgeschaft? (Die alte Begründung kann ja dann nicht zutreffen.). Wird stattdessen ein anderes Zeichen gewählt das die gleiche Aufgabe übernimmt?

lg

[Leonidas]

Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.

Welches Konvertierungstool?

Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.

Wie siehts damit eigentlich aus? Was mich aber etwas an der ganzen Geschichte wundert, dass zum Beispiel die Twisted-Leute scheinbar vorhaben bei Python 2.x zu bleiben, zumindest vorerst.

[sape]

Würde ich auch gerne Wissen.

[birkenfeld]

Dan hätte ich aber noch einer Frage: Warum wird das dann abgeschaft? (Die alte Begründung kann ja dann nicht zutreffen.). Wird stattdessen ein anderes Zeichen gewählt das die gleiche Aufgabe übernimmt?

Da print eine Funktion wird, wird es ein Keyword-Argument geben.

Bzw. das Futur ist unzutreffend

Code: Alles auswählen

Python 3.0x (p3yk:53421, Jan 31 2007, 08:41:24)
[GCC 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> Print("a", "b", file=sys.stderr)
a b

Wobei momentan "print" als Statement noch vorhanden ist und die Funktion deswegen großgeschrieben ist.

[birkenfeld]

Welches Konvertierungstool?

Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.

Wie siehts damit eigentlich aus?

Naja, es existiert und kann schon einige Änderungen, z.B. print oder die neue except-Syntax.
Wo es natürlich schwierig wird, das sind Sachen wie dict.iterkeys()/keys(), weil man da nicht eindeutig sagen kann, ob z.B. "x.keys()" geändert werden muss.

Was mich aber etwas an der ganzen Geschichte wundert, dass zum Beispiel die Twisted-Leute scheinbar vorhaben bei Python 2.x zu bleiben, zumindest vorerst.

Nachdem die Konvertierung nie 100% Zuverlässigkeit erreichen kann, haben die etwas Angst vor der Riesenarbeit, den ganzen Code vollständig zu portieren. Kein Wunder bei der Codebasis...

ein Grund mehr für gescheite Unit Tests (was nicht heißt, dass Twisted keine hat).

[Leonidas]

Ist es wirklich eine schlaue Idee, das Keyword-Argument wie ein Builtin zu benennen? Funktional ist es ja eigentlich egal, aber so etwas bin ich normalerweise nicht von Python gewöhnt. Oder wird ``file()`` nun abgeschafft?

[birkenfeld]

Ist es wirklich eine schlaue Idee, das Keyword-Argument wie ein Builtin zu benennen? Funktional ist es ja eigentlich egal, aber so etwas bin ich normalerweise nicht von Python gewöhnt. Oder wird ``file()`` nun abgeschafft?

Nein, das nicht. Aber warum sollte das Keyword nicht so heißen?

[Leonidas]

Nein, das nicht. Aber warum sollte das Keyword nicht so heißen?

Die gängige "Lehrmeinung" ist ja, dass man keine Namen nehmen sollte, die Builtins überdecken. In dieser Form, würde aber in der Funktion Print der Name file überdeckt. Ok - da diese Funktion höchstwarscheinlich in C implementiert ist, ist es an dieser Stelle von der Funktionalität egal, aber sollte man nicht besser ein gutes Beispiel geben?

Nicht dass dann jemand sowas in seinem Code auch macht und meint: "die Builtins machen es doch auch so!" Andererseits würde der Name ``target`` warscheinlich besser passen, ist auch nicht wesentlich länger zu tippen und ebenso leicht zu merken. Noch dazu ist er etwas neutraler, d.h. er suggeriert nicht, dass da zwingend ein file-Objekt (im Sinne von Instanz von file) hingeschickt werden muss.

[sape]

@Birkenfeld:
Naja, man soll doch keine Namen vom builtins verwenden. Oder ist das bei Keywords zulässig? Ich glaube mich zu erinnern das im PEP8 drinstande das man dann lieber ein _ am ende setzen soll im Zweifelsfall wenn kein besserer Name einfällt (Ich glaube das galt auch für Keywords).

[birkenfeld]

@Birkenfeld:
Naja, man soll doch keine Namen vom builtins verwenden. Oder ist das bei Keywords zulässig? Ich glaube mich zu erinnern das im PEP8 drinstande das man dann lieber ein _ am ende setzen soll im Zweifelsfall wenn kein besserer Name einfällt (Ich glaube das galt auch für Keywords).

Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.

Zweitens, bei Keywords *musst* du den Namen verändern, weil die nicht als kwargs zulässig sind.

[Leonidas]

Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.

Ja, das habe ich ach schon geschrieben. Aber wie sieht das mit der Konsistenz aus. Warum wird nun mit zweierlei Maß gemessen, dass die Builtins etwas dürfen was der normale Programmierer in seinem Code unterlassen sollte.

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, aber das gilt ja nur für CPython, für IronPython oder PyPy muss das gar nicht mehr gelten. Sonst verhalten sich die in C geschriebenen Funktionen ja eigentlich genauso wie in Python geschriebene Funktionen, d.h. es gibt im "Look and Feel" keinen Unterschied.

[birkenfeld]

Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.

Ja, das habe ich ach schon geschrieben. Aber wie sieht das mit der Konsistenz aus. Warum wird nun mit zweierlei Maß gemessen, dass die Builtins etwas dürfen was der normale Programmierer in seinem Code unterlassen sollte.

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, aber das gilt ja nur für CPython, für IronPython oder PyPy muss das gar nicht mehr gelten. Sonst verhalten sich die in C geschriebenen Funktionen ja eigentlich genauso wie in Python geschriebene Funktionen, d.h. es gibt im "Look and Feel" keinen Unterschied.

"A foolish consistency..."

Die Richtlinie ist nicht dazu da, stur einfach so eingehalten zu werden, sondern dazu um dem Programmierer das Leben leicht zu machen.

Wenn du die Funktion nicht schreibst, braucht es dich nicht zu kümmern, ob der Programmierer derselben sich (evtl.) das Leben schwer gemacht hat -- sofern du dir sicher bist dass er alles richtig gemacht hat.

[Leonidas]

"A foolish consistency..."

Das ist mir schon klar, aber ich finde dass target eine brauchbare Alternative ist. Wie dem auch sei, egal..

Eigentlich sollte dieser Thread auch schon laengst abgesplittet worden sein

[birkenfeld]

Ich glaube es war auch "stream" im Gespräch.

Nur ist auf python-3000 keiner auf die Idee gekommen, an "file" könnte aus diesem Grund etwas falsch sein...

[sape]

Auch wenns nicht jeden schmeckt, aber ich finde es blöd das die bultins sich da hinwegsetzen dürfen. Ich sehe das auch so wie Leonidas:

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, [...]

Wobei die Begründung das es in C implementiert ist und die es deswegen dürfen keine wirkliche für mich ist und nur fadenscheinig Rechtfertigung.
...

Und vor ca. 1 Stunden war gerade das Thema in einem Thread mit dem überschrieben der builtins. Und nun wie soll man dann noch wirklich argumentieren könne? Die dürfen das und DU nicht ist ein wenig...naja ich sags mal höflich, dualistisch? Finde ich ehrlich gesagt nicht OK und auch inkonsistent.

Ist meine ehrliche Meinung.

Birkenfeld, könntest du das Thema nicht mal ansprechen? So wie ich mitgekriegt habe bist du ja auch ein wenig mit beteiligt bei Python. Könnte schwören das ich PEPs von dir gelesen habe

lg

[birkenfeld]

Auch wenns nicht jeden schmeckt, aber ich finde es blöd das die bultins sich da hinwegsetzen dürfen. Ich sehe das auch so wie Leonidas:

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, [...]

Wobei die Begründung das es in C implementiert ist und die es deswegen dürfen keine wirkliche für mich ist und nur fadenscheinig Rechtfertigung.
...

"Dürfen" ist nicht der Punkt. Hier geht es nicht um Gesetze, die gebrochen werden können, sondern um Empfehlungen, mit denen sich der Programmierer das Leben leichter macht. In diesem Fall ist das weder für denjenigen, der print() implementiert, noch den, der es benutzt, relevant.

Und vor ca. 1 Stunden war gerade das Thema in einem Thread mit dem überschrieben der builtins. Und nun wie soll man dann noch wirklich argumentieren könne?

Das hab ich oben schon vorgeführt.

Die dürfen das und DU nicht ist ein wenig...naja ich sags mal höflich, dualistisch? Finde ich ehrlich gesagt nicht OK und auch inkonsistent.

Ich weiß nicht genau, was ich davon halten soll. Du kommst mir ehrlich gesagt etwas zwanghaft vor.

Nochmal: Das sind keine Gesetze, nicht mal Syntax oder zwingend vorgeschriebene Regeln. Du hältst dich krampfhaft an etwas fest, was es in der Form nicht gibt.

Birkenfeld, könntest du das Thema nicht mal ansprechen? So wie ich mitgekriegt habe bist du ja auch ein wenig mit beteiligt bei Python. Könnte schwören das ich PEPs von dir gelesen habe

Brav Aber nein, ich werde das Thema nicht ansprechen, zum einen weil es mich überhaupt nicht stört. Zum anderen treiben sich dort recht intelligente Menschen herum, und ich kann mir nicht vorstellen dass es keinem von denen in den Sinn gekommen ist dass "file" der Name eines Builtins ist.

[sape]

Das hab ich oben schon vorgeführt.

Nochmal: Das sind keine Gesetze, nicht mal Syntax oder zwingend vorgeschriebene Regeln. Du hältst dich krampfhaft an etwas fest, was es in der Form nicht gibt.

Ok, dann werde ich mir das dann mal verinnerlichen.


Danke für die Infos.

lg

EDIT: Ups habs genau andersherum verstanden. Sry.