Message266159
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). |
|
Date |
User |
Action |
Args |
2016-05-23 15:52:19 | barry | set | recipients:
+ barry, rhettinger, r.david.murray, ethan.furman, berker.peksag, martin.panter, eryksun, leewz, jayvdb |
2016-05-23 15:52:19 | barry | link | issue26632 messages |
2016-05-23 15:52:19 | barry | create | |
|