[Python-Dev] Convention on functions that shadow existing stdlib functions (original) (raw)
Brett Cannon brett at python.org
Tue Jul 26 02:34:33 CEST 2011
- Previous message: [Python-Dev] Convention on functions that shadow existing stdlib functions
- Next message: [Python-Dev] Convention on functions that shadow existing stdlib functions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Jul 23, 2011 at 20:35, Eli Bendersky <eliben at gmail.com> wrote:
Some background: I'm working (on and off) on issue 11015 - documenting the public functions in test.support
Some of the functions in test.support (for example unlink, rmtree) simply shadow existing & popular stdlib functions, with the aim of swallowing the exceptions these may throw. This is confusing, IMHO. For example, grepping 'unlink' on Lib/test/test*.py files doesn't say much about which unlink is being used. A couple of options to handle this are: 1. Remove these functions altogether, trying to use existing constructs (such as the ignoreerrors parameter in rmtree). 2. Adapt a naming convention for such functions, for instance rmtreesilent and unlinksilent (or a similar convention, if one exists) Opinions?
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110725/de04e5b4/attachment.html>
- Previous message: [Python-Dev] Convention on functions that shadow existing stdlib functions
- Next message: [Python-Dev] Convention on functions that shadow existing stdlib functions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]