[Python-Dev] Convention on functions that shadow existing stdlib functions
Steven D'Aprano
steve at pearwood.info
Thu Jul 28 01:53:21 CEST 2011
Eli Bendersky wrote:
> Sure, but I'm still leery of two functions with the same name doing acting
> slightly differently.
and then in a later post:
> As I mentioned elsewhere, it's not good practice to have two functions with
> the same name doing something slightly different, in different modules in
> the code-base.
artist.draw() and gunslinger.draw() do not necessarily need to do the
same thing, and I don't agree that a (futile) preference for globally
unique names is good practice: it can lead to unnecessarily long names
(artist.draw_with_pencil_on_paper) or redundant characters prefixing the
name (itertools.imap -- what does the "i" in imap tell you that the
itertools didn't already?). Solving this problem is what namespaces are for.
Renaming test.support.ulink to something else doesn't fix the problem of
unsupported support functions being used in third-party code. It may
even *encourage* it, by making the extra functionality more explicit.
However, is there any reason why test.support itself shouldn't be
renamed test._support, or possibly _test.support, so that the *entire*
suite is marked as a private implementation detail?
--
Steven
More information about the Python-Dev
mailing list