"Don't rebind built-in names*" - it confuses readers

rusi rustompmody at gmail.com
Mon Jun 10 22:36:44 EDT 2013


On Jun 11, 5:14 am, Terry Jan Reedy <tjre... at udel.edu> wrote:
> Many long-time posters have advised "Don't rebind built-in names*.
>
> * Unless you really mean to mask it, or more likely wrap it, such as
> wrapping print to modify some aspect of its operation than one cannot do
> with its keyword parameters. The point for this post is that such
> wrapping modify or extend the basic meaning of the builtin, but do not
> abolish it.
>
> Reasons have been given in various related forms: 'my long experience
> tells me its bad', 'you may need the builtin later', 'you may forget
> that you rebound the builtin, 'it can lead to subtle bugs, etc.
>
> Leaving aside the code writer and code operation, I recently discovered
> that it is not nice for readers, whether humans or programs.
>
> For instance, open Lib/idlelib/GrepDialog.py in an editor that colorizes
> Python syntax, such as Idle's editor, jump down to the bottom and read
> up, and (until it is patched) find
>                      list.append(fn)
> with 'list' colored as a builtin. Stop. That looks wrong. List.append
> needs two arguments: a list instance and an object to append to the
> list. The 'solution' is in a previous line
>          list = []
> Reading further, one sees that the function works with two lists, a list
> of file names, unfortunately called 'list', and a list of
> subdirectories, more sensibly call 'subdirs'. I was initially confused
> and reading the code still takes a small bit of extra mental energy.
> Idle stays confused and will wrongly color the list instance name until
> it is changed. Calling the file list 'fnames' or 'filenames' would have
> been clearer to both me and Idle.
>
> --
> Terry Jan Reedy

Pascal introduced the idea of block structure -- introduce a name at
one level, override it at a lower level. [Ok ALgol introduced, Pascal
popularized].
This has caused more trouble than it has solved. And so languages
nowadays tend to 'protect' against this feature.

Here is Erlang's 'sticky' feature
http://books.google.co.in/books?id=Qr_WuvfTSpEC&pg=PA181&lpg=PA181&dq=erlang+sticky+directory&source=bl&ots=aLZCjwzUFb&sig=DQiiQgzHCt5EtE5H3WY3bCWh4eM&hl=en&sa=X&ei=gYu2UbD6DMOMrQeNh4HYDA&ved=0CEAQ6AEwAw#v=onepage&q=erlang%20sticky%20directory&f=false
that prevents a programmer from overriding a builtin module unless he
explicitly asks for that.



More information about the Python-list mailing list