Re: Fso Python binding
On Mon, 2009-02-16 at 09:28 +0100, Michele Renda wrote: > This was my second question. I come from Java, so the convention are > "getName", "setAge". > But now, thinking to pygtk, I remember that the convention was > "get_name","set_age". I will fix it. > Can you please confirm that the Python convention about classes > remain > "MyWondefulClass"? Yes, you can see the python convention in PEP8 [0]. The classes are in CapitalizedWords and the method names in lower_case_with_underscores. Then, it is also said somewhere in the document that consistency is more important than following the style, so in your case I would got for the methods with the same name than the dbus functions (CapitalizedWords) > > Yes I know the pain of trying to write generic code for gobject, qt > or > > efl. The python Dbus library allow you to specify the underlying > > mainloop you are using when you create the bus object, in your case > that > > would be more tricky I guess cause you use GObject as a base class > for > > all you proxies. May be possible though. > > > I don't know Qt, but I think there is something like QObject that do > the > same work (more or less). > I want to have a look... A lot of people told me that developing with > Qt > is more funny than with Gtk. My opinion on that : If I use C++, I prefer using Qt, but if I use C or python, then I prefer gtk. Then, Qt provides things that gtk doesn't (I don't know if the opposite is also true...) gui [0] http://www.python.org/dev/peps/pep-0008/ signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
Wiadomość Oryginalna
Od: Michele Renda
> Hello to all
>
> I am writing here to show something I was working today, and I'd like to
> know your opinions.
> I try to explain with a few of words. How someone of you know, I wrote
> Sephora. In lastest day I lost some time to trying to fix sephora with
> the new fso milestone. Where I was working I realized that I hate dbus
> :) Ok, I know it is very important, it is cross language compatibile,
> but I program in python, and I don't like to write too much code. If I
> want to turn on a led I want to do something like:
>
> device = ODeviced()
> device.getLED().getGta02AuxRed().setBlinking(2, 3)
>
> Or if I want to react to a function I want to do something like this:
>
> gps = OGpsd()
> def myfunc(i):
> # I do something here
> gps.connect('fixStatusChanged', myfunc)
>
> So, I studied a bit how to use reflection in Python and the source code
> written by Michael Lauer, and I wrote a Python binding for FSO, and I
> called with a lot of fantasy PyFso (It is only a transitory name,
> because I think this name is already used for another project).
>
> You can have a look here: [1]
>
> To help the navigation, it also print the structure of the object I
> created [2].
>
> For now it is only a proof of concept. I would like to know if someone
> else have the same feeling with dbus.
>
> Thank you
> Michele Renda
>
> [1] http://dl.getdropbox.com/u/562269/PyFso/pyfso.py
> [2] /home/michele/Dropbox/Public/PyFso/structure.txt
>
I used to play with dbus and FSO a while ago, and I came to a similar
conclusion - writing something simple takes too much time.
Instead of wrapping the interesting methods of FSO, I made a simple dbus object
wrapper.
To use it, one would pass the dbus bus name and object name. The resulting
object would be a python object with method names corresponding to the dbus
method names (I made my own, much simpler parser based on the one in mdbus),
while completely ignoring signals.
I used it to get GPS data from Gypsy, worked like a charm.
I could dig it up again and explain, if anyone's interested.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
On 16/02/2009 08:14, Guillaume Chereau wrote: > Yes but I was thinking of cli-framework where you interactively create > and manipulate the proxies objects. There the auto-completion would work > and be very helpful. > > I never listened about cli-framework... and now you made me curious. I will have a look on it. > By the way, why do you change the name convention for the dbus methods, > and make them all lowercase ? I know python convention is to use > lowercase, but in that case I would prefer having the same name as the > original DBus method (just a suggestion.) > > This was my second question. I come from Java, so the convention are "getName", "setAge". But now, thinking to pygtk, I remember that the convention was "get_name","set_age". I will fix it. Can you please confirm that the Python convention about classes remain "MyWondefulClass"? > Yes I know the pain of trying to write generic code for gobject, qt or > efl. The python Dbus library allow you to specify the underlying > mainloop you are using when you create the bus object, in your case that > would be more tricky I guess cause you use GObject as a base class for > all you proxies. May be possible though. > I don't know Qt, but I think there is something like QObject that do the same work (more or less). I want to have a look... A lot of people told me that developing with Qt is more funny than with Gtk. Have you a nice day Michele Renda ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
On Mon, 2009-02-16 at 07:51 +0100, Michele Renda wrote: > On 16/02/2009 03:44, Guillaume Chereau wrote: > > Hi Michele, > > > Hello Guillaume > > I share your feeling that directly using dbus in python is a little bit > > tedious. > > I didn't try your your code, just had a look at it, I like how the dbus > > methods are directly added into the object instead of using the > > __getattr__ method, it means we can use automatic completion from the > > python interpreter, something that is missing with DBus proxy objects. > > > I don't think the code completation will never work, at least in a > editor, because the methods available will be known only > during the execution of the code, not before :( Yes but I was thinking of cli-framework where you interactively create and manipulate the proxies objects. There the auto-completion would work and be very helpful. By the way, why do you change the name convention for the dbus methods, and make them all lowercase ? I know python convention is to use lowercase, but in that case I would prefer having the same name as the original DBus method (just a suggestion.) > The good part it that this library will not need to be updated if > fso-frameworkd will change. > The weak part is that fso-frameworkd deamon will change, all the > applications that use it will continue to need to be updated. > > What I like less is that you are using GObject, which mean I won't be > > able use your library for paroli. > > > Ops... my fault. I use PyGtk, so I thought that GObject is all the > world. And I forgot that exist a world done by other toolkits. > I think it needed to be called PyGtkFso or PyGObjectFso, and if the > ideas is nice, it will not be difficult to create a version of the same > library to > run with Qt and with Efl. I need only to study a bit PyQt and PyEfl. Yes I know the pain of trying to write generic code for gobject, qt or efl. The python Dbus library allow you to specify the underlying mainloop you are using when you create the bus object, in your case that would be more tricky I guess cause you use GObject as a base class for all you proxies. May be possible though. > > Also I though all the signals in GObject class had to be declared at the > > class level, how does it work with your introspection mechanism ? > > > This is the part I like more (but I don't know how much clean it is) > I redefine the method "connect" and if a signal si a signal for dbus > (that I read on runtime), I connect it direct to dbus, else I contine to > connect to the object. Ah I see, nice ! > Still I have to test well the part with signals, I tested well only methods. > To be runned, it need the mdbus script copied as mdbus.py in the same > forlder of pyfso.py (I steal a class from Michael). > > Anyway, I think it is a good initiative, maybe Mickey will consider > > adding this or something similar to the framework git. > > > > > For now I will try to use on some programs I created. But I son't think > it is so good code to enter in framework. For now it is only an experiment. I'll keep an eye on this project. If you could somehow embed it into an interactive python interpreter (see cli-framework), then I would give a try for sure. > > Thank you > Michele Renda > Regards, Guillaume Chereau signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
On 16/02/2009 03:44, Guillaume Chereau wrote: > Hi Michele, > Hello Guillaume > I share your feeling that directly using dbus in python is a little bit > tedious. > I didn't try your your code, just had a look at it, I like how the dbus > methods are directly added into the object instead of using the > __getattr__ method, it means we can use automatic completion from the > python interpreter, something that is missing with DBus proxy objects. > I don't think the code completation will never work, at least in a editor, because the methods available will be known only during the execution of the code, not before :( The good part it that this library will not need to be updated if fso-frameworkd will change. The weak part is that fso-frameworkd deamon will change, all the applications that use it will continue to need to be updated. > What I like less is that you are using GObject, which mean I won't be > able use your library for paroli. > Ops... my fault. I use PyGtk, so I thought that GObject is all the world. And I forgot that exist a world done by other toolkits. I think it needed to be called PyGtkFso or PyGObjectFso, and if the ideas is nice, it will not be difficult to create a version of the same library to run with Qt and with Efl. I need only to study a bit PyQt and PyEfl. > Also I though all the signals in GObject class had to be declared at the > class level, how does it work with your introspection mechanism ? > This is the part I like more (but I don't know how much clean it is) I redefine the method "connect" and if a signal si a signal for dbus (that I read on runtime), I connect it direct to dbus, else I contine to connect to the object. Still I have to test well the part with signals, I tested well only methods. To be runned, it need the mdbus script copied as mdbus.py in the same forlder of pyfso.py (I steal a class from Michael). > Anyway, I think it is a good initiative, maybe Mickey will consider > adding this or something similar to the framework git. > > For now I will try to use on some programs I created. But I son't think it is so good code to enter in framework. For now it is only an experiment. Thank you Michele Renda ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fso Python binding
Hi Michele,
I share your feeling that directly using dbus in python is a little bit
tedious.
I didn't try your your code, just had a look at it, I like how the dbus
methods are directly added into the object instead of using the
__getattr__ method, it means we can use automatic completion from the
python interpreter, something that is missing with DBus proxy objects.
What I like less is that you are using GObject, which mean I won't be
able use your library for paroli.
Also I though all the signals in GObject class had to be declared at the
class level, how does it work with your introspection mechanism ?
Anyway, I think it is a good initiative, maybe Mickey will consider
adding this or something similar to the framework git.
Cheers,
-gui
On Mon, 2009-02-16 at 02:22 +0100, Michele Renda wrote:
> Hello to all
>
> I am writing here to show something I was working today, and I'd like to
> know your opinions.
> I try to explain with a few of words. How someone of you know, I wrote
> Sephora. In lastest day I lost some time to trying to fix sephora with
> the new fso milestone. Where I was working I realized that I hate dbus
> :) Ok, I know it is very important, it is cross language compatibile,
> but I program in python, and I don't like to write too much code. If I
> want to turn on a led I want to do something like:
>
> device = ODeviced()
> device.getLED().getGta02AuxRed().setBlinking(2, 3)
>
> Or if I want to react to a function I want to do something like this:
>
> gps = OGpsd()
> def myfunc(i):
> # I do something here
> gps.connect('fixStatusChanged', myfunc)
>
> So, I studied a bit how to use reflection in Python and the source code
> written by Michael Lauer, and I wrote a Python binding for FSO, and I
> called with a lot of fantasy PyFso (It is only a transitory name,
> because I think this name is already used for another project).
>
> You can have a look here: [1]
>
> To help the navigation, it also print the structure of the object I
> created [2].
>
> For now it is only a proof of concept. I would like to know if someone
> else have the same feeling with dbus.
>
> Thank you
> Michele Renda
>
> [1] http://dl.getdropbox.com/u/562269/PyFso/pyfso.py
> [2] /home/michele/Dropbox/Public/PyFso/structure.txt
>
>
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
signature.asc
Description: This is a digitally signed message part
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Fso Python binding
Hello to all
I am writing here to show something I was working today, and I'd like to
know your opinions.
I try to explain with a few of words. How someone of you know, I wrote
Sephora. In lastest day I lost some time to trying to fix sephora with
the new fso milestone. Where I was working I realized that I hate dbus
:) Ok, I know it is very important, it is cross language compatibile,
but I program in python, and I don't like to write too much code. If I
want to turn on a led I want to do something like:
device = ODeviced()
device.getLED().getGta02AuxRed().setBlinking(2, 3)
Or if I want to react to a function I want to do something like this:
gps = OGpsd()
def myfunc(i):
# I do something here
gps.connect('fixStatusChanged', myfunc)
So, I studied a bit how to use reflection in Python and the source code
written by Michael Lauer, and I wrote a Python binding for FSO, and I
called with a lot of fantasy PyFso (It is only a transitory name,
because I think this name is already used for another project).
You can have a look here: [1]
To help the navigation, it also print the structure of the object I
created [2].
For now it is only a proof of concept. I would like to know if someone
else have the same feeling with dbus.
Thank you
Michele Renda
[1] http://dl.getdropbox.com/u/562269/PyFso/pyfso.py
[2] /home/michele/Dropbox/Public/PyFso/structure.txt
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
