Seite 1 von 3

Verfasst: Sonntag 8. Dezember 2002, 17:58
von RicmanX
Wir bräuchten das halt Scriptfähig! Egal ob Linux oder Win, Console nützt da nichts... :shock: :)

Verfasst: Sonntag 8. Dezember 2002, 22:20
von Beyond
Ich verstehe Deine Antwort nicht :?:

- Was zeichnet ein scriptfähiges Modul aus?
- Warum darf die Demo (bzw. schlicht der Funktionstest) von dem Modul nicht in einer Console laufen?
- Wie sollte Deiner Meinung nach eine Demo für ein solches Modul aussehen?

cu beyond

Verfasst: Montag 9. Dezember 2002, 06:00
von RicmanX
Naja, ich persönlich bevorzuge ne Demo mit bspw. IDLE oder in HTML Umgebung.
Jedenfalls möcht ich nur wissen, wie ich per Script die Informationen abfrage, also das sie nicht in ner Konsole erscheinen, sondern sowas we n return Wert sind. Also was müsste man dazu in dieser Demodatei ändern?

Verfasst: Montag 9. Dezember 2002, 20:23
von Beyond
HTML-Umgebung :?: Verwendest Pylets mit Grail oder erwartest Du Dir einen http-Demo-Server?
Ich kenne kein Python-Modul das soetwas macht (abgesehen von Medusa :) ...)

Aber schau doch einfach mal in die Demo-Datei rein. Dafür sollte eine Demo nämlich eigentlich gut sein.

Dort gibt es folgende Zeile

Code: Alles auswählen

data,info = _contentinfo.getContentinfo(file, hard=1, relaxed=0, returnData=1)
Das ist doch ein schöner return-Wert. data enthält den Inhalt der Datei, wenn returnData=1 ist und info enthält die Informationen. Das und der Rest sollte eigentlich selbsterklärend sein.

Code: Alles auswählen

info[2]
ist schließlich noch ein Dictionary mit weiteren Werten z.B. gibt es da (sofern die Werte ermittelt werden können, das ist ja nicht immer gegeben z.B. haben Audiodateien keine Breite und Höhe)

Code: Alles auswählen

info[2]['width']

Code: Alles auswählen

info[2]['height']
cu beyond

PS: Eine passend abgeänderte Demo-Datei interessiert mich jetzt schon.

Verfasst: Montag 9. Dezember 2002, 22:11
von RicmanX
So, nach 20-30min Arbeit und über den Umweg einer Ausgabe in IDLE ;):

http://www.pythonarea.net/module/contentinfo/

Nachtrag von Milan: hab das edidiert, weil ich das Verzeichnis mal verschoben habe...

Verfasst: Mittwoch 11. Dezember 2002, 14:05
von RicmanX
@Beyond: es wäre schön wenn du das Script weiterentwickeln würdest! :)

Ich habe bemerkt, das der die ...__image__jpeg.py usw. zwar importiert, aber nicht benutzt? Jedenfalls wären auch weitere Mimetypes noch gut. Und er sollte auch die Extension der Datei (Am Bsp. Python.jpg) anstatt ".jpeg" zurückgeben.

Ansonsten echt Klasse gemacht und super nützlich! 8)

Verfasst: Mittwoch 11. Dezember 2002, 23:47
von Beyond
Danke. :D

Ich werde mich mal am Wochenende daran machen etwas weiter zu coden.

Ich habe z.Z. nur ziemlich viel zu tun. Das Physikstudium an der TUM ist kein Kinderspiel und dann habe ich noch so einige andere Verpflichtungen ...

Über Mithilfe beim Programmieren für dieses Modul wäre ich sehr dankbar. Vorallem beim Implementieren von Mime-Types sollte sich die Arbeit auch gut aufteilen lassen.

U.U. werde ich auch am Wochenende ein neues Konzept für content_info einführen: Ich will das dictionary, daß jetzt ja irgendwelche Daten enthält durch ein spezielles Objekt ersetzen, daß für jeden Mime-Type spezifisch ist, aber eben allgemeine Parents hat (mittels Multiple Inheritance) z.B. können das gif- und das jpeg-Objekt beide von einem Picture-Objekt abgeleitet werden. Ist etwas eines Instanz eine Picture-Objekts hat es z.B. Höhe und Breite.

Außerdem möchte ich die Lizenz ändern z.B. LGPL oder BSD.

Vorschläge?

cu beyond

Verfasst: Samstag 14. Dezember 2002, 21:11
von Beyond
(Ich war vorhin wieder mal ausgeloggt worden :?: )

So jetzt ist die neue Version fertig. Die gibt's wieder unter
http://www.zope.org/Members/beyond/contentinfo
Es wäre echt toll, wenn Ihr Module z.B. für mp3, mpeg, avi, ... programmieren könntet. Ich kann gerne auch dabei mithelfen.
Für .ogg habe ich schon einen Java-Code gefunden. Er ist aber GPL und ich hätte gerne LGPL, daher habe ich den Autor angeschrieben ...

Übrigens: die extension für JPEG ist wirklich .jpeg.

Verfasst: Samstag 14. Dezember 2002, 21:24
von RicmanX
Das mit der Extension mein ich so, wie die Datei halt heißt. Weil im _contentinfo wird das auch ausgelesen, nur je nach Header entsprechend ausgegeben. Ich denk halt an ne "echte" Extension, sprich wie im Dateinamen. Meinetwegen auch 2 Werte, falls sich beides unterscheidet.

Zu allererst könnt ich dir die Infos für Endung/Mimetyp von mehreren Dateiarten schicken.
Gib mal Mailadresse :)

Verfasst: Samstag 14. Dezember 2002, 21:28
von Milan
ich hab mal zwecks lesbarkeit die beiden doppelten Posts gelöscht. Ich denk mal, daa eh beide doppelt mit gleichem text waren... :wink: :roll: . Ich mach das dann auch bei anderen topics um Ordnung zu schaffen, wenn ich mal wieder sowas bemerke, solange noch ein anderer Post mit wirklichem Namen da ist, der darauf hinweißt.

Verfasst: Samstag 14. Dezember 2002, 22:19
von RicmanX
Also ich hab n ziemliches Problem. "info" ist einfach n String oder so, kein Dictionary mehr. Das heißt man kommt an die Infos nicht mehr ran - bzw. ich bin zu blöd dazu :D

Verfasst: Sonntag 15. Dezember 2002, 01:23
von Beyond
Postings: Ja gut, daß die doppelten raus sind.

Mimetypes: Wichtig ist vorallem wie die Informationen in den Dateien stehen. Eine reine Zuordnung von Dateiname und Mimetype reicht leider nicht (dafür gibt es ein Python-Modul mimetypes). Aber schick mir einfach mal was Du hast. Email-Adresse -> webmaster@beyond-thoughts.com

Info: info ist jetzt ein Objekt -- sprich eine Instanz einer Klasse. siehe auch CIContentTypes.py
interessante Informationen kann man dann z.B. mit getattr oder einfach mit obj.attribut herausbekommen.

Extension: Aus dem Dateinamen kann man diese natürlich ermitteln. Das geht recht simpel ist aber nicht so verlässlich. Dafür könnte ich eine Extra-Funktion schreiben. Das andere wäre: verschiedene gültige Extensions für einen Mimetype zu defnieren und ggf. die gültige und derzeit verwendete Extension zurückzuliefern.


cu beyond

Verfasst: Sonntag 15. Dezember 2002, 08:52
von Milan
ich weiß zwar wie man dann die sachen da rausholt, aber das ist eigentlich nicht userfreundlich, weil du ständig überprüfen müsstest ob die attribute wirklich da sind. Das gleiche wäre es wenn du mit getattr arbeitest, weil man darauf nicht schnelle Dictionaryspeizifische Optionen anwenden kann. Ich fänd es besser wenn du noch in deine Basisklasse ne Methode einbauen könntest die gleich ein Dictionary formt, falls es gefordert wird. Soll heißen, das in deiner Klasse BasicContent eine Methode dict eingebaut werden könnte, die ein Dictionary nach der vorherigen Aufbauweise zurückliefert. Dadurch wäre es ja egal, mit welchem Contenttype du das machst, weil sich das dann vererbt.

Verfasst: Sonntag 15. Dezember 2002, 12:54
von Beyond
Ein dictionary gibt's schon: __dict__

Eine solche Vorgehensweise ist aber bad style!

Denn bei einem Dictionary weißt Du zunächst weder, ob es ein Attribut gibt noch, was es bedeutet (schlimmer).

Es ist wesentlich sinvoller mit isinstance zu prüfen ob der Content von der Klasse PictureContent ist. Denn dann weißt Du:
- es gibt width und height
- was das zu bedeuten hat.

Genau deshalb habe ich das ganze neu programmiert.

cu beyond

Verfasst: Sonntag 15. Dezember 2002, 13:13
von Milan
ich finde das ist berachtungsweise. :arrow: denn immerhin gibt es bei einem Dict die methoden has_key, items, keys, values. Die kann ich schnell durch for-schleifen laufen lassen, was eigentlich mein Ziel ist. Dann kann ich ähnlich wie mit getattr werte mit get rausholen.

Versteh mich nicht falsch, denn deine Klassen blieben ja erhalten und man könnte ja immer noch mit isinstance abfargen. nur lässt sich der Rest besser handhaben. Es ist ja nur eine nutzbare Option, nicht ein zwang das zu nehmen. das es das mit __dict__ schon gab, wusste ich ja nicht.
Schlechter Stil ist es meiner Meinung nach nicht, weil du ja eben abprüfen kannst was da ist etc.

Verfasst: Sonntag 15. Dezember 2002, 13:33
von Beyond
Was da ist kann man abprüfen. Nicht aber wie die Werte zu interpretieren sind. Ich habe mir daher für das .png-modul auch die Arbeit gemacht eine richtige __str__ Methode zu programmieren und auch gleich meine Referenz angegeben, sodaß man hier wirklich weiter arbeiten kann. Bei einem Flash-File ist z.B. eigentlich (habe ich aber anders implementiert) Breite und Höhe in 20*pixelzahl angegeben. Würdest Du einfach darauf zugreifen (mit anderer Implementation) käme wohl nicht das raus, was Du Dir erwartest....

Aber was ist z.B. wenn .pdf-Dokumente unterstützt werden. Da finde ich es garicht so leicht überhaupt festzulegen was Breite und Höhe dann sein soll. Man könnte sagen Breite und Höhe einer Seite, aber in .pdf-Dokumenten können Seiten verschiedener Größe auftauchen ... Soll man das Maximum nehmen? Man könnte auch alle Seiten "aneinander hängen" und davon die Maße nehmen.

Wenn es also nicht nur um Bilder geht ist die Sache nicht so einfach und intuitiv.

Nachdem es nach bisherigen Infos bei Dir aber nur um Bilder geht solltest Du immer auf PictureContent prüfen (sonst kannst Du zwar u.U. Deinen Code ausführen, aber er macht dann keinen Sinn -- so etwas sollte man verhindern! Das ist ähnlich wie ein dicker Käfer der auf dem Rücken liegt und mit den Beinen strampelt). Handelt es sich nicht um ein Bild solltest Du mit einer Fehlermedlung abrechen. Wenn doch ist ja eh alles bestens ...

Aber wenn Dir Deine Methode leichter fällt, mach es so. Ich habe auch schon einiges mit WFM-Status zusammen-gehackt. Da gibt's noch viel mehr Sachen, die man machen kann 8) ...

Was ich Dir sagen will: Sei Dir im Klaren was Du tust und wo Fehler in Deinem Code dadurch auftauchen können. Kommentiere diese Stellen v.a. wenn Du mit anderen zusammenarbeitest.

cu beyond

Verfasst: Sonntag 15. Dezember 2002, 13:40
von Milan
:wink: hab das ein wenig eng gesehen, weil ich eben nur Bilder brauche...

ich hab mich heute auch mal schlau gemacht in bezug auf mp3 und avi, aber außer tausend Editoren die sagen, die sagen sie wären die besten im umwandeln, hab ich keinen Hinweis oder Quellcode gefunden, der dir nützlich sein könnte. tut mir leid.

Verfasst: Donnerstag 19. Dezember 2002, 20:20
von RicmanX
Falls sich manche Leute wundern, neue URL ist jetzt http://www.pythonarea.net/cgi-bin/paf/m ... o/index.pl

Verfasst: Donnerstag 19. Dezember 2002, 21:13
von Beyond
Man muß z.B. nach "file format specifications" suchen. Bei SourceForge gibt's einige mp3-Projekte. Diese können z.B. mp3-Daten auslesen.

Für .ogg habe ich eines gefunden.

@Milan: Hättest Du Interesse es in das Modul einzuarbeiten?

Verfasst: Freitag 20. Dezember 2002, 14:15
von Milan
neugierig bin ich schon, aber ich habe keine Ahnung, wie du deine Module aufgebaut hast. am besten schickst du mir mal ne mail, wo drin steht was es amchen soll und wie es das zurückgeben soll.
In der Zeit muss ich dich auch erst mal enttäschen, da ich vor Weihnachten quasi "streike", weil erst mal Ferienstart ist. ansonsten hätt ich lust zu das zu machen.