"_void" is better than "void" because it doesn't clutter up the
namespace by getting imported into the global namespace with
"from module import *" . ( or possibly conflict with some other
use of 'void' )
Given '_void' as a convention, I just dropped the suffix as
non-essential. :-)
>
> "Obviously" Python either needs a convention on how to do this, or a
> language construct to do it.
>
Was there supposed to be a smiley at the end of that sentence, or is
that what the quotes around "Obviously" mean, or are you hinting at
some other possible namespace conflicts produced by importing the
symbol void ? I think '_void' takes care of this problem, but maybe
I'm missing something.
Re: the 'import' thread: I don't have time to write the whole
( and hopefully thoughtful ) reply that that topic deserves, but
ONE feature I was considering is apropos to this discussion:
currently, import is the only way to create a module. In some of
my namespace experiments, I've kept a null file around to be
imported to be able to create an empty module, which could then
be modified. Maybe there should be a 'module' statement ?
I considered this once before, but I thought that since you
couldn't import this module by name, only as a side effect of
importing another module, ( or in the global scope, perhaps )
what's the use of it. But perhaps that IS the point - a way
of creating a sub namespace.
Currently, you can do this with a null class:
class FakeModule:
pass
_private = FakeModule()
_private.variable = []
_private.a = 'something'
but maybe it's worth spending the extra keyword for the extra clarity
of:
module _private:
variable = []
a = 'something'
[ ... ]
if _private.variable : ...
I'm assuming that an import statement is not required in the file
which contains the sub-module definition. But it would be
explicitly importable by: 'from topmodule import submodule' .
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics