[Python-Dev] Breaking undocumented API

[Łukasz Langa]

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