Re: Is it bad practise to write __all__ like that
Am 28.07.2011 20:01 schrieb Ian Kelly: The advantage of Thomas's decorator here is that it lets you place the denotation of whether a function is exported alongside its definition, whereas simply declaring the __all__ list forces you to separate them. It also avoids the problem of possibly mistyping the function's name in the list. Thank you. For the ones who do not like @__all__ because it might look ugly, here is an alternative: __all__ = [] def export(obj): __all__.append(obj.__name__) return obj It is nearly the same, but without an extra class and with the more readable @export def func(): pass Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
Thomas, A ha! Now I feel all warm and fuzzy inside. It's nice to start the day with learning something new. To be honest, the initial problem was that I didn't understand the meaning of '__all__', again probably from not working in the large with python. After posting, I went and had another go at understanding decorators. I think your second decorator example is the neatest one I have seen and it is quite obvious where the value of the decorator here is. You have used a minimal amount of code to solve a potentially major long term code maintenance problem. I will echo Karim here, a very elegant solution. On 29 July 2011 07:37, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 28.07.2011 20:01 schrieb Ian Kelly: The advantage of Thomas's decorator here is that it lets you place the denotation of whether a function is exported alongside its definition, whereas simply declaring the __all__ list forces you to separate them. It also avoids the problem of possibly mistyping the function's name in the list. Thank you. For the ones who do not like @__all__ because it might look ugly, here is an alternative: __all__ = [] def export(obj): __all__.append(obj.__name__) return obj It is nearly the same, but without an extra class and with the more readable @export def func(): pass Thomas -- http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
On 07/29/2011 08:37 AM, Thomas Rachel wrote: Am 28.07.2011 20:01 schrieb Ian Kelly: The advantage of Thomas's decorator here is that it lets you place the denotation of whether a function is exported alongside its definition, whereas simply declaring the __all__ list forces you to separate them. It also avoids the problem of possibly mistyping the function's name in the list. Thank you. For the ones who do not like @__all__ because it might look ugly, here is an alternative: __all__ = [] def export(obj): __all__.append(obj.__name__) return obj It is nearly the same, but without an extra class and with the more readable @export def func(): pass Thomas I did not plan that this topic introduce so many great ideas. It started from a simple question and ended up with new and beautiful solution. Very pleased of the collective spirit of this mailing list. It changed from non-sense verbal fightings I saw earlier in some discussions like perl versus python related topic. Karim -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
Thomas Rachel wrote: class AllList(list): list which can be called in order to be used as a __all__-adding decorator Wow, this is a great idea. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
Karim karim.liat...@free.fr writes: Hello, __all__ = 'api db input output tcl'.split() or __all__ = api db input output tcl .split() Maybe this: __all__ = [x.__name__ for x in [ api, db, input, output, tcl, ]] presuming these are all objects with an accurate ‘__name__’ attribute. I'm starting to yearn for the ability in Python to get a string representation of a name itself, by using the name and not writing it as a string literal. That would make the above more robust. But really, this is all obfuscatory. Why not: __all__ = [ 'api', 'db', 'input', 'output', 'tcl', ] It's clear and explicit and really not difficult to type or maintain. -- \ “I do not believe in forgiveness as it is preached by the | `\church. We do not need the forgiveness of God, but of each | _o__)other and of ourselves.” —Robert G. Ingersoll | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
Am 28.07.2011 13:32 schrieb Karim: Hello, __all__ = 'api db input output tcl'.split() or __all__ = api db input output tcl .split() for lazy boy ;o). It is readable as well. What do you think? Why not? But you could even do class AllList(list): list which can be called in order to be used as a __all__-adding decorator def __call__(self, obj): for decorators self.append(obj.__name__) return obj __all__ = AllList() @__all__ def api(): pass @__all__ def db(): pass @__all__ def input(): pass @__all__ def output(): pass @__all__ def tcl(): pass HTH, Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
On 07/28/2011 02:29 PM, Thomas Rachel wrote: __all__ = AllList() Hello Thomas, Very beautiful and elegant code. Having both at the same time an instance and a method... With this 'small' topic, you taught me something today on property application! Cheers Karim -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
HI Thomas, I've not really got the hang of decorators yet, so I was wondering why one might use your approach rather than just using Karim's original method? I only really use python for smallish, utility programs, so I suppose I haven't come across an issue complex enough to see a clear advantage in using decorators. I'm still looking for that 'a ha!' moment when it all becomes clear to me. Could it be that simple examples of decorators end up being overkill for the problem they are solving, elegant though the code may be? For anyone else, what was itch that decorators solved, such that they became an additional tool in the their kit bag? On 28 July 2011 14:00, Karim karim.liat...@free.fr wrote: On 07/28/2011 02:29 PM, Thomas Rachel wrote: __all__ = AllList() Hello Thomas, Very beautiful and elegant code. Having both at the same time an instance and a method... With this 'small' topic, you taught me something today on property application! Cheers Karim -- http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
On Thu, Jul 28, 2011 at 7:22 AM, mark ferguson markf...@gmail.com wrote: I've not really got the hang of decorators yet, so I was wondering why one might use your approach rather than just using Karim's original method? The advantage of Thomas's decorator here is that it lets you place the denotation of whether a function is exported alongside its definition, whereas simply declaring the __all__ list forces you to separate them. It also avoids the problem of possibly mistyping the function's name in the list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it bad practise to write __all__ like that
Thomas Rachel wrote: Why not? But you could even do class AllList(list): list which can be called in order to be used as a __all__-adding decorator def __call__(self, obj): for decorators self.append(obj.__name__) return obj __all__ = AllList() @__all__ def api(): pass @__all__ def db(): pass @__all__ def input(): pass @__all__ def output(): pass @__all__ def tcl(): pass Bravo! -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Jabber erikmaxfrancis Smaller than the eye can see / Bigger than the mind can conceive -- India Arie -- http://mail.python.org/mailman/listinfo/python-list
