expertenaustausch > comp.lang.* > comp.lang.python

Thomas Güttler (09.10.2017, 18:35)
Hallo,

seit einigen Monaten pflege ich meine programming guidelines, damit
ich mich selbst bessere daran halte :-)

Falls es jemanden interessiert:



Feedback ist willkommen.

Gruß,
Thomas
Hermann Riemann (10.10.2017, 09:07)
Am 09.10.2017 um 17:35 schrieb Thomas Güttler:

> seit einigen Monaten pflege ich meine programming guidelines, damit
> ich mich selbst bessere daran halte :-)


> Falls es jemanden interessiert:
>   


> Feedback ist willkommen.


2: Datenstrukturen.

struct in C ist effektiver als class in Python.
SQL etc ist im privaten Bereich bzw kleine Datenmengen
schlichtweg ineffektiv und für Programmierer unhandlich.

Datensätze speichere ich csv ähnlich ab.
Dadurch können strings "beliebig" lang sein.
( pickle wäre eine Alternative)

NULL behandele ich in Python über True False Indikatoren.

3: Dev
Chaos entsteht von alleine.
shells verwende ich in Python über os.system
wegen geringen Lernaufwands
und umgekehrt trickse ich mit symbolischen links
und bei Suche mit grep weder *~ Dateien (durch *emacs erzeugt)
noch *pyc zu durchsuchen.

Ich verwende C, wenn es besser geht,
oder Python zu langsam bist.
Beispiel Pixelmanipulation in 2560x1600 Fenster.

Threads und Async stehen bei mir durchaus auf der Wunschliste,
wenn das Problem dazu passt.
debuggen würde dann als Ausgabe in Dateien stattfinden.

Source code generation is a stupid idea:
Ich habe den C-Preprozessor für Python erwogen.
Das # passt gut dazu.
So #include #ifdef #define ..
Allerdings geht dann die Zeilenummerierung
bei Tippfehler verloren.

Und source code generation aus Daten
ist ein KI-Traum.

CSV
Ich mag von extern gelieferte CSV_dateien.
lines=open(irgendwas.csv).readlines()
for line in lines:
elems=line.rstrip().split(';')
..
Intern verende ich derartiges mit der Abweichung
dass ich Spalte 0 gerne für Steuerung verwende.

dos etc. verwende ich nicht.
Bestenfalls html-Dateien,
die ich über browser mittels durchklicken auffinden kann.

IDE:
Irgendein Editor ( meist emacs) und Kommandooberfläche.

...

Learn one programming language, not ten:

Python : universeller Schraubendreher.
C : Bohrmaschine
javascript: Spezialwerkeug für html Steiten
lisp : Automatik ( quote eval Mechanismus)

Andere Sprachen können notwendig bzw. interessant sein.

Für den Privatgebrauch sehe ich keine Notwendigkeit von git.
Eine Datensicherung Duplikate auf gleichem PC und auch USB-Platte
gelegentlich alte USB-Platten aufbewahren
für ein: es war einmal, reicht.
Viele Versionen führen zu viel Verwirrung.

...

Hermann
der schon lange programmiert,
früher mal meist C heutzutage meist Python 3
(3.4 SuSE "mag" leider kein 3.5)
Thomas Güttler (10.10.2017, 13:24)
Am 10.10.2017 um 08:07 schrieb Hermann Riemann:
> Am 09.10.2017 um 17:35 schrieb Thomas Güttler:
> Source code generation is a stupid idea:
> Ich habe den C-Preprozessor für Python erwogen.
> Das # passt gut dazu.
> So #include #ifdef #define ..
> Allerdings geht dann die Zeilenummerierung
> bei Tippfehler verloren.
> Und source code generation aus Daten
> ist ein KI-Traum.


Hallo Hermann und andere,

Ich bin mit dem aktuellen KI-Trend (Tensorflow) noch nicht sehr vertraut.

So weit ich weiß wird dort nicht Quelltext erzeugt.

Ich denke der Traum ist total sinnlos.

Warum sollte ich davon träumen, dass aus Daten Quelltext erzeugt wird? Was ist der Mehrwehrt?

Warum nicht ein generisches Programm verwendet, dass direkt auf den Daten arbeitet?

Warum der Umweg über Quelltexterzeugung? Bitte den Vorteil erläutern, denn ich sehe den nicht :-)

PS: Meine Zeilen klingen vielleicht etwas "harsch". So ist das nicht gemeint. Ich freue mich,
dass jemand konkrete Hinweise hat: Danke!

Gruß,
Thomas
Hermann Riemann (10.10.2017, 14:33)
Am 10.10.2017 um 12:24 schrieb Thomas Güttler:

>> Und source code generation aus Daten
>> ist ein KI-Traum.


> Ich bin mit dem aktuellen KI-Trend (Tensorflow) noch nicht sehr vertraut.


Tensorflow kenne ich praktisch nicht.
Dafür habe ich mal lisp verwendet.
Da gibt es etwas wie quote.
Damit kann man einer Variablen oder Listenelement
so etwas wie ein keywort zuweisen.

Außerdem gibt es da die polnische Notation,
was Unterprogrammen ähnlich ist.

Also statt a + b wird + a b.

Pythonähnlich wäre dann

x = [ quote(if), [ quote(<=), a, b ] [ quote(=) a b ]]

eval(x) würde dann if a<=b: a=b ausführen.

In Python müsste man erst Quelltext erzeugen
und, da eval nach meinem Eindruck auf eine Zeile
beschränkt ist, Dateien erzeugen und import anwenden.
Etwa so:

Datei: a.py
s="Mist"
if len(s)==4:
from b import *
else:
from c import *
print(s)

Datei: b.py
s="bla"

Datei: c.py

s="grr"

python3 a.py liefert dann
bla

Mit diesem Verfahren kann ein eval
über mehr als 1 Zeile nachgebastelt werden,
indem man erstellte Dateien bedingt nachträglich
importiert.
...

> Warum sollte ich davon träumen, dass aus Daten Quelltext erzeugt wird?


Eigentlich ist Quelltext nur eine Kommunikationsdarstellung
für Menschen.
computer intern sind andere Darstellungen eines Programms
besser geeignet.

> Was ist der Mehrwehrt?


> Warum nicht ein generisches Programm verwendet,
> dass direkt auf den Daten arbeitet?


Um aus Daten verwertbares Wissen zu machen,
benötigt es ein Programm, welches mit den Daten etwas anfangen kann.

Wenn aber die Verwertung der Daten erst noch
experimentell herausgefunden werden soll,
wird damit ein Programm gebastelt.

Das muss nicht ein Mensch machen,
womit ki ..

Hermann
der den quote eval Mechanismus aus lisp in Python vermisst.
Peter Otten (10.10.2017, 14:48)
Hermann Riemann wrote:

[snip coding horror]

> Mit diesem Verfahren kann ein eval
> über mehr als 1 Zeile nachgebastelt werden,
> indem man erstellte Dateien bedingt nachträglich
> importiert.


So, liebe Kinder, dass passiert wenn die Seite mit exec vom Hund gefressen
wurde.

Also, passt gut auf euren Fiffi auf ;)
Bernd Nawothnig (10.10.2017, 22:57)
On 2017-10-10, Peter Otten wrote:
> Hermann Riemann wrote:
> [snip coding horror]
> So, liebe Kinder, dass passiert wenn die Seite mit exec vom Hund
> gefressen wurde.
> Also, passt gut auf euren Fiffi auf ;)


Nun füttere die Trolle doch nicht noch. Wenn sie wenigstens
unterhaltsam wären, meinetwegen, aber nicht für so einen Schrunz.

Bernd
Hermann Riemann (11.10.2017, 07:12)
Am 10.10.2017 um 13:48 schrieb Peter Otten:

>> Mit diesem Verfahren kann ein eval
>> über mehr als 1 Zeile nachgebastelt werden,
>> indem man erstellte Dateien bedingt nachträglich
>> importiert.


> So, liebe Kinder, dass passiert wenn die Seite mit exec vom Hund gefressen
> wurde.



mag die bessere Alternative zu bedingten imports zu sein.

Bedingte imports mag für Testzwecke und Erweiterungen
nützlich sein.

Hermann
der wenigstens wieder etwas Praktisches gelernt hat.
Thomas Güttler (11.10.2017, 12:46)
Am 10.10.2017 um 13:33 schrieb Hermann Riemann:
> Hermann
> der den quote eval Mechanismus aus lisp in Python vermisst.


Ich vermisse nichts.

Ich habe Python, Linux, PostgreSQL, Django-ORM und einen wunderschönen bunten Herbst :-)

Hermann: Warum vermisst du "eval"?
Hermann Riemann (11.10.2017, 15:14)
Am 11.10.2017 um 11:46 schrieb Thomas Güttler:

> Ich habe Python, Linux, PostgreSQL, Django-ORM und einen wunderschönen
> bunten Herbst :-)


Python (leider nur Python 3.4) und Linux (SuSE 42)
habe ich auch.

Mich würde schon interessieren,
welche Linux Distributionen keine Probleme mit
Python > 3.4 haben.

Datenbanken verwende ich nicht.

Wenn ich excel erhalte, exportiere ich sie nach html
und bearbeite diese html-Dateien mit import html ..

*.csv Dateien wird mit Linux nach utf-8 konvertiert
und dann ohne csv-Modul bearbeitet.

Bei *.mbox bin ich mit Python aufgeschmissen
weile sie sowohl so als auch utf-Zeichen enthalten.
( könnte ich ich noch mittels Zerlegung überwinden.)
Allerdings die decodierung danach ..

Welchen Editor verwendest Du für Python?
( Ich nehme meist emacs, gelegentlich kate,
bei kleinen Korrekturen
oder zum Anschauen (wegen sicherem q:!) auch vi)

> Hermann: Warum vermisst du "eval"?


Ich vermisse das eval, so wie es in lisp ist.
Ein eval auf Listen bei denen auch keyword ähnlich
wie Unterprogrammnamen vorkommen.

Bei Python müsste ich dies derzeit in einen string umwandeln,
der Vergleichbar ist wie die letzte Zeile in

und dann exec verwenden.

Wie weit PyPy
in der Richtung geht,
weiß ich nicht.

Hermann
der früher mal mit lisp symbolisch gerechnet hat
und dies mit Python fortsetzen möchte.
Thomas Jollans (11.10.2017, 15:35)
On 2017-10-11 14:14, Hermann Riemann wrote:
> Am 11.10.2017 um 11:46 schrieb Thomas Güttler:
> Python (leider nur Python 3.4) und Linux (SuSE 42)
> habe ich auch.
> Mich würde schon interessieren,
> welche Linux Distributionen keine Probleme mit
> Python > 3.4 haben.


Warum Probleme? Habe ich was verpasst? Python 3.5-3.6 funktionieren super.

* Debian stable hat 3.5.
* Ubuntu 16.04 LTS hat 3.5, Ubuntu 17.10 hat 3.6.
* Arch/openSUSE-Tumbleweed und Konsorten haben sowieso das allerneueste.
* RHEL/CentOS/Scientific 7.x haben standardmäßig leider kein Python 3,
aber "Software Collections" mit verschiedenen Python-3-Versionen, auch
Python 3.6.

Wobei auf einer Distri ohne aktuelles Python unter Umständen Anaconda
die beste Lösung ist.

> Datenbanken verwende ich nicht.
> Wenn ich excel erhalte, exportiere ich sie nach html
> und bearbeite diese html-Dateien mit import html ..
> *.csv Dateien wird mit Linux nach utf-8 konvertiert
> und dann ohne csv-Modul bearbeitet.


pandas, pandas, pandas.

> Bei *.mbox bin ich mit Python aufgeschmissen
> weile sie sowohl so als auch utf-Zeichen enthalten.
> ( könnte ich ich noch mittels Zerlegung überwinden.)
> Allerdings die decodierung danach ..


Echt? Die stdlib kann das nicht?

(Selber keine Erfahrung mit)
Peter J. Holzer (12.10.2017, 00:25)
On 2017-10-11 12:14, Hermann Riemann <nospam.ng> wrote:
> Mich würde schon interessieren,
> welche Linux Distributionen keine Probleme mit
> Python > 3.4 haben.


Was meinst Du mit "Probleme haben"? Debian stable hat Python 3.5 (Debian
ist nicht dafür bekannt, stets die neueste Software zu haben), und ich
könnte sicher problemlos Python 3.6 oder 3.7 (alpha) installieren.

> *.csv Dateien wird mit Linux nach utf-8 konvertiert und dann ohne
> csv-Modul bearbeitet.


Warum ohne csv-Modul?

> Bei *.mbox bin ich mit Python aufgeschmissen weile sie sowohl so als
> auch utf-Zeichen enthalten. ( könnte ich ich noch mittels Zerlegung
> überwinden.) Allerdings die decodierung danach ..


Dafür gibt es das email Package.

> Welchen Editor verwendest Du für Python?


vim.

hp
Hermann Riemann (12.10.2017, 12:55)
Am 11.10.2017 um 23:25 schrieb Peter J. Holzer:
> On 2017-10-11 12:14, Hermann Riemann <nospam.ng> wrote:
> Was meinst Du mit "Probleme haben"? Debian stable hat Python 3.5 (Debian
> ist nicht dafür bekannt, stets die neueste Software zu haben), und ich
> könnte sicher problemlos Python 3.6 oder 3.7 (alpha) installieren.


Auf alle aktuellen Rechner mit intel oder AMD Prozessor
verwende ich SuSE 42.2 bzw. SuSE 42.3
und da wird nur Python 3.4 angeboten.
Python 3.5 Auswahl führt zu Warnungen von Inkompatibilitäten.

>> *.csv Dateien wird mit Linux nach utf-8 konvertiert und dann ohne
>> csv-Modul bearbeitet.


> Warum ohne csv-Modul?


Bei mir sieht es prinzipiell so aus:

aktionen=[]
f=open("iurgendwas.csv")
for line in f:
liste=line.rstrip().split(';')
if len(liste)<zu_kurz: continue
dict={}
aktionen.append(dict)
dict["euro"]=liste[6]
..

# Auswertung von Aktionen
...

Was soll da mit dem csv-Modul besser gehen?

>> Bei *.mbox bin ich mit Python aufgeschmissen weile sie sowohl so als
>> auch utf-Zeichen enthalten. ( könnte ich ich noch mittels Zerlegung
>> überwinden.) Allerdings die decodierung danach ..


> Dafür gibt es das email Package.


Wird bei SuSE 42 nicht angeboten.

>> Welchen Editor verwendest Du für Python?


> vim.


Ich habe gvim probiert.
gvim hat bei KDE den Nachteil,
das nach reboot ein leeres Fenster angezeigt wird.
Außerdem verschandelt gvim die Konsole mit vielen Zeilen mit
invalid source position for vertical gradient

Hermann
der für Programmentwicklung gerne 3 Monitore verwendet
Mitte Editor, rechts Konsole für ./irgendwas.py
links browser für Dokumentation cgi, Daten ..
Thomas Güttler (12.10.2017, 13:49)
Am 11.10.2017 um 14:14 schrieb Hermann Riemann:
> Datenbanken verwende ich nicht.


Schade. Warum nicht?
Massa, Harald Armin (12.10.2017, 14:13)
> Am 11.10.2017 um 14:14 schrieb Hermann Riemann:
>> Datenbanken verwende ich nicht.

> Schade. Warum nicht?
> Datenbanken, grade relationale, erfordern extra Arbeit, um die DSGVO

umzusetzen.
Wenn man die Daten irgendwie "speichert", sind die nahezu so gut wie
gelöscht, und damit
sind die Löschanforderungen der DSGVO fast schon mit umgesetzt.

Gruß Harald
Hermann Riemann (12.10.2017, 17:07)
Am 12.10.2017 um 12:49 schrieb Thomas Güttler:

>> Datenbanken verwende ich nicht.


> Schade. Warum nicht?


Ich habe mal etwas mit SQL experimentiert.
Ergebnisse:
- benutzen konnte ich das nur unter /root
- sehr viele lesbare Dateien wurden angelegt
- string Länge durch Angaben begrenzt.

Da finde ich es besser,
meine Daten in selber angegeben Formate zu speichern.
Bei der benutzen Menge ist das im Millisekunden Bereich.
Und als alleiniger Benutzer kann ich Konflikte
überblicken.

Verschlüsseln kann ich auch selber
und malware tut sich schwerer Daten zu finden.

Momentan erwäge ich Daten mittels
pickle zu speichern und zu laden,
was die Handhabung vereinfachen sollte,
sofern nicht pickle das Format ändert.

Wenn ich über cgi Daten schreiben will,
muss ich die Dateien mit chmod 666
allgemein schreibbar machen.

Hermann
der keine Zeit für Datenbankenprogrammierung
opfern mag.

Ähnliche Themen