Krautkanal.com

Veröffentlicht am 2015-07-03 19:18:14 in /prog/

/prog/ 7328: Es ist wieder mal Zeit für einen Pythonfaden....

bassamology Avatar
bassamology:#7328

Es ist wieder mal Zeit für einen Pythonfaden.

donjain Avatar
donjain:#7329

Jemand positive Erfahrungen mit PyPy oder Cython gemacht?

leandrovaranda Avatar
leandrovaranda:#7337

>>7329
PyPy ist sehr schnell. Cython ist eher frickelig. Da kann man im Grunde auch gleich C nehmen.

seanwashington Avatar
seanwashington:#7339

Bernd, ich möchte nach Stille oder leisen Passagen in mp3/ogg/flac Dateien suchen. Mit welchen Modulen sollte ich mich einschmieren?

thierrymeier_ Avatar
thierrymeier_:#7344

Welches leichtgewichtiges Webframework?
Flask, CherryPy oder Bottle?

jasontdsn Avatar
jasontdsn:#7345

Mit was erstellt man denn User Interfaces für eine Konsolenanwendung? Curses ist anscheinend nicht wirklich gut dokumentiert. Irgendwelche Alternativen die Pythonexpertenbernd empfehlen kann?

antongenkin Avatar
antongenkin:#7346

>>7345
Neben Curses gibt es auch noch Urwid. Habe aber beides noch nicht benutzt.

stuartlcrawford Avatar
stuartlcrawford:#7347

>>7345
ncurses

mr_arcadio Avatar
mr_arcadio:#7349

>>7345
Wenn du die Muse hast dann kannst du auch eine Bindung für S-Lang schreiben. Wundert mich das dies noch niemand gemacht hat.

vladarbatov Avatar
vladarbatov:#7351

>>7337
PyPy behindert gerade die Python3 Migration.
Cython ist irgendwie veraltet als Ansatz, vor allem durch PyPy.
Für einfachen algorithmischen Pythoncode schnell zu machen unter CPython empfiehlt sich shedskin.
Für das Interface mit C ist cffi deutlich einfacher zu benutzen und funktioniert problemlos und schnell mit PyPy im Gegensatz zu Cython.

Generell: PyPy ist die Zukunft von Python. Vor allem mit so Späßen wie stm.

>>7344
Bottle ist theoretisch das leichtgewichtigste, wenn dir das wichtig ist.
Flask ist von der Benutzung aber genauso, nur deutlich besser erweiterbar und hat eine bessere Basis mit werkzeug.
Leichtgewichtig ist nicht unbedingt besser.

>>7345
Für alles, was irgendwie komplexer ist, wird es einfacher sein einen kleinen lokalen Webserver zu machen. Nur meine Meinung, Grenzfälle gibt es sicher, wo man eine reine Konsolenanwendung machen will.
Habe einmal urwid genutzt.

freddetastic Avatar
freddetastic:#7352

>>7349
Auch: Ich habe eben einmal über S-Lang geschaut. Kommt mit einer eigenen Skriptsprache. Ist vermutlich einfach aus Python den Interpreter aufzurufen und dann einfach über Umleitung von StdIO den Interpreter füttern. Ist sicher keine Ausgeburt an Geschwindigkeit, aber für einfache Programme dürfte es genügen.

Leider scheint S-Lang auch ohne fertige Widgets zu kommen.

buddhasource Avatar
buddhasource:#7353

>>7351
Bei Cython sehe ich vor allem den Vorteil, das man Python Code nach C konvertieren kann und damit direkt ausführbar macht.

Generell ist es eigentlich nicht so schwer Code zu schreiben der sowohl unter Python 2.7 als auch 3.x läuft. PyPy kann glaube ich mittlerweile auch Python 3. Kompatiblen Code zu schreiben lohnt trotzdem, denn dann hat man auch noch auf Jython zugriff. Was insbesondere wegen Android noch interessant werden kann.

lightory Avatar
lightory:#7354

>>7353
>Python Code nach C konvertieren kann
Das macht ja shedskin mit Python nach C++ und zwar zu 100% nicht wie Cython wo deinen Pythoncode ohne Cython spezifische Annotationen vielleicht nach C übersetzt aber ansonsten einfach deinen Code in Python intern ausführt.

Pypy3 kann im Moment nur 3.2 und ist deutlich langsamer als pypy2 dabei.
Da fehlt noch etwas Arbeit.

Und Python auf dem Schlaufon ist ein Thema für sich. Da schau mal lieber Kivy an, bevor man sich da auf Jython verlässt.

ayalacw Avatar
ayalacw:#7355

>>7354
Shedskin scheint alles andere als vollständig zu sein. Zum einen kann es nur Python 2.6, zum anderen fehlen schöne Dinge wie Unicode oder *args/**kwargs. Auch vermute ich das C++ den meisten Leuten die von Python her kommen ein Graus ist.

damenleeturks Avatar
damenleeturks:#7372

Da ich kürzlich mal ein bisschen mit Pythin rumprobiert habe eine konkrete Frage:
Methoden liefern ja oft den return type 'any' zurück. Wenn ich den Rückgabewert einer Variablen zuweise habe ich quasi eine 'any'-Variable.
Nun habe ich den Kniff gelernt zu sagen: 'assert isinstance xy' um mit der Variablen was anfangen zu können.

Ist das gebräuchlich und guter Stil oder eher eine Mogelei?

jjshaw14 Avatar
jjshaw14:#7373

>>7372
>Pythin

Python?

>return type 'any' zurück

Any gibts in Python nicht. Die einzige mir bekannte Sprache mit 'any'-Typ ist AWL.

>assert isinstance xy

wzf?
assert isinstance(xy, zz)
?

vj_demien Avatar
vj_demien:#7375

>>7372
Bernd schließt sich den Bedenken des Vorredners an und möchte hinzufügen, dass es in Python eigentlich recht üblich ist, keinen Wert auf den exakten Datentyp zu legen. Stattdessen gibt es für eine Vielzahl von Typen gleichnamige Methoden mit hinreichend ähnlicher Semantik, dass man sie auf Variablen anwendet, ohne sich irgendwie mit der Typisierung auseinanderzusetzen.

buleswapnil Avatar
buleswapnil:#7376

>>7375

Das ganze hat sogar einen Namen.
Ententypisierung Ducktyping nennt sich dies.

armcivor Avatar
armcivor:#7409

> >>> original = ['erstens', 'zweitens']
> >>> kopie = original
> >>> kopie.remove('zweitens')
> >>> original
> ['erstens']

Warum macht Python das, Bernd? Ich möchte doch nur die Kopie ändern und das Original so lassen wie es ist. Wie geht das?
t. Programmierneubiene drinvor offensichtlich

jajodia_saket Avatar
jajodia_saket:#7410

>>7409
>Warum macht Python das, Bernd?

Weil in Python alles eine Referenz ist. Das ist eines der Grundkonzepte von Python.

>>> a = [1,2]
>>> b = a[:]
>>> b.remove(1)
>>> a
[1, 2]
>>> b
[2]

BillSKenney Avatar
BillSKenney:#7412

>>7409
In Python gibt es keine Variablen, sondern nur Namen für Objekte.
Stell dir das so vor.
"=" ist kein Zuweisungsoperator, sondern einfach nur ein Namensgeber.
Python kopiert niemals implizit.

Das ist eines der besten Eigenschaften von Python.

kylefrost Avatar
kylefrost:#7414

>>7410
>>7412
Danke für die Erklärung.
Ich habe jetzt noch list() entdeckt und es damit gemacht:

> >>> a = ['eins', 'zwei']
> >>> b = list(a)
> >>> b.remove('zwei')
> >>> a
> ['eins', 'zwei']
> >>> b
> ['eins']

kennyadr Avatar
kennyadr:#7415

>>7412
>Das ist eines der besten Eigenschaften von Python.

Ja, wenn man es verstanden hat, ist es sehr angenehm. Es ist auch einer der Ursachen für die recht hohe Ausführungsgeschwindigkeit von Python (im Vergleich zu anderen Scriptsprachen). Es wird nicht ständig alles umkopiert, sondern in der Regel werden nur Referenzen umhergeschoben.

Das verwandte Prinzip von mutable- und immutable-Objekten sollte man auch verstanden haben. Nur wenn man beide Prinzipien kennt, versteht man was zum Beispiel bei
a = a + 1
genau passiert.

jehnglynn Avatar
jehnglynn:#7416

>>7415
>Es ist auch einer der Ursachen für die recht hohe Ausführungsgeschwindigkeit von Python (im Vergleich zu anderen Scriptsprachen).

Wut? CPython ist doch gerade so okayes Mittelfeld.

areus Avatar
areus:#7417

>>7416
Ersteinmal ist CPython nicht das schnellste Python und zweitens: Was ist denn wesentlich schneller? JS fällt mir nur ein. Und das ist auch nicht wesentlich schneller.
PyPy zerfickt alle.

smaczny Avatar
smaczny:#7418

>>7417
>PyPy zerfickt alle
Schneller sind lediglich:
LuaJIT
Rubinius
Interpreter, die auf Graal/Truffle basieren
HHVM
Racket

Und vermutlich noch viele weitere. Außer natürlich in Kirschgepflückten Benchmarks, wo PyPy schneller als C ist...

Und selbst wenn dem nicht so wäre -> PyPy unterstützt nichtmal Python 3 vollständig, damit kann mans im Grunde in die Tonne treten.

Was Bernd daran einfach stört, ist, dass es den Bastelprojektstatus nicht loswird. Es ist einfach brutal unterfinanziert, weil die wertlose Community sich mit dem Drecksack CPython zufrieden gibt, der aufgrund dieser Referenzensachen übrigens langsamer ist, wenn es um so vieles geht. Pointer sind scheiße, wenns nicht um ganz große Objekte geht.

Und viele Dinge sind einfach so unnötig langsam, obwohl es ja keinen Komfort kosten würde, siehe https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow

teylorfeliz Avatar
teylorfeliz:#7419

>>7418
>Und viele Dinge sind einfach so unnötig langsam, obwohl es ja keinen Komfort kosten würde, siehe https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow

List-comprehension, kennt er sie?
list(i * i for i in range(100))

Nur so ein Beispiel. Wenn du die list nicht wirklich brauchst, wird sie sogar gar nicht alloziiert.

Der Typ hat keine Ahnung von Python.

kimcool Avatar
kimcool:#7420

>>7419
Sein Beispiel ist wohl einfach nur schlecht. i² kann man natürlich über List Comphrehension lösen, aber genug andere Dinge nicht. Und für jene hat Python (Ruby aber z.B. schon) dann keine Methode, um eine Liste mit schon vorgegebener Kapazität zu initialisieren.

cbracco Avatar
cbracco:#7421

>>7419
>list(i * i for i in range(100))

Gerade dein Beispiel zeigt doch das Problem von dynamischen Sprachen, was auch in dieser verlinkten Präsentation angesprochen wird.

Was du hier zeigst ist keine list comprehension sondern ein Generatorausdruck.
list muss so lange lesen, bis der Generator aufgebraucht ist und weiß eben nicht dass er genau 100 Einträge haben wird und muss immer wieder Speicher sich nachbesorgen intern.
Es sollte also eine API geben, mit der man list sagen kann, dass es doch 100 Einträge haben wird als optionales Optimierungsargument z.B.: list((i * i for i in range(100)), 100)

Der PyPy JIT würde das ja sehr einfach erkennen und daraus direkt ein Array machen und es ist dann egal.

arashmanteghi Avatar
arashmanteghi:#7422

>>7419
Es geht darum, dass man Python nicht einfach ein Argument zum Vor-Alloziieren einer Listengröße mitgeben kann.

Der Typ hat Ahnung und Recht.

/Faden

aleclarsoniv Avatar
aleclarsoniv:#7423

>>7422
>Es geht darum, dass man Python nicht einfach ein Argument zum Vor-Alloziieren einer Listengröße mitgeben kann.

Ja. Das ist aber komplett irrelevant. Das macht Python nicht langsam.
Außerdem kann man so Sachen machen wie:

x = [None] * 1000000

Da braucht es keine zusätzliche API zu. Ja, es wird hier ein list "unnötig" alloziiert, was dann per multiplikator-operator aufgeblasen wird und es wird "unnötig" mit None-Referenzen initialisiert. Das geht aber im Rauschen unter. Und initialisieren will man es sowieso. Arrays mit undefiniertem Inhalt will man in so einer Sprache nicht. Da kann man ja gleich C nehmen.
Jeder JIT könnte dieses Konstrukt einfach erkennen und optimieren. (Integers sind immutable, deshalb ist es statisch optimierbar)

Ich bleibe dabei, der Typ hat keine Ahnung von Python und zeigt nicht-Probleme auf.

suribbles Avatar
suribbles:#7424

>>7421
>Was du hier zeigst ist keine list comprehension sondern ein Generatorausdruck.

Ja das ist mir schon klar. Und zwar mit gutem Grund habe ich das so gemacht und auch erklärt. Denn oft genug braucht man überhaupt keine Liste und kann direkt über Generatoren gehen.

mefahad Avatar
mefahad:#7435

>>7355
Shedskin hat keinen Monty Python Kanonnamen. Unvollständiger geht nicht.

sokaniwaal Avatar
sokaniwaal:#7436

>>7423
Die Frage ist, ob eine Sprache noch "beautiful" ist, wenn das Idiom zur Initialisierung von Listen "[None] * listsize" ist.

starburst1977 Avatar
starburst1977:#7437

>>7436
Jetzt auch noch beschweren das der Missbrauch einer verknüpften Liste nicht mehr schön aussieht. Wenn du ein Array haben möchtest dann nimm halt eins. Wenn ich mich nicht täusche kommt da was mit Numpy.

clementc Avatar
clementc:#7439

>>7436
>Die Frage ist, ob eine Sprache noch "beautiful" ist, wenn das Idiom zur Initialisierung von Listen "[None] * listsize" ist.

Die Frage beantworte ich dir gerne:
*trommelwirbel*
Ja

Auch: Nimm halt das Konstrukt, das zu deinem Problem passt, wie schon mehrfach gesagt.

irsouza Avatar
irsouza:#7445

Darf man hier auch tolle neue Module lüften? Bernd hat gerade VisPy durch dieses Video entdeckt:
https://www.youtube.com/watch?v=_3YoaeoiIFI
Schaut mal ab 11:45 wenn ihr Backsteine scheißen wollt :3

mbilderbach Avatar
mbilderbach:#7457

>>7445
Die Auswahl an Visualisierungsbibliotheken ist wirklich erdrückend. Auch: Danke, jetzt seh ich mir wieder tagelang Vorträge an.

jacobbennett Avatar
jacobbennett:#7459

Was hält Bernd eigentlich von Nuitka? Habe letztens angefangen, MC-Simulationen in Python zu schreiben, ob der Einfachheit, und die Geschwindigkeit ist verglichen mit C/C++ echt miserabel.
Nuitka verspricht ja Konvertierung zu C++-Code und Kompilierung, aber weißt du, wie schnell dies im Endeffekt ist?

zackeeler Avatar
zackeeler:#7465

>>7459
Bernd verspricht sich nicht viel von einem statischen Compiler für eine auf so vielen Ebenen dynamische Sprache wie Python. Schon gar nicht in diesem Entwicklungsstadium.

Aber teste er es ruhig.

joshuapekera Avatar
joshuapekera:#7475

Ich habe keine Ahnung von Python, wollte aber mal ein ein Projekt einarbeiten was Python verwendet. Scheitere schon ganz am Anfang. Das Dingen will installiert werden (bei einer interpretierten Sprache, wzt?) und bringt eine setup.py mit. Diese beschwert sich direkt mit

> [Errno 13] Permission denied: '/usr/local/lib/python3.4/dist-packages/test-easy-install-26773.pth'
tg


Ja natürlich nicht, das wäre ja auch noch schöner. Als lösung wird vorgeschlagen --install-dir, --prefix anzugeben. Gibt man diese An gibts die Beschwerde

> error: option --install-dir not recognized

In der Setup.py steht

>from setuptools import setup, find_packages


Ist das Normal? Mir erscheint Python bis jetzt voll-verzögert.

garethbjenkins Avatar
garethbjenkins:#7476

>>7475
Siehe https://docs.python.org/3/install/index.html#alternate-installation (besonders --home und die Hinweise dazu mit Blick auf PYTHONPATH).

Oder die Dokumentation von easy_install (welches --install-dir unterstützt), dann aber jenes auch benutzen.
>Das Dingen will installiert werden (bei einer interpretierten Sprache, wzt?)
Irgendwo müssen die Dateien ja hin.
>voll-verzögert
[Kommentare zur Grammatik.]

jjshaw14 Avatar
jjshaw14:#7479

Bernd, ich habe eine Menge relative Zeitpunke in Form "+mm:ss", wie überführe ich es in Unix Epoch mit einen wählbaren Bezugszeitpunkt?

Irgendwie bin ich von calendar, datetime und time ziemlich verwirrt.

ma_tiax Avatar
ma_tiax:#7481

>>7479
Bernd ist recht sicher, dass das jemand schon sauber implementiert und veröffentlicht hat, fand aber nichts exakt passendes. Jedenfalls ist die Geschichte mit Zeitangaben und -differenzen dank historischer Artefakte absolut immer irgendwie schwierig, deswegen der ganze Dokumentationswirrwarr.

Jedenfalls gibt es da nicht viel Hilfe, wenn man ein eigenes Stringformat einführt. Hierzu siehe https://de.wikipedia.org/wiki/ISO_8601#Zeitspannen und https://pypi.python.org/pypi/isodate

from datetime import datetime, timezone
from isodate import parse_duration

reference = datetime(1986,1,28, 16,38,00,0, timezone.utc)
offsets = map(parse_duration, map(lambda s: "PT" + s,
                ["0M", "2S", "36S", "58S", "1M00S", "1M04S", "1M08S", "1M12S",
                "1M12.525S", "1M13.124S", "1M13.162S", "110S"]))
for o in offsets:
    print(reference + o)

raquelwilson Avatar
raquelwilson:#7486

>>7479
https://pypi.python.org/pypi/sanetime

darcystonge Avatar
darcystonge:#7634

Bernd, was sollte ich rauchen um hinter Design Patterns durch zu steigen? Ich habe ein wenig das Internet gefragt, es ist nur spärliche und unvollständige Informationen da. Entweder Codebeispiele ohne Erklärung (https://github.com/faif/python-patterns) oder Blabla. Ich will schon eine allgemein verständliche Erklärung, auch mal für Pythonneulinge (so wie Head First Design Patterns für Java mal gewesen ist). In welchen Situationen bringen Design Patterns welchen Gewinn? Gerne auch als Screencast.

Neuste Fäden in diesem Brett: