type-checking support in Python?

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Tue Oct 7 01:49:27 EDT 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"  
by some.
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 [1]; the differences between both approaches are discussed here  
[2].
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.

[1] http://msdn.microsoft.com/en-us/library/Aa260976.aspx
[2] http://blogs.msdn.com/ericlippert/archive/2003/09/12/52989.aspx

-- 
Gabriel Genellina




More information about the Python-list mailing list