Re: type-checking support in Python?

[Gabriel Genellina]

En Mon, 06 Oct 2008 11:19:58 -0300, Joe Strout <jo*@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/ar.../12/52989.aspx

--
Gabriel Genellina

[Steven D'Aprano]

On Tue, 07 Oct 2008 19:36:12 +1300, Lawrence D'Oliveiro wrote:

In message <ma************ *************** ***********@pyt hon.org>,
Gabriel Genellina wrote:

>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².

Isn't the right way to handle that to attach dimensions to each number?

This thread may be dead by now, but just for the record "dimensions " are
not "units". 1 inch and 1 kilometre have the same dimension (Length) but
obviously they can't be added to make 2 inches (or 2 kilometres).

On the other hand, dimensions are very handy for sanity results; if
somebody suggested to me that adding 15 inch second per gram to 195 cm
month per tonne gave 6.7 gallons per millgram hour, I don't even need to
do the conversion to see that this *must* be wrong because the dimensions
don't match: the original arguments have dimensions Length*Time/Mass but
the supposed argument has dimensions L**3/(M*T).

Dimensions are useful to check if quantities are compatible, but you
still need to convert them to a common unit.
--
Steven

[Arnaud Delobelle]

On Oct 7, 9:52*pm, Erik Max Francis <m...@alcyone.c omwrote:

I have a unit system module (unity) in progress as well (it's working
but it's as yet unreleased), but which takes a different approach which
I think has more promise. *Instead of having multiple united types
derived from different fundamental types, it has its own type Quantity
which takes two arguments: the amount and the units (which are further
data structures). *That way, the amount and the units are kept
separately and the unit system doesn't know anything specific about the
amount and only deals with the unit system. *Operations between
quantities enforce the type system (either combining the units for
operations like multiplication, or requiring that they be compatible for
operations like addition or comparison), and simply perform the
appropriate operations on the amount without enforcing any type. *This
allows you to have united operations on integers, floating point
numbers, decimals, vectors, matrices, quaternions -- whatever values you
may want to support units.

Mine is more of a dimensional analysis tool (as well as a general unit
converter) since it allows you to define a basis of units, then define
units within that basis and manipulate them -- thus it remembers the
definitions of all the units it has encountered. *You can define whole
new unit systems (e.g., c.g.s. vs. SI) and have them all relate to each
other, or even define brand new unit systems (e.g., man-day-widgets for
questions like, "If it takes one man three days to make two widgets, how
many widgets can five men make in two weeks?").

--
Erik Max Francis && [e-mail] m &&http://www.alcyone.com/max/
* San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
* *Those who forget the past are condemned to repeat it.
* * -- George Santayana

It's funny how many people have had the need for this! I have written
a module that seems to be very similar. It contains:

* A BasicDimension class whose objects are basis vectors in the
dimensions vector space.
* A Dimension class which is simply a vector in the dimension vector
space, which optionally can be named.

E.g.

distance = new_basic_dim(' distance', 'metre')
mass = new_basic_dim(' mass', 'gram')
time = new_basic_dim(' time', 'second')

speed = new_dim('speed' , distance/time)
accel = new_dim('accel' , speed/time)

area = new_dim('area', distance**2)
volume = new_dim('volume ', distance**3)

density = new_dim('densit y', mass/volume)

force = new_dim('force' , mass*accel)

Then:

>>volume/area
distance

>>speed*time
distance

* A Units class whose objects can registered with a dimension

* DObject class whose objects are just objects with a dimension. You
can do arithmetic with DObjects provided that you can do arithmetic
with their underlying objects.

>>s = Units(time, 1)
ms = Units(time, 0.001)
s.symbol = 's'
print DObject(2, s) + DObject(19, ms)

2.019 s

>>m = Units(distance, 1)
print DObject(3.0, m) / DObject(2.0, s)

1.5 [units distance*time**-1 1]

>>Units(distanc e/time, 1).symbol = 'm/s'
print DObject(3.0, m) / DObject(2.0, s)

1.5 m/s

>>print DObject(23.0, s).convert_to(m s)

23000 ms

* You can also have separate 'Dimensions systems', e.g. you can have
speed, force, time as basic dimensions instead of distance, mass, time
(IOW you have a different basis for the dimensions vector space).
Then you can convert DObjects between systems. Although this feature
is not working to my satisfaction.

I have designed this as part of a program to mark automatically online
maths/science worksheets, so speed is not really a consideration in my
implementation.

I have always thought of this as just a tool for my program, but I
suppose it can be seen as a sort of dynamic type checking system!

--
Arnaud

[Lawrence D'Oliveiro]

In message <01************ **********@news .astraweb.com>, Steven D'Aprano
wrote:

... just for the record "dimensions " are not "units".

Yeah, OK. "unit" = "dimensions " x "multiplier ".

Where "multiplier " can be arbitarily set to 1 for SI units.

[Lawrence D'Oliveiro]

In message
<1d************ *************** *******@q9g2000 hsb.googlegroup s.com>, Bas
wrote:

What they taught me as a physics undergrad is to always convert random
units given as input to SI units as soon as possible, do all your
calculations internally in SI units and (only if really needed)
convert back to arbitrary units on output.

If only NASA's Mars Climate Orbiter engineers had followed that rule. :)