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

[Joshua Landau]

On 11 June 2013 01:14, Terry Jan Reedy <tjreedy at udel.edu> wrote:
> Many long-time posters have advised "Don't rebind built-in names*.
>
> 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.

The problem here is the problem with all of this - names should be
descriptive. There is rarely a case where "str" or "string", even, is
sufficiently detailed, and "file" often really refers to a "path" for
example.

You should really not worry about shadowing builtins because if you're
using sufficiently long names you almost ne'er accidentally will. In
one of my recent posts I was chastised by someone (I remember not who)
for overwriting the "property" builtin - obviously this would *never*
happen in real life. If you call your property "property" you are a
fool. It means nothing!

Secondly, shadowing will _almost never_ be a problem, as you
invariably, given that you don't use "list" or "str" as variable
names, will have shadowed a completely contextually useless variable.
And thus, in the one-in-a hundred-in-a-thousand chance that you
accidentally shadow a builtin that happens to be important, you can
assume that your editor has a half-decent variable replacement
mechanism - it's only shadowed in a single scope!

----

But enough of that, you asked about syntax highlighting.

Personally, the current method is good - it reminds you when you are
shadowing, but does it gently. If you're adamant that the most
sensible name for your variable is "format", use it. The highlighting
shouldn't be taken to mean "this is from __builtins__", but a little
reminder that __builtins__ uses the name. Chances are, you won't be
using "format", so do. The little colour change, though, reminds you
to check that it really is the best name.

Or, well, do what I do and use a proper editor, and set syntax not to
highlight keywords if you care enough. My editor makes a good choice
only to highlight those keywords that you really don't want to shadow
- list, str, etc. - where they're just too vague to be good variable
names. "Format"'s unusual and as such do what you want with it.