Actually I just remembered twisted can interact with the stdlib logging library as well through `twisted.python.log.PythonLoggingObserver`.
So I would change it to using `logging` and in the twisted interface implementation use that. That leaves us with twisted specific code only in: * protocol.py * client.py * object.py * endpoints.py And also the tests needs a bit of abstraction as well, preferably by testing the D-Bus protocol implementation by itself. — Sent from Mailbox On Mon, May 25, 2015 at 8:41 AM, null <[email protected]> wrote: > I forked the project yesterday (github.com/wolfhechel/txdbus) and had another > look at it. > The first thing I noticed was that three tests fails on Python 3.4, these > seems to be related to string -> bytes differences in the socket > implementation which needs to be taken care of first. > Six is already a requirement so I would probably use that in order to > normalise the output from the protocols. > Second step would be to separate all Twisted related code into its own > interfaces and place that code in its own package. > From those interfaces I would create the abstraction and then create the > asyncio implementation on top of that. > As for the logging, two approaches came to mind: > 1. Initialize logging alongside the event loop abstraction and pass the log > object to all involved classes. > 2. Setup a global logging object in txdbus.log and upon initalization setup > the appropriate logging facility (default to stdlib logging). > I would prefer alternative number 1 since IMHO global objects with common > names (such as logger, log, logging) tend to collide with a lot of other > packages and increase chances of circular import dependencies. > Since this is really your project, do you wish to start your own fork so that > the main code is held in your account? Otherwise I’ll just give you write > permission in the fork I’ve already done. > My vacation doesn’t start until July really but I do have some spare time on > the evenings on which I will work on this. > So for planing and dividing the work I suggest we start of by mapping the > work needed to be done and start creating issues on the repository. > — > Sent from Mailbox > On Sun, May 24, 2015 at 11:33 PM, Elizaveta Guseva <[email protected]> > wrote: >>> >>> Ultimately it is your choice, but it sounds like there is interest in >>> this project from the txdbus community, which never hurt a project's >>> chances of success :) >> Awesome. For me, with my primary scientific programming experience, help is >> never bad =) >> OK, I'll start with planning. Will keep you updated. >> *Pontus,* >> I will start figuring out how to abstract the event loop. >> Do you have any specific plan of action in mind? >> With regards, to your plans of participation... >> I don't have much of the collaborative coding experience. >> I am not sure what would be the best way of work organization. >> Eliza >> On Sun, May 24, 2015 at 4:57 PM, Tycho Andersen <[email protected]> wrote: >>> On Sat, May 23, 2015 at 09:42:21PM -0400, Elizaveta Guseva wrote: >>> > Hi, >>> > >>> > *Pontus,* >>> > >>> > As I understood from the discussion you mentioned, the author of txbus >>> > cogane wants to keep one code base in order to wait for kdbus merge. >>> > >>> > I think it's not compatible with asyncio, because asyncio isn't supported >>> > in 2.7. >>> >>> asyncio is supported in 2.7 (and <3.3), just not as an stdlib module, >>> so I don't think this is a big factor for us, as we already require >>> users to install it (qtile's event loop is asyncio based no matter >>> which version of python you're running). >>> >>> > Besides that as I saw from code txdbus relies not only on twisted event >>> > loop but also on logger for example. I don't know how it would be >>> possible >>> > to separate twisted and asyncio in that framework without fork, to be. >>> > >>> > I'm also not sure if we should worry about kdbus anytime soon, judging >>> from >>> > the heated discussion about merge into kernel. Maybe I am wrong. >>> > >>> > *Tycho,* >>> > >>> > Where do you think is better to start from txdbus or python-dbus? >>> > >>> > Pontus listed files in txdbus which rely on Twisted. >>> > >>> > As for python-dbus, it's: >>> > >>> > >>> > - *bus.py -- calls for abstract async from connection.py* >>> > - _compat.py -- None >>> > - *connection.py -- has abstract async function* >>> > - *_dbus.py -- asks for abstract loop* >>> > - *decorators.py -- calls for abstract async* >>> > - exceptions.py -- None >>> > - *_expat_introspect_parser.py -- None* >>> > - >>> > *gi_service.py -- uses gobjects * >>> > - >>> > *glib.py -- glib.. * >>> > - gobject_service.py -- depricated >>> > - lowlevel.py -- None >>> > - *mainloop -- import from glib bindings* >>> > - *proxies.py -- uses connections' abstract async* >>> > - *server.py **-- asks for abstract loop* >>> > - *service.py -- calls for abstract async* >>> > - types.py -- None >>> > >>> > To me it seems python-dbus hid its gobject dependencies pretty well and >>> it >>> > might be rather easy to add asyncio without touching most of the code. >>> >>> It sounds to me like you might get some help doing it in txdbus, >>> whereas you wouldn't doing it in dbus-python, which is a benefit. >>> >>> A pure python implementation also causes less of a problem with >>> distribution, although again I'm not sure this is a big concern for us >>> since the majority of our users are Linux with a handful of OpenBSD >>> folks. >>> >>> Ultimately it is your choice, but it sounds like there is interest in >>> this project from the txdbus community, which never hurt a project's >>> chances of success :) >>> >>> Tycho >>> >>> > Eliza >>> > >>> > >>> > >>> > >>> > On Sat, May 23, 2015 at 6:54 AM, <[email protected]> wrote: >>> > >>> > > I’ve mentioned this on an issue in txdbus >>> > > https://github.com/cocagne/txdbus/issues/11 and the author had some >>> > > pretty good points on implementing a twisted/asyncio abstraction >>> > > in the txdbus library. >>> > > >>> > > I would be willing to contribute to this as well if the decision is >>> taken >>> > > to simply work on top of txdbus. >>> > > >>> > > >>> > > >>> > > On Wed, May 20, 2015 at 5:01 AM, Elizaveta Guseva <[email protected]> >>> > > wrote: >>> > > >>> > >> Hello Pontus, >>> > >> >>> > >> Oh, cool! Thanks a lot for your recommendation! >>> > >> I will definitely look into it. >>> > >> >>> > >> Eliza >>> > >> >>> > >> On Tue, May 19, 2015 at 7:47 AM, Pontus Karlsson < >>> > >> [email protected]> wrote: >>> > >> >>> > >>> Not sure on how far you've gotten on researching this, but as the >>> model >>> > >>> of asyncio is heavily inspired by the Twisted structure >>> > >>> I would recommend trying to port txdbus >>> > >>> <https://github.com/cocagne/txdbus> to asyncio. >>> > >>> >>> > >>> I was actually looking into doing this a month back and started to >>> map >>> > >>> the code structure and looking into what needs to be altered: >>> > >>> >>> > >>> - *authentication.py* - Zope interfaces, twisted logger >>> > >>> - *bus.py* - twisted logger and Factory? >>> > >>> - *client.py* - Heavy twisted usage >>> > >>> - *endpoints.py* - Heavy twisted usage >>> > >>> - error.py - No Twisted API usage >>> > >>> - interface.py - No Twisted API usage >>> > >>> - introspection.py - No Twisted API usage >>> > >>> - marshal.py - No Twisted API usage >>> > >>> - message.py - No Twisted API usage >>> > >>> - *objects.py* - Zope interfaces, twisted defer >>> > >>> - *protocol.py* - Zope interfaces, heavy twisted usage >>> > >>> - *router.py* - Twisted log >>> > >>> >>> > >>> My recommended approach here is to fork it and abstract the event >>> loop >>> > >>> to work with both Twisted and asyncio. >>> > >>> >>> > >>> Den måndag 4 maj 2015 kl. 22:54:20 UTC+2 skrev Eliza Guseva: >>> > >>>> >>> > >>>> Hello all, >>> > >>>> >>> > >>>> First. Thanks a lot for choosing me as a student for your project!! >>> > >>>> >>> > >>>> As an international student in USA, I'm having some challenges with >>> > >>>> bureaucratic system in my University. >>> > >>>> It starts taking too long at the moment. So I'd better not wait even >>> > >>>> longer and start communication now. >>> > >>>> I have to warn: there might be issues with the system, but I'm >>> trying >>> > >>>> hard to get it work. >>> > >>>> >>> > >>>> On the brighter topic:) >>> > >>>> As I understand it's time to read the documentation now. >>> > >>>> Could you recommend me the reading, which suits the best for the >>> > >>>> purposes of the project? >>> > >>>> What source codes do you think, I should look into to get a better >>> > >>>> understanding? >>> > >>>> I will be asking questions, in the progress. >>> > >>>> >>> > >>>> Thanks a lot! >>> > >>>> >>> > >>> -- >>> > >>> You received this message because you are subscribed to the Google >>> > >>> Groups "qtile-dev" group. >>> > >>> To unsubscribe from this group and stop receiving emails from it, >>> send >>> > >>> an email to [email protected]. >>> > >>> For more options, visit https://groups.google.com/d/optout. >>> > >>> >>> > >> >>> > >> -- >>> > >> You received this message because you are subscribed to a topic in the >>> > >> Google Groups "qtile-dev" group. >>> > >> To unsubscribe from this topic, visit >>> > >> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>> > >> To unsubscribe from this group and all its topics, send an email to >>> > >> [email protected]. >>> > >> For more options, visit https://groups.google.com/d/optout. >>> > >> >>> > > >>> > > -- >>> > > You received this message because you are subscribed to the Google >>> Groups >>> > > "qtile-dev" group. >>> > > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > > email to [email protected]. >>> > > For more options, visit https://groups.google.com/d/optout. >>> > > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "qtile-dev" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "qtile-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "qtile-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qtile-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
