[Python-Dev] Convention on functions that shadow existing stdlib functions

[Brett Cannon]

On Wed, Jul 27, 2011 at 16:53, Steven D'Aprano <steve at pearwood.info> wrote:

> 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?
>

Technically no for the _test idea, although it would promote the idea of not
shipping Python with its tests, which would be a shame as it's hard enough
to get people to run them. Renaming test.support is much more acceptable,
just more work considering how many times that module is used in the test
suite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110728/11e63964/attachment.html>