RetroSearch Browse

Thu Jul 28 01:53:21 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-July/112597.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-July/112597.html below:

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