[Python-Dev] Breaking undocumented API (original) (raw)

Łukasz Langa lukasz at langa.pl
Thu Nov 18 14:13:39 CET 2010

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

More information about the Python-Dev mailing list