Barry A. Warsaw added the comment:
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
__all__.
>
>>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
>file.
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).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
