type-checking support in Python?
gagsl-py2 at yahoo.com.ar
Tue Oct 7 07:49:27 CEST 2008
En Mon, 06 Oct 2008 11:19:58 -0300, Joe Strout <joe at strout.net> escribió:
> Finally, one thing I've considered is adopting some identifier prefixes
> indicating type. Maybe "iFoo" for integer, "fFoo" for floating-point
> numbers, "d" for dictionary, "l" for list, "t" for tuple, "o" for
> object, and "v" for variable types that may be more than one of the
> above. I gather (from just a couple days of browsing) that such a
> naming convention isn't common in the Python community, but is there
> anyone else here who does it? I'd rather adopt an existing standard
> (even if it's not widely used) than make one up.
Apart from the wise words that others have said, I'd add that I see no
point in identifier prefixes when they merely indicate "type" (in the
Python sense or even a broader sense) - called "system Hungarian notation"
In contrast, the prefix used in "apps Hungarian notation" declares the
"kind" or "intent" of the variable, and it may be useful in some cases.
This appears to be the original intent of Charles Simonyi when he wrote
his paper ; the differences between both approaches are discussed here
As an example, in the oil industry here in my country there is a mix of
measurement units in common usage. Depth is measured in meters, but pump
stroke in inches; loads in lbs but pressures in kg/cm². So it's important
to keep track of which unit some variable represents - its type would be
always float, and that carries no information; but its unit *is* important
informacion, so I sometimes use a postfix to indicate that.
Variable names should be *meaningful* - before automatically sticking an
"f" or "i" or "m_" prefix to something, think what you gain from it. If
you always represent a street address using a string in your application,
"szAddress" (or "sAddress") don't give you any more information than
"address" alone, so the prefix is useless.
More information about the Python-list