Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
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. -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/30 Kai Huuhko kai.huu...@gmail.com: 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. I have 2 applications written in py, one is 1 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. -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/30 Rafael Antognolli antogno...@profusion.mobi: 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. With good documentation there will be little to no need for looking things up from C api. We should improve the py-elm docs and preferably get them online. 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. I agree. -- 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 -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
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 1 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 -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
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 1 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/30 Kai Huuhko kai.huu...@gmail.com: 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 1 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? 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. 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/30 Davide Andreoli d...@gurumeditation.it: 2012/5/30 Kai Huuhko kai.huu...@gmail.com: 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 1 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? 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
On Wed, May 30, 2012 at 4:53 PM, Kai Huuhko kai.huu...@gmail.com wrote: 2012/5/30 Davide Andreoli d...@gurumeditation.it: 2012/5/30 Kai Huuhko kai.huu...@gmail.com: 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 1 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/30 Rafael Antognolli antogno...@profusion.mobi: On Wed, May 30, 2012 at 4:53 PM, Kai Huuhko kai.huu...@gmail.com wrote: 2012/5/30 Davide Andreoli d...@gurumeditation.it: 2012/5/30 Kai Huuhko kai.huu...@gmail.com: 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 1 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 Packing args in a tuple is cheating! But it's not instantly clear what needs to be passed to it like in the set function (well in this case it almost is but some have more complexity than this example). If we were to remove the get/set functions in multi-arg cases we should add a docstring describing the args. So let's get the docs in order. Epydoc parses evas with lots of warnings but it seems to get everything in there. We do need to get doc generation working properly for py-elm. 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
* Kai Huuhko kai.huu...@gmail.com [2012-05-29 23:33:19 +0300]: 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. For these 1 arg only setters, if we have them duplicated under property and direct call, it's way to go to have only the property. BR, -- 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 -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
On Tue, May 29, 2012 at 10:40 PM, Gustavo Lima Chaves gl...@profusion.mobi wrote: * Kai Huuhko kai.huu...@gmail.com [2012-05-29 23:33:19 +0300]: 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. For these 1 arg only setters, if we have them duplicated under property and direct call, it's way to go to have only the property. BR, I agree. Using properties is much more the python way. -- Boris Faure -- 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
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 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 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
Re: [E-devel] python-elementary RFC: Using python properties instead of duplicating them with the get/set functions
2012/5/29 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 davemds PS: this is what I'm doing on geany (the editor I use) to solve your problem :D https://github.com/DaveMDS/geany/commit/c7035d58f2b8b50df96e9cd9fbf6f9e73ec2ce74 -- 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
