Am 18.11.2010 13:48, schrieb Michael Foord:
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly
sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d put open in __all__.
"import *" would then override the builtin open. A good reason not to
use "import *" I guess, but also a good reason not to create names that
shadow builtins.
Heh. Instead have fun with io.ioopen(), gzip.gzipopen(),
webbrowser.webbrowseropen(), etc.? We do have namespace support for
a reason.
Or urllib2.urlopen, oh wait - that's real...
If I was importing from those namespaces I probably *would* import and
rename to have unambiguous names (and you would *have* to if there was
any possibility of you using the builtin open). io.open is arguably an
exception to this as it does the same as the builtin open...
Using meaningful names is *good*. This is a reason I dislike modules
that just call their base exception class "Error". You *have* to use
it from the namespace (or import with import as and give it a good
name) for it to have any meaning.
Guys, I may agree or disagree with these statements but we are drifting
towards "opinion" versus "solid, well understood practice". Let's focus
on the subject.
For the matter, "import *" is a discouraged mechanism anyway, let alone
the rare exceptions where its usage is valid. If you use star-imports
and you don't know what you're doing, you might just as well hurt
yourself in other ways than just by "open".
Maybe we should just sum up the discussion somewhere already. Keeping up
with a thread reaching a megabyte in size is starting to be painful.
Best regards,
Łukasz
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com