Mailman 3 April 2016 - python-de

Python auf GRUB
by Christopher Arndt 14 Apr '16

14 Apr '16

Hallo alle, zufällig bin ich gestern auf diesen Talk von der PyCon 2015 gestoßen, wo jemand von Intel über die Portierung von Python auf BIOS + EFI + GRUB berichtet. Ich bin fasziniert, in wie viele ökologischen Nischen Python in letzter Zeit vordringt. Hier das Video des Talks: https://www.youtube.com/watch?v=bYQ_lq5dcvM Und hier eine ausführliche Zusammenfassung: http://lwn.net/Articles/641244/ Und schließlich die Webseite des Projekts: http://biosbits.org/ Hat das jemand schon mal ausprobiert? Gibt es irgendwelche Einplatinenrechner, auf denen das laufen würde (x86-Architektur ist wohl momentan Voraussetzung)? Gruß, Chris

1 0

Django Portierungstrategy???
by Marcel Hug (schaf) 13 Apr '16

13 Apr '16

HI All, Ich habe ein Django 1.5.1 projekt, welches mit Python 2.7 laeuft. Nun moechte ich das ganze auf die neusten Versionen bringen. Auf der Django Webseite wird empfohlen mit Python 3 zu arbeiten, aber meine Portierungserfahrung sagt mir, dass ich das besser in einem 2 Step Approach mache. 1. Schritt: Portierung auf Django 1.9.5 (e.g. mit neuster DB Version) 2. Schritt: Portierung auf Python 3. Da ich relativ neu bin in Python und Django wollte ich mich mal erkundigen, was ihr fuer Erfahrungen gemacht habt...? Danke fuer alle Tips. Gruess schaf

4 5

Re: [Python-de] Django Portierungstrategy???
by Marcel Hug (schaf) 13 Apr '16

13 Apr '16

Am Dienstag, 12. April 2016 18:28:01 UTC+2 schrieb Albrecht Mühlenschulte: > On 12 Apr 2016, at 17:08, Marcel Hug (schaf) wrote: > > Ich habe ein Django 1.5.1 projekt, welches mit Python 2.7 laeuft. Nun > > moechte ich das ganze auf die neusten Versionen bringen. Auf der > > Django Webseite wird empfohlen mit Python 3 zu arbeiten, aber meine > > Portierungserfahrung sagt mir, dass ich das besser in einem 2 Step > > Approach mache. > > > > 1. Schritt: Portierung auf Django 1.9.5 (e.g. mit neuster DB Version) > > 2. Schritt: Portierung auf Python 3. > > Gute Strategie - weiter wird immer empfohlen die Minor-Versionen (also > x.Y.z) durch zu steppen, weil die deprecation-Warnings recht hilfreich > sein können. > > Viele Grüße > Albrecht hi Albrecht, Hi Alle, zuerst mal vielen Dank fuer Eure Beitraege. Ich werde demnach nicht wie geplant von 1.5.1 direkt auf 1.9.5 gehen, sondern zuerst auf 1.6.11, dann 1.7.11., dann 1.8.12 und am Schluss auf 1.9.5 gehen. Vielen Dank fuer Eure Beitraege. Gruess schaf

1 0

Fwd: Re: Syntax-Erweiterung für Schleifen in Python3
by Achim Domma 11 Apr '16

11 Apr '16

On Saturday, 09 April, 2016 09:19 AM, Stefan Schwarzer wrote: > Ich habe darüber nachgedacht, aber mir ist kein besserer > Ansatz eingefallen wie in den schon geschriebenen Antworten. [...] > Fällt euch noch etwas ein? Ich würde gerne mal einen realen Anwendungsfall sehen. Zumindest ist das die Frage, die ich einem Kollegen stellen würde, der mit dem Problem auf mich zu kommt. Für mich "riecht" die Frage nach einem verstecken Workaround für ein anderes Problem. Meiner Ansicht nach unterwandert die Fragestellung etwas das abstrakte Konzept eines Iterators. Eine Iterator liefert "on demand" Werte und eine For-Schleife verarbeitet sie "stupide" einen nach dem anderen. Die "Buchhaltung" ob der Iterator je ein Ergebnis geliefert hat, interessiert normal nicht, wird her aber gewünscht. Meiner Ansicht nach ist die For-Schleife der falsche Platz. Ich würde das im Iterator lösen und hab' mal ganz auf die Schnelle folgendes zusammengehackt: class Wrapper(): def __init__(self, it): self.it = it self.called = False def __iter__(self): return self def __next__(self): nxt = self.it.__next__ result = nxt() self.__next__ = nxt self.called = True return result empty = Wrapper(iter([])) for x in empty: print(x) print(empty.called) not_empty = Wrapper(iter([1,2,3])) for x in not_empty: print(x) print(not_empty.called) Das kann man sicher noch schöner schreiben. Ich hatte auch überlegt, keine eigene Klasse zu verwenden, sondern einen Generator und die "called" property am original Iterator zu setzen. Beides hat Vor- und Nachteile. Meine Entscheidung würde wohl vom konkreten Problem und dessen Scope abhängen. Grüße, Achim

2 1

Re: [Python-de] Pip call with --allow-external and --allow-unverified leads to error for mysql-connector-python
by Marcel Hug (schaf) 11 Apr '16

11 Apr '16

Am Donnerstag, 7. April 2016 18:10:22 UTC+2 schrieb Christopher Arndt: > Am 07.04.2016 um 17:42 schrieb Marcel Hug (schaf): > > Das sollte eigentlich doch gehen, wenn ich das tar.gz direkt im requirements.txt angebe? Oder braucht es noch mehr? > > Also bei mir klappt folgendes: > > $ mkvirtualenv msqlc > (msqlc)$ echo > "https://cdn.mysql.com/Downloads/Connector-Python/mysql-connector-python-2.1…" > >requirements.txt > (msqlc)$ pip install -r requirements.txt > > > Chris Hi Chris, danke. Jetzt klappt es auch. Ich musste noch die Reihenfolge der Packete aendern und einige andere Anpassungen machen, aber jetzt hat es geklappt. Danke.

1 0

Re: [Python-de] Schleifen die ohne Durchlaufen des Schleifenkörpers beendet wurden
by Marco Bakera 10 Apr '16

10 Apr '16

Sven R. Kunze schrieb am 10.04.2016 um 14:09: >> Könnte man das nicht mit einer IF-Abfrage lösen? > > Sicher, wie viele Sprachfeatures. :) Das klingt nach Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Ich hoffe, wir haben bald nicht auch ein Monstrum wie das LOOP-Macro in Python. Beste Grüße, der Marco.

2 1

Re: [Python-de] Schleifen die ohne Durchlaufen des Schleifenkörpers beendet wurden
by Marco Bakera 10 Apr '16

10 Apr '16

Sven R. Kunze schrieb am 24.03.2016 um 20:53: > > neulich hatten wir wieder das Problem, dass wir gerne etwas in der > folgenden Art uns gewünscht hätten: > > for item in collection: > # do for item > empty: > # do when collection is empty Könnte man das nicht mit einer IF-Abfrage lösen? Warum muss es dafür eine spezielle Syntax geben? Beste Grüße, der Marco.

2 1

Syntax-Erweiterung für Schleifen in Python3
by Thomas Güttler 10 Apr '16

10 Apr '16

Hallo, der Thread "Schleifen die ohne Durchlaufen des Schleifenkörpers beendet wurden" war sehr interessant. Während dem Skifahren weit abseits von Laptop und Python viel mir etwas ähnliches ein, dass ich in dieser StackOverflow frage formuliert habe: http://stackoverflow.com/questions/36399808/loop-in-python-do-stuff-before-… {{{ I want to optimize. # Simple solution connection = get_db_connection() for item in my_iterator: push_item_to_db(item, connection) *Drawback:* `get_db_connection()` is slow. If `my_iterator` is empty, then I want to avoid to call it. # "if None" solution connection = None for item in my_iterator: if connection is None: connection = get_db_connection() push_item_to_db(item, connection) *Drawback:* If there are 100k items in `my_iterator`, then `if connection is None` gets called 100k times (although it is needed only once). I want to avoid this. # Perfect solution ... 1. don't call `get_db_connection()` if iterator is empty 1. don't call `if` uselessly for every iteration. Any idea? }}} Während es im Thread "Schleifen die ohne Durchlaufen des Schleifenkörpers beendet wurden" hauptsächlich darum ging wie man das mit dem aktuellen Python lösen kann, hier die Überlegung: Warum nicht die Syntax in Python3.x erweitern? Bei Schleifen fallen mir diese Anwendungsfälle ein: - on-empty - pre-first (siehe oben) - on-break (wie bisher "else") Gruß, Thomas -- http://www.thomas-guettler.de/

11 24

Re: [Python-de] "Snake" in Python programmieren
by Marco Bakera 09 Apr '16

09 Apr '16

Christopher Arndt schrieb am 09.04.2016 um 11:22: > > Bitte nicht auf diesen Troll eingehen, der immer mal wieder die ML mit > sinnlosen Provokationen heimsucht, eingehen. Ist leicht an den > Absendernamen zu erkennen. Danke für den Hinweis. Vielleicht findet trotzdem jemand die Erklärung hilfreich. ;) Beste Grüße, der Marco.

1 0

"Snake" in Python programmieren
by Armin Armerschlucker 09 Apr '16

09 Apr '16

Müsste doch einfach sein...

3 2