On 06/27/2016 09:31 PM, Zachary Ware wrote:
On Mon, Jun 27, 2016 at 7:32 PM, Chris Angelico wrote:
If you're primarily worried about classes and functions, here's a neat
trick you can use:
__all__ = []
def all(thing):
__all__.append(thing.__name__)
return thing
Barry Warsaw has wr
On Mon, Jun 27, 2016 at 7:32 PM, Chris Angelico wrote:
> If you're primarily worried about classes and functions, here's a neat
> trick you can use:
>
> __all__ = []
> def all(thing):
> __all__.append(thing.__name__)
> return thing
Barry Warsaw has written a nice decorator called 'public'
On Tue, 28 Jun 2016 12:46 pm, Terry Reedy wrote:
> On 6/27/2016 6:29 PM, Pavel S wrote:
>
>> Frankly, do you always unit-test if __all__ works?
>
> One should. CPython's test suite includes test___all__. I believe it
> imports every stdlib module, looks for __all__, and if present, tests
> tha
On 6/27/2016 6:29 PM, Pavel S wrote:
Frankly, do you always unit-test if __all__ works?
One should. CPython's test suite includes test___all__. I believe it
imports every stdlib module, looks for __all__, and if present, tests
that it works. It probably executes 'from module import *'. A
On Mon, Jun 27, 2016, at 20:32, Chris Angelico wrote:
> If you're primarily worried about classes and functions, here's a neat
> trick you can use:
How about just
__all__ = [list of stuff including classes and functions]
__all__ = [x if isinstance(x, str) else x.__name__ for x in __all__]
--
htt
On Tue, Jun 28, 2016 at 11:55 AM, MRAB wrote:
> On 2016-06-28 01:32, Chris Angelico wrote:
> [snip]
>
>> If you're primarily worried about classes and functions, here's a neat
>> trick you can use:
>>
>> __all__ = []
>> def all(thing):
>> __all__.append(thing.__name__)
>> return thing
>>
>
On Tue, 28 Jun 2016 06:56 am, Pavel S wrote:
> Hi,
> I today uncovered subtle bug and would like to share it with you.
>
> By a mistake, I forgot to put comma into '__all__' tuple of some module.
> Notice missing comma after 'B'.
>
> # module foo.py
> __all__ = (
> 'A',
> 'B'
> 'C',
On 2016-06-28 01:32, Chris Angelico wrote:
[snip]
If you're primarily worried about classes and functions, here's a neat
trick you can use:
__all__ = []
def all(thing):
__all__.append(thing.__name__)
return thing
Err... won't that hide the 'all' builtin?
--
https://mail.python.org/ma
On Tue, Jun 28, 2016 at 6:56 AM, Pavel S wrote:
> By a mistake, I forgot to put comma into '__all__' tuple of some module.
> Notice missing comma after 'B'.
>
> # module foo.py
> __all__ = (
> 'A',
> 'B'
> 'C',
> )
>
> class A: pass
> class B: pass
> class C: pass
>
> If you try to im
On Mon, Jun 27, 2016, at 16:56, Pavel S wrote:
> Porposal: allow putting objects into __all__ directly, so possible
> problems will be found earlier:
Question: What happens if the object in __all__ isn't the same object
that's in the module?
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Jun 28, 2016 at 8:29 AM, Pavel S wrote:
>> but what about integers or strings?
>
> Can you provide example?
Sure. I'll spare you the wall of text that is os.__all__, but here's the types:
>>> import os
>>> {type(getattr(os, x)).__name__ for x in os.__all__}
{'bool', 'module', 'function',
> but what about integers or strings?
Can you provide example?
---
No matter if __all__ uses names or objects, I think it should be validated not
only when importing '*', but always.
Frankly, do you always unit-test if __all__ works?
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Jun 28, 2016 at 6:56 AM, Pavel S wrote:
> Porposal: allow putting objects into __all__ directly, so possible problems
> will be found earlier:
>
> # module foo.py
> class A: pass
> class B: pass
> class C: pass
>
> __all__ = (A, B, C)
>
> Note: this currently don't work.
>
from foo i
Emile van Sebille wrote:
On 5/11/2012 9:41 AM Ethan Furman said...
Style question:
Since __all__ (if defined) is the public API, if I am using that should
I also still use a leading underscore on my private data/functions/etc?
I would, even if only to alert any future maintainer of the intern
On 5/11/2012 9:41 AM Ethan Furman said...
Style question:
Since __all__ (if defined) is the public API, if I am using that should
I also still use a leading underscore on my private data/functions/etc?
I would, even if only to alert any future maintainer of the internal vs
exposed nature of t
Paul Woolcock wrote:
The gurus will have to correct me if this is not an accepted practice,
but I know some projects (Fabric is the one that comes to mind) will
define a submodule specifically for the 'from blah import *' situation.
The submodule would be called "api", or something like that, s
The gurus will have to correct me if this is not an accepted practice, but I
know some projects (Fabric is the one that comes to mind) will define a
submodule specifically for the 'from blah import *' situation. The submodule
would be called "api", or something like that, so you can do: 'from
mymod
Ethan Furman wrote:
> Greetings!
>
> Does anyone know/recall the original purpose of __all__?
To customise the names available for `from ... import *`:
http://docs.python.org/whatsnew/2.1.html#other-changes-and-fixes
> I had thought it was primarily to specify what would be imported when
> `f
[EMAIL PROTECTED] wrote:
> Andy> This a mm.py module:
> Andy> _all__=('getsize1',)
>
> Andy> size=85
>
> Andy> def getsize1():
> Andy> return size
>
> Andy> def getsize2():
> Andy> return 2*size
>
>
> Andy> I do not know why but getsize2 is not kept pr
Andy> This a mm.py module:
Andy> _all__=('getsize1',)
Andy> size=85
Andy> def getsize1():
Andy> return size
Andy> def getsize2():
Andy> return 2*size
Andy> I do not know why but getsize2 is not kept priviate?
That's not what __all__ is used for. Try
20 matches
Mail list logo
