Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the g

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Wed, May 30, 2012 at 4:53 PM, Kai Huuhko <kai...@gm...> wrote:
> 2012/5/30 Davide Andreoli <da...@gu...>:
>> 2012/5/30 Kai Huuhko <kai...@gm...>:
>>> 2012/5/30 Gustavo Sverzut Barbieri <bar...@pr...>:
>>>> On Wednesday, May 30, 2012, Davide Andreoli wrote:
>>>>
>>>>> 2012/5/30 Kai Huuhko <kai...@gm... <javascript:;>>:
>>>>> > 2012/5/30 Davide Andreoli <da...@gu... <javascript:;>>:
>>>>> >> 2012/5/29 Kai Huuhko <kai...@gm... <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.
>>
>> so you want property for functions with 1 arg and xxx_set/get() for
>> those with more arguments ?? isn't this confusing?
>
> Do properties actually work with more than one argument?

Yes, look at the geometry property of evas objects bindings:
http://trac.enlightenment.org/e/browser/trunk/BINDINGS/python/python-evas/evas/evas.c_evas_object.pxi#L436

> I actually started learning programming properly with the EFL (and
> Telepathy) python bindings, and for me the most confusing thing about
> them were the lack of documentation, the fact that it was generally
> out of sync with C api, had many deprecated methods, and the
> get/set/property duplication.
>
> So in my newbie opinion, having the get/set functions OR a property
> for a single functionality, would be the most clear way to learn and
> use the api.
>
> All I wanted to do was to write applications but here I am, trying to
> improve the tools that I've been given. ;-)
>
>>
>>>
>>> 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
>>
>> this is the like it is done now:
>> implementation in the set/get functions and wrapped in the properties,
>> you want the opposite? I'm ok if you want to swap this...but really
>> cannot see a reason.
>
> What I mean is that these wrappers would be external from the python api.
>
>>
>>
>>>
>>> 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.
>>
>> Totally agree, it's the reason I put "doc:TODO" on every widget
>> name in the .pxd  :)
>>
>>> 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?
>>
>> never tryed, but gustavo had a generated version online somewhere...
>> so the generation should work.
>>
>> Note: there are also some pages in the wiki about the py bindings, with example
>> and other stuff. Another work to do is to keep those pages updated :(
>> http://trac.enlightenment.org/e/wiki/Python
>>
>> bye
>> davemds
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> >
>>>>> ------------------------------------------------------------------------------
>>>>> > 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
>>>>> > enl...@li... <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
>>>>> enl...@li... <javascript:;>
>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Gustavo Sverzut Barbieri
>>>> http://profusion.mobi embedded systems
>>>> --------------------------------------
>>>> MSN: bar...@gm...
>>>> 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
>>>> enl...@li...
>>>> 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
>>> enl...@li...
>>> 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
>> enl...@li...
>> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi

Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the g

Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions