Python Worst Practices

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat Feb 28 01:36:44 EST 2015


Dan Sommers wrote:

> On Sat, 28 Feb 2015 12:09:31 +1100, Steven D'Aprano wrote:
> 
>> There's no harm in calling a local variable "id", if you don't use the
>> built-in id() inside that function. That's one of the reasons why
>> functions exist, so that the names you use inside a function are distinct
>> from those outside.
> 
> And thank goodness for that!  I've been writing Python code since 1997
> and version 1.5.<something>,¹ and I still do a double take when emacs
> colors all my ids that faint blue that means "builtin."

Although it is not helpful for people using screen-readers, and may be of
limited use to the colour-blind, I am in favour of colourising built-ins so
they stand out.

On the other hand, I recall seeing an editor which rejected the idea of
colour-coding built-ins, keywords etc., instead it coloured your own
variables. So given:

    spam = 23
    eggs += cheese*len(sausage)


spam, eggs, cheese and sausage would be different colours. The idea being,
when scanning a large code base, all the places that use a specific
variable would stand out ("just look for the dark green word").



> I don't think I've ever used the builtin function id in a program.
> Ever.  Not even once.  Honestly, what is a valid use case? 

Here's one. I think it's the only time I have seen id() used apart from
interactive experimentation:

https://code.activestate.com/recipes/577504



> That said, I 
> do have boatloads of parameters and objects locally named id because
> it's idiomatic (at least to me) and mnemonic (at least to me) and just
> as meaningful.
> 
> ¹ No, not continuously.  I have eaten and slept since then.

Slacker!



-- 
Steven




More information about the Python-list mailing list