output formatting for user-defined types

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sat Apr 8 03:36:38 EDT 2006


On Fri, 07 Apr 2006 21:18:23 -0700, Russ wrote:

>>>>>> dist = 4 * ft
>>>>>> print >> out, dist/ft
>>> 4
> 
>>> Note, however, that this requires the user to explicity ask for the
>>> conversion.
> 
>>How is this any more explicit and any less safe than:
> 
>>dist = 4 * ft
>>print float(dist)
> 
> Because the former specifies the actual units and the latter does not.
> If the base units were not feet, then the latter would not return the
> value in feet (which happens to be 4 here). It would return the value
> in whatever the base unit for length happened to be. So the former
> works even if the base unit is changed, but the latter does not.

So what you are saying is, if I enter a unit in feet, you automatically
change that unit to some base unit (say, metres if you use SI) behind my
back. So, assuming SI units as the base, if I say:

print 2*ft + 1*ft

you're going to give me an answer of 0.9144 metres, instead of the
expected 3ft. Surely if I'm entering my values in a particular unit, I
would like to see the answers in that same unit, unless I explicitly ask
for it to be converted?


> Secondly, allowing unconditional conversion to float allows any unit to
> be passed to trig functions. But any unit other than (dimensionless)
> radians passed to a trig function is an error. I explaned that already,
> but apparently you missed it.

I didn't miss that at all.

sin(45*ft) 

is still an error.

sin(45) 

shouldn't be, even if that 45 came from float(45*ft). What do you care
where the value comes from? I'm sure you allow sin(float('45')) without
complaining that trig functions don't operate on strings.


>>But in any case, I suspect you do automatically convert units. What do you
>>do in this case:
> 
>>x = 45*ft
>>y = 16*m
>>z = x+y
> 
>>Do you raise an error?
> 
> Nope. Works just fine. You obviously didn't look at the user guide.
> What happens is that any length unit is automatically converted to the
> chosen base unit for length, so everything is consistent.

So, despite your going on about the evils of automatic conversions behind
the user's back, you do go ahead and do automatic conversions behind the
user's back. 

Slight inconsistency, don't you think?


>>All you are doing is making a rod for your own back, to no advantage.
> 
> Wrong again.

Hey, it isn't *me* battling to find a way to easily print my instance
objects. 



-- 
Steven.




More information about the Python-list mailing list