Is it bad practise to write __all__ like that

[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?

Cheers
Karim

 

[Thomas Rachel]

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

 

[Karim]

__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

 

[Ian Kelly]

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.

 

[Thomas Rachel]

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

 

[Karim]

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

 

[OKB (not okblacke)]

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