Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10445 > unrolled thread

Is it bad practise to write __all__ like that

Back to article view | Back to comp.lang.python

Contents

  Is it bad practise to write __all__ like that Karim <karim.liateni@free.fr> - 2011-07-28 13:32 +0200
    Re: Is it bad practise to write __all__ like that Ben Finney <ben+python@benfinney.id.au> - 2011-07-28 21:52 +1000
    Re: Is it bad practise to write __all__ like that Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-07-28 14:29 +0200
      Re: Is it bad practise to write __all__ like that Karim <karim.liateni@free.fr> - 2011-07-28 15:00 +0200
      Re: Is it bad practise to write __all__ like that Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-28 12:01 -0600
        Re: Is it bad practise to write __all__ like that Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-07-29 08:37 +0200
          Re: Is it bad practise to write __all__ like that Karim <karim.liateni@free.fr> - 2011-07-29 11:54 +0200
      Re: Is it bad practise to write __all__ like that Erik Max Francis <max@alcyone.com> - 2011-07-28 22:22 -0700
      Re: Is it bad practise to write __all__ like that "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-29 18:49 +0000

#10445 — Is it bad practise to write __all__ like that

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

[toc] | [next] | [standalone]

#10446

Karim <karim.liateni@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

[toc] | [prev] | [next] | [standalone]

#10449

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

[toc] | [prev] | [next] | [standalone]

#10451

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

[toc] | [prev] | [next] | [standalone]

#10469

On Thu, Jul 28, 2011 at 7:22 AM, mark ferguson <markferg@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.

[toc] | [prev] | [next] | [standalone]

#10501

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

[toc] | [prev] | [next] | [standalone]

#10508

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

[toc] | [prev] | [next] | [standalone]

#10500

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 && max@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

[toc] | [prev] | [next] | [standalone]

#10533

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web