On Wed, May 30, 2012 at 10:33 AM, Kai Huuhko <kai.huu...@gmail.com> wrote:
> 2012/5/30 Davide Andreoli <d...@gurumeditation.it>:
>> 2012/5/29 Kai Huuhko <kai.huu...@gmail.com>:
>>> 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.
>
> 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.
>
> 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.
I'm not against having only the property functions, but it will make
it more difficult to find a giving python API/property once you know
what you want from the C API.
Additionally, if this change is done, it's important that it is done
across all the python bindings, not only elementary, to avoid
inconsistent API.
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
------------------------------------------------------------------------------
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
