This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author barry
Recipients barry, berker.peksag, eryksun, ethan.furman, jayvdb, leewz, martin.panter, r.david.murray, rhettinger
Date 2016-05-23.15:52:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On May 23, 2016, at 02:43 PM, Franklin? Lee wrote:

>I sometimes wrap functions that return iterators to make functions that
>return lists, because I work on the interpreter a lot. From there, it's not
>much of a stretch to imagine functions which are implemented as decorated
>versions of other functions.
>If @public were only to be used as a decorator, it would not be possible to
>have `public` called on a function outside of its definition. But someone
>might call `public(some_decorator(some_function))`.

Do you mean, they'd call this is some module other than the one some_function
was defined in?  I don't know that this is a use case we even want to support.

>(@public is really a macro, if you think about it.)

That's true in a sense.  It doesn't change the decorated thing at all.  I
think it's important to keep in mind that @public isn't the only way to add to

>>It would be possible.  
>(I meant, is it possible for someone to have a non-list __all__?)

Yes.  I've seen existing code where __all__ is assigned to a tuple.

>If the `.append` fails, I think there should be a meaningful error. Perhaps
>"'__all__' is not a list."

You should get something like:

AttributeError: 'tuple' object has no attribute 'append'

which seems pretty obvious.

>I'm thinking of the people who don't read docs and are coming from other
>languages. They'd put `@public` over their method, and one day they'd `import
>*` from that file (whereas they used to only import explicitly), getting an
>error about a name not being defined in their module. "But why would that
>name need to be defined? It's a method."
>Or worse, the name of the method just happens to be the same as something in
>some other file, so they'll focus on why that NAME is being expected in THIS

Well, consenting adults and all.  I'm not sure we need to protect ourselves so
strictly against people who don't read the docs and don't understand Python
(i.e. random cargo-culters).

>>Also, I know that I have several cases where constants are actually
>>instances.  They could be marker objects like::
>>    MARKER = object()  
>(Here's food for thought: A MARKER could be a one-element enum, both
>conceptually and by implementation. Just like how the "bool enum" is
>{True,False} and the "None enum" is {None}.)

Sure.  I don't think that changes anything here though.  Down the line, it
might be an interesting idiom to experiment with (you can probably start with
the standalone enum34 module).
Date User Action Args
2016-05-23 15:52:19barrysetrecipients: + barry, rhettinger, r.david.murray, ethan.furman, berker.peksag, martin.panter, eryksun, leewz, jayvdb
2016-05-23 15:52:19barrylinkissue26632 messages
2016-05-23 15:52:19barrycreate