{merged stuff}
Date: Mon, 27 Mar 2006 23:45:14 -0800
From: Bob Miller <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Python] Re: [Eug-lug] Python help - more elegant way to do this...
...>
I've given up on this guideline. I use those words for local
variables when they're the most descriptive. Since the names are
statically scoped, and since I try not write functions more an 10-15
lines long, I don't see it as a significant concern.
...
Sure, I trust *you* know what you are doing.
But what if other people continue working on your code, or you have to
work on other people's code who left you with a function of 10 pages of
code, not 10 lines ?
Getting back to the original post,
http://www.euglug.org/pipermail/euglug/2006-March/006534.html
my comment was addressed to someone new to python, to be aware that an
identifier that sounds intuitive may be already 'taken' by builtins.
Beside, what's wrong about being more descriptive than using 'file': is
it a file name or a file handle, or is it an inStream or an outStream,
feeling more verbose, or more cryptic...(anything but the 'reserved' name)
So I stick to what I said: be aware of builtins functions and avoid
conflicts if you know better.
There is no price to pay for doing so.
- Horst
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
Over on that other list, horst wrote:
Naming a fileName 'file' is generally not a good idea: 'file' is a
function of the ever present "module" __builtins__ (actually more like a
constructor of an I/O handle). It replaced the more procedural sounding
'open' in version 2.2, about 3 years ago (if I remember correctly).
By doing so you are overriding the builtins function.
There are about two dozen, intuitive sounding identifiers, that collide
with __builtins__ , you want to stay clear off, like list, dict, map, min,
max,... To see those from within the interactive interpreter just say:
>>> dir(__builtins__)
I've given up on this guideline. I use those words for local
variables when they're the most descriptive. Since the names are
statically scoped, and since I try not write functions more an 10-15
lines long, I don't see it as a significant concern.
Besides, we get new builtins are coming every release. 2.5 introduces
"any" and "all". I wouldn't want to revisit all my existing code to
check for those names.
No, I am not asking to do so -- you'll figure out when things breaks.
If you are using a more descriptive naming scheme, and avoid common
terminology you just have to do less figuring out.
--
Bob Miller K<bob>
[EMAIL PROTECTED]
_______________________________________________
Python mailing list
[EMAIL PROTECTED]
http://www.euglug.org/mailman/listinfo/python
_______________________________________________
EUGLUG mailing list
euglug@euglug.org
http://www.euglug.org/mailman/listinfo/euglug
