The existing codebase was written in adherence to the Twisted coding standard in case there was ever a call to merge it into the Twisted mainline. Personally, I abhor their coding standard but I think consistency with the surrounding codebase is generally worth the pain. I'm not interested in draconian adherence to the standard, especially since it seems unlikely to be merged at this point, but I'd appreciate it if the new code looked similar to the surrounding code in order to avoid jarring and potentially confusing differences for future developers. Make sense?
Tom On Wed, May 27, 2015 at 2:57 AM, <[email protected]> wrote: > Hi Tom, thank you for your interest in participating in this project! > Of the top of my head there’s really nothing that needs explaining, the > code is well documented and structured in a logical fashion. > > Would you prefer us to keep the coding style consistent across the project? > I noticed my coding style differs quite heavily from yours, I believe > however that a “guest” of a project should adapt to the already defined > style guidelines so I would have no trouble doing just that. > > — > Sent from Mailbox <https://www.dropbox.com/mailbox> > > > On Tue, May 26, 2015 at 7:44 PM, Tom Cocagne <[email protected]> > wrote: > >> Pontus & Eliza, >> >> Please consider me a resource for your efforts. I have little development >> time available and I wrote txdbus quite a while back but I should at least >> be able to answer some questions and serve as a sounding board for design >> and implementation ideas. Good luck! >> >> Tom Cocagne >> >> On Tuesday, May 26, 2015 at 2:07:32 AM UTC-5, Pontus Karlsson wrote: >>> >>> How are you running the tests? Using tox I’m not getting that import >>> error so try that and verify that the issue still exists. >>> >>> Could you enable issues on the repository and start an initial branch >>> for the abstraction? >>> >>> I suggest we keep a branch for the abstraction and when that’s done >>> we’ll start with the asyncio branch. >>> >>> I’ve added a Gitter room as well for general talks regarding how to >>> proceed, unless you prefer keeping those discussions in this mailing list? >>> >>> — >>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>> >>> >>> On Tue, May 26, 2015 at 6:34 AM, Elizaveta Guseva <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> I've added you as collaborator to my fork. >>>> >>>> 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. >>>>> >>>> >>>> OK. That sounds like a plan. >>>> Last time I worked together with a collaborator. I kept a plan in the >>>> Wiki of gitHub in order to remember what was the last step and who is >>>> responsible for which task. >>>> I don't know if you'd like to use it for coordination. >>>> https://github.com/gelisa/txdbus/wiki/Plan >>>> >>>> I also keep some notes there too. Mainly for myself to keep track of >>>> things. You can disregard them >>>> >>>> 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. >>>>> >>>> That's fine. >>>> >>>> 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. >>>>> >>>> >>>> Ugh, I run the tests too and saw them. I am going to look into it. >>>> Did you have issues with import UNIXServerEndpoint/UNIXClientEndpoint >>>> in Python 3.4? >>>> It's looks similar to the endpoints, which can be imported in the >>>> source file of Twisted 15.2.1. Which puzzles me. >>>> >>>> Eliza >>>> >>>> >>>> >>>> >>>> >>>> On Mon, May 25, 2015 at 2:59 AM, <[email protected]> wrote: >>>> >>>>> 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 <https://www.dropbox.com/mailbox> >>>>> >>>>> >>>>> On Mon, May 25, 2015 at 8:41 AM, [email protected] < >>>>> [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 <https://www.dropbox.com/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. >>>>> >>>> >>>> -- >>>> 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 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 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.
