Gast piwo Geschrieben May 7, 2017 at 13:05 Share Geschrieben May 7, 2017 at 13:05 liebe leute ... soweit ich das beurteilen kann wäre das wohl genau das was tf wirklich voranbringen könnte : ein switch der python bindings auf python3/asyncio was allerdings keinen stein auf dem anderen liesse, da das alles dann einigermassen einfacher wäre meinungen ? chancen (borg etc) ? lg wolfgang Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben May 9, 2017 at 09:04 Share Geschrieben May 9, 2017 at 09:04 Du meinst intern für die TCP/IP Kommunikation? Womöglich könnte der Code dadurch einfacher/verständlicher werden, allerdings ist das Handling so wie es aktuell geschieht ja jetzt viele Jahre getestet. Das umzureißen würde erstmal zu neuen Problem führen. Davon abgesehen würden wir ganz viel Python 2 vs 3 if/else haben, da wir ja weiterhin Kompatibilität mit Python 2 haben wollen. Ich könnte mir das frühestens vorstellen wenn Python 2 tot ist. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Gast piwo Geschrieben May 10, 2017 at 07:08 Share Geschrieben May 10, 2017 at 07:08 ok, dann sagt gleich nein. warum man auf den tod von python2 warten will erschliesst sich mir nämlich nicht. der sinn von asyncio ist ja gerade dass von applikationsseite eine struktur (segmentierung in coroutinen bzw. atomare codeabschnitte bzw. "sinnvolle" punkte für yields statt blindem threading) eingebracht wird die der performance dient. ausserdem wird in einem jahr wohl keine sinnvolle library NICHT eine asyncio-version sein ... aber bitte. ein major rework der python-api wäre nicht unbedingt ein fehler. eine bessere abstraktion der jetzingen async-architektur mit callbacks wäre m.m.n. nicht der schlechteste ansatz. würde auch die irregularitäten und impliziten race-conditions (man denke nur an response_expected_all() das man gezwungen ist schon defaultmässig einzusetzen und andere feinheiten sobald man eine 2. eventloop neben der tf-loop haben muss ....). ALTERNATIV : mir ist die tf-programmierung bzw. tf-klitterei eigentlich vollkommen egal. was ich brauche ist von mir aus nur eine übergabeschnittstelle : am besten euer datalogger der als ewig restarteter prozess ewig restartete stacks abgreift und die daten in eine rethink-db schreibt (oder in eine redis oder was weiss ich wohin wo man das einfach und effizient präsentiert bekommt - mqtt ist mir persönlich schon zu schwergewichtig ...) bitte da mal hirnschmalz reinlegen, nicht halblösungen die jeder sowieso wieder privat pflegen muss ... DANKE Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben May 11, 2017 at 14:01 Share Geschrieben May 11, 2017 at 14:01 warum man auf den tod von python2 warten will erschliesst sich mir nämlich nicht. Die Unterstützung für Python 2 können wir natürlich erst entfernen wenn Python 2 nicht mehr so weiträumig verwendet wird. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Gast piwo Geschrieben May 12, 2017 at 21:12 Share Geschrieben May 12, 2017 at 21:12 MODIFY : kein normaler mensch wird EINE codebasis für python 2 UND 3 gleichzeitig pflegen oder kodieren - hm ? d.h. mit python3 würde sich eine rekodierung aufgrund von asyncio auf natürliche weise anbieten. oder wollt ihr den momentanen schinken ewig so belassen ? dann bitte eine klare antwort. die bisherigen antworten empfinde ich nämlich als abwiegeln bzw. ignoranz und verschieben weil keine lust etc. mir fehlt auch ein kommentar zum rest - d.h. wie ihr euch vorstellt dass man (ausser mqtt das auch nur unkomplett und unnötig kompliziert ist) daten von tf-stacks sinnvoll in gut performende schnittstellen bringen kann. nochmals : z.b. rethink-db für datenkollektion bzw. irgendwelche key-value-schnittstellen um setter anzustossen und output zu generieren (ohne die low-level-programmierung auf bricklet-ebene) ... danke. ich fürchte dass das nicht so gern hier beantwortet wird, aber ich habe den eindruck, dass die applikationsseite von tf schon weitgehend ein stiefkind ist ... lg wolfgang Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben May 13, 2017 at 16:01 Share Geschrieben May 13, 2017 at 16:01 kein normaler mensch wird EINE codebasis für python 2 UND 3 gleichzeitig pflegen oder kodieren - hm ? Das ist durchaus üblich. Ich weiß gar nicht so 100%ig was dein Problem ist, deswegen bekommst du vermutlich auch nicht die Antwort die du dir wünscht. Es ist aktuell nicht geplant die Python Bindings groß zu verändern. Dir scheint ja Performance sehr wichtig zu sein, unser System kann bis zu 1000 Nachrichten pro Sekunde pro Stapel generieren, diese kann man mit den Bindings so wie sie sind problemlos behandeln. Auch auf einem RPi oder dem RED Brick. Da würde eine Umstellung auf asyncio nicht viel ändern. Unsere Bindings bieten einen Realzeit-Zugriff auf die aktuellen Daten des System, wenn du von rethink-db sprichst nehme ich an du möchtest Daten archivieren und später auf diese zugreifen können. Das ist nicht die Aufgabe der Bindings im generellen und hat auch nichts mit den Python Bindings oder asyncio zu tun. Die Vorgehensweise dafür wäre mit Hilfe der Bindings die Daten auszulesen und mit einem Zeitstempel in der Datenbank deiner Wahl, z.B. rethink-db, zu speichern. Ab da kannst du dann das rethink-db JSON-Interface nutzen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Gast piwo Geschrieben February 18, 2018 at 17:05 Share Geschrieben February 18, 2018 at 17:05 Es ist aktuell nicht geplant die Python Bindings groß zu verändern. ... ist nun ein dreiviertel jahr vergangen seit meinen letzten moanings. alles ist ja seitdem viel besser geworden - siehe all die bugs die nun endlich nicht mehr als raceconflicts schlagend werden usw. usf. ;-) aber die zeit tickt - https://pythonclock.org/ und daher : ich erwarte mir von tinkerforge schon eine "offizielle" stellungnahme wie das da weitergehen soll und wird ... schliesslich steht und fällt ja aufgrund des fehlens von brauchbaren applikationslibraries (d.h. codebase abseits des brickd's und der rudimentären hw-access-libs) jeder muss sich all den schmonz der zu einer brauchbaren applikation führt selber entsteissen (was entweder zu hardcoded middleware führt, die dann gecachte daten mit "fortgeschritteneren" mitteln behandelbar macht - - - oder zu mehr oder weniger elaborierten versuchen mittels introspektion vorgefundener parametrierter stacks selber middleware zu sein) ich finde das irgendwie dämlich, dass jeder da im regen steht und selber die drainage am hals hat. der momentanen vorhandene prozedurale kitt der sich "bindings" nennt ist nämlich mit modereneren mitteln nicht ganz leicht zu "fressen" ausser man will prozesskommunikation mit einer separaten eventloop managen. auch da wünsche ich mir ein bisschen vision der maintainer was denn der "use-case" so sein soll in python. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.