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

Eli Bendersky eliben at gmail.com
Wed Jul 27 15:14:40 CEST 2011


>
>
>
> The mere fact that these functions exist in a different module suggests
> different semantics from those found in other places in the stdlib. I don't
> think they should be renamed simply because some code imports the functions
> directly instead of the module itself (suggesting they should be doing the
> latter over the former). Now if the functions are redundant that's something
> else entirely and removal should be fine.
>

I will try to clarify my concern.

Documented functions from test.support currently appear in the global index
of the Sphinx-generated documentation. Suppose we document test.support's
"unlink". Now the index entry for "unlink" will contain two "unlink"
references (*), with slightly different semantics - one in os and another in
test.support

Will it take long for newbie code to appear with the test.support version?
Not to mention that grepping code that imports the "unlink" function
directly doesn't reveal which one is being used.

I think this is troublesome. I think at least two separate actions are
required here:

1. In the documentation of test.support mention explicitly that it's code
for CPython's internal use only, and these APIs aren't guaranteed to be
stable.
2. Some functions like unlink and rmtree are obviously redundant, and shadow
frequently used Python stdlib functions, so I would either kill them
completely or at least rename them appropriately.

Eli


(*) Actually, three, since there's also xml.dom.minidom.Node, but that's
obviously unrelated).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110727/2264777a/attachment.html>


More information about the Python-Dev mailing list