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