Python 3.2 Migration in develop bzw. 1.0 Release

[callidomus]

Hi Jan,

scheint schon länger kaputt zu sein: in meinem Pull-Request war der dritte Rückgabewert eine Datetime der Endzeit, nach der Übernahme ein Datetime der Startzeit. Die Endzeit finde ich schon wichtig.

ich glaube Du irrst Dich. In Deinem Request war zwar eine datetime dabei, die immer noch drin ist, aber es war und ist nicht die Endzeit. An der Stelle im Code müsste man sich die berechnen (DTEND - DTSTART + dt).


Bis bald

Marcus

[JNK]

Hallo Marcus,

das glaube ich nicht. Bei mir stand da "de", was mit dem Datetime von DTEND befüllt ist. und das ist m.E. schon das Ende des Termins. Funktioniert bei mir auch so.

Gruss,

der Jan

[callidomus]

Hi Jan,

wir haben beide Recht :-)

Beim Konvertieren auf dict habe ich Dein de nicht übernommen.

Es fehlt aber bei wiederkehrenden Einträgen, dort wurde nur die datetime vom Start übergeben.

Bis bald

Marcus

[JuMi2006]

Hallo Marcus ... bist du beim Problem mit asynchat und der Squeezebox schon weitergekommen? Das fehlt im Moment noch um komplett auf python3 umzusteigen.

Gruß

[JNK]

wir haben beide Recht :-)

Beim Konvertieren auf dict habe ich Dein de nicht übernommen.

Es fehlt aber bei wiederkehrenden Einträgen, dort wurde nur die datetime vom Start übergeben.

Ja, das wusste ich, das wollte ich mir eigentlich nochmal in ner ruhigen Stunde angucken. Und was machen wir nun damit?

Das sqlite kann ich nicht mehr testen, ich habe fast alle sqlite zugusten der rrd gelöscht und den rest packe ich nicht.

Gruss,

der Jan

[callidomus]

Hi Mirko,

Hallo Marcus ... bist du beim Problem mit asynchat und der Squeezebox schon weitergekommen? Das fehlt im Moment noch um komplett auf python3 umzusteigen.

leider nicht. Ich habe es mir mal angesehen konnte aber nicht offensichtliches finden. Ohne Squeezebox kann ich aber schlecht Debug-Outputs setzen. Ich müsste mich an das Problem rantasten um den Fehler einzugrenzen.
Vllt. kann der Autor des Plugins hier helfen? Robert?

Bis bald

Marcus

[callidomus]

Hi Jan,

Und was machen wir nun damit?

na fixen. Ich schreibe es mal auf meine Liste, steht aber ziemlich weit unten.

Bis bald

Marcus

[JuMi2006]

Das hier hilft vielleicht:

https://mail.python.org/pipermail/py...ne/578585.html

Nach erstem überdenken passt es, leider fehlt mir hier jetzt das Wissen um Bits,Bytes,Hex ...

Kann es damit zusammenhängen dass die commands die das Plugin sendet explizit als utf8 geliefert werden?

Gruß

[callidomus]

Hallo,

Und sqlite pack killt SH.py:

das ist gefixed.

Es fehlt aber bei wiederkehrenden Einträgen, dort wurde nur die datetime vom Start übergeben.

Das auch. Es wird jetzt ein Dict zurück gegeben mit 'Start' und 'End' als Datetime-Object.

Bis bald

Marcus

[callidomus]

Hallo Mirko,

leider hilft der Link nicht.

Kann es damit zusammenhängen dass die commands die das Plugin sendet explizit als utf8 geliefert werden?

Vereinfacht gesagt, alles was über das Netzwerk geht muss ein Byte-Ojekt sein.
Das bekommt man wenn man ein einen String mit .encode() aufruft. Oder bytearray(), Bytes(), b'binarystring'.

Alles Strings sind bei Py3.2 als UTF-8 kodiert, sofern es explizit nicht anders angibt.

An irgendeiner Stelle wird aber der UTF-8 String uncodiert auf das Netzwerk geschickt. Da meckert er. Leider konnte ich die Stelle nicht so schnell ausfindig machen.

Bis bald

Marcus

[JuMi2006]

Das scheint zu passieren wenn die Antwort aus dem Netzwerk kommt. Soweit konnte ich das zumindest mit Logs eingrenzen. Bis zum Senden der Befehle läuft alles gut. Kommt die erste Antwort von der Squeezebox hängts. An irgend einer anderen Stelle hatte ich das mit dem Terminator schonmal gelesen ... finde es nur nicht mehr...verstanden hab ich den Code aber eh nicht.

[JNK]

Danke für die Fixes, hier noch einer von mir:

wettercom-Plugin, __init__.py:

l. 42-44

        searchURL = 'http://' + self._server + '/location/index/search/' \
            + location + '/project/' + self._project + '/cs/' \
            + hashlib.md5(self._project[COLOR="Red"].encode('UTF-8')[/COLOR] + self._apikey[COLOR="red"].encode('UTF-8')[/COLOR] + location[COLOR="red"].encode('UTF-8')[/COLOR]).hexdigest()

l. 74-76

        forecastURL = 'http://' + self._server + '/forecast/weather/city/' \
            + city_code + '/project/' + self._project + '/cs/' \
            + hashlib.md5(self._project[COLOR="red"].encode('UTF-8')[/COLOR] + self._apikey[COLOR="red"].encode('UTF-8')[/COLOR] + city_code[COLOR="red"].encode('UTF-8')[/COLOR]).hexdigest()

Gruss,

der Jan

[callidomus]

Hi Jan,

danke, ist - fast so - drin.

Bis bald

Marcus

[JNK]

Marcus,

Das ist ja elegant. Hatte erst überlegt, ob das wohl geht und es dann doch 'konservativer' gemacht. Danke.

Gruß,

der Jan

[mike]

Das ical-Plugin hat jetzt einen Fehler (bei mir): Es meldet das str keine decode-Funktion hat:

  File "/usr/smarthome/plugins/ical/__init__.py", line 67, in __call__
    ical = ical.decode()
AttributeError: 'str' object has no attribute 'decode'

Ein:

diff --git a/plugins/ical/__init__.py b/plugins/ical/__init__.py
index 00ad9c5..aa10332 100755
--- a/plugins/ical/__init__.py
+++ b/plugins/ical/__init__.py
@@ -64,7 +64,7 @@ class iCal():
             except IOError as e:
                 logger.error('Could not open ics file {0}: {1}'.format(ics, e))
                 return {}
-        ical = ical.decode()
+        #ical = ical.decode()
         now = self._sh.now()
         offset = offset - 1  # start at 23:59:59 the day before
         delta += 1  # extend delta for negetiv offset

behebt das Problem bei mir. Wahrscheinlich geht es dann aber bei anderen nicht mehr?

Grüße
Mike