[Python-Dev] Convention on functions that shadow existing stdlib functions (original) (raw)

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