2012/5/30 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>:
> On Wednesday, May 30, 2012, Davide Andreoli wrote:
>
>> 2012/5/30 Kai Huuhko <kai.huu...@gmail.com <javascript:;>>:
>> > 2012/5/30 Davide Andreoli <d...@gurumeditation.it <javascript:;>>:
>> >> 2012/5/29 Kai Huuhko <kai.huu...@gmail.com <javascript:;>>:
>> >>> Currently the python bindings have get/set functions as in the C api,
>> >>> in addition to this it has object properties which have their
>> >>> functionality implemented by simply calling those functions, such as
>> >>> in the below example:
>> >>>
>> >>> def remember_position_set(self, remember):
>> >>> elm_video_remember_position_set(self.obj, remember)
>> >>>
>> >>> def remember_position_get(self):
>> >>> return bool(elm_video_remember_position_get(self.obj))
>> >>>
>> >>> property remember_position:
>> >>> def __get__(self):
>> >>> return self.remember_position_get()
>> >>> def __set__(self, remember):
>> >>> self.remember_position_set(remember)
>> >>>
>> >>> I propose that the get/set functions are removed from the python api
>> >>> and replaced by the properties, so the above example simply becomes:
>> >>>
>> >>> property remember_position:
>> >>> def __get__(self):
>> >>> return bool(elm_video_remember_position_get(self.obj))
>> >>> def __set__(self, remember):
>> >>> elm_video_remember_position_set(self.obj, remember)
>> >>>
>> >>> Please tell me what you think about this change.
>> >>>
>> >>
>> >> I disagree here, we have compatibility layer in all the efl pybindings,
>> >> don't see a reason to not follow the scheme here.
>> >> I like/prefer to write using the c style functions usually, please
>> >> leave at the user the choice :P
>> >> ...I know is annoying to write properties
>> >
>> > Having both the get/set functions and a property for one functionality
>> > is confusing for new pythonic efl developers. We've already revamped
>> > much of the py-elm bindings breaking many existing applications in the
>> > process, this would be a good time to do more damage by simplifying
>> > the python api.
>>
>> I have 2 applications written in py, one is 10000 lines of py code...
>> do you want to rewrite ALL my apps for me ?? :P
>>
>> Really: You are proposing to remove 90% of the functions from
>> the bindings. I would say: no way.
>>
>> Also we discussed this long time ago and we choosed to ALWAYS
>> keep c "compatibility" in all the bindings
>>
>> >
>> > In the spirit of this, I'm also looking into replacing the py-elm
>> > callback_xxx_add/del functions with a single C api equivalent evas
>> > smart_callback_add/del("xxx"... function. This also means that we
>> > won't need to maintain the functions when signals are added or removed
>> > from C.
>>
>> We discussed this some years ago, we decided to keep all the cb functions
>> for the user, so you don't have to browse the docs to know what callbacks
>> are available for the widget.
>> I agree to add a generic func (smart_callback_add/del("xxx"...))
>> But I prefer to keep also the explicit ones for reference.
>>
>>
>> >
>> > If we are ever going to push for a release and wider acceptance of the
>> > bindings, we need to make the py bindings api as simple as possible,
>> > as feature complete as possible, and as well documented as possible.
>> > Having them easier to maintain is a nice bonus too.
>>
>> In general I agree, BUT I don't want to break stuff more than necessary.
>> IMO removing stuff just to make maintaining easier is not a good approach.
>
>
> Agreed, and it should be easy to use... This will help by doing exceptions
> on wrong callbacks, setters/getters are used by properties anyway. I don't
> think it will buy us much to remove
To clarify:
Only the functions which are logically a property of the object and
have a single function argument would be replaced. Also there are
python reserved words like "file" which cannot be used for properties,
where the file_get/file_set functions should still be used.
It is not my intention to forcefully break everything. We (or
application developers) could provide C api compatibility with
wrappers:
class Video(elementary.Video):
def remember_position_get(self):
return self.remember_position
def remember_position_set(self, remember):
self.remember_position = remember
With the callbacks, what I didn't take into consideration at first are
the different conversion functions. In that light, the current
implementation of the cb functions is ideal so I no longer see any
need to change anything about them.
We should have a proper api reference documentation online just like
the C api has, and the usage of properties and other python features
should be concisely documented along with code examples.
Currently I can't get epydoc to parse py-elm docstrings properly, it
picks up only ObjectItem classes and doesn't show any errors. Does
anyone know if this can be fixed or if another documentation system
can be used?
>
>
>>
>> >
>> ------------------------------------------------------------------------------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond. Discussions
>> > will include endpoint security, mobile security and the latest in malware
>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > _______________________________________________
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net <javascript:;>
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net <javascript:;>
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
