Fun with numbers - dammit, but I want a cast!

[Bengt Richter]

On Mon, 11 Aug 2003 14:38:24 GMT, Alex Martelli <aleax at aleax.it> wrote:

>Graham Nicholls wrote:
>   ...
>>> xscale = xframe / float(img_x)
>> 
>> Thats what I wanted to do, but was sure I'd read that python didn't have
>> casts, and that _looks_ like a cast to me!
>
>Well, Python surely has the ability to create new objects, and the most
>typical way to do that is to call a type, possibly passing it, as the
>call's arguments, the value[s] that direct the new object's creation.
>
>
>So, for example, if you have a string S and want to create a list L
>whose items are the string's characters, you typically code:
>
>L = list(S)
>
>
>Similarly, if you have a number N and want to create a float F whose
>value is the floating-point equivalent of N's value, you code:
>
>F = float(N)
>
>
>Whether these are "casts" is, I guess, a pretty moot issue.  Me, I'd
>call them "type calls" (or "explicit constructor calls" if I were in a C++
>mood:-), reserving the terminology "cast" for the C/Java notation:
>
>    (sometype)somevalue
>
>or the C++ notations of forms such as:
>
>    static_cast<sometype>(somevalue)
>
>But, of course (in C++), explicitly calling a costructor of (e.g.) float,
>with an integer argument; or statically casting an int to float; or even
>using the old C-ish "prepended type in parenthesis" notation; have much
>the same effect in most contexts.  As long as you're quite clear that
>what you're actually doing is "create a new value of a specified type
>by calling the type with suitable argument[s]", rather than (the typical
>idea of "cast") "reinterpreting an existing value AS IF it was of some 
>other type rather than of the type it actually is", it may not be a
>problem if you like to call the operation "a cast".
>
<nit>I'd prefer adding the [] items in that last, to make it clear that a
reinterpreting cast is about representations, not about the associated
abstract values. I.e.,

 "..., rather than (the typical idea of "cast") "reinterpreting an existing [representation of a]
  value AS IF it was [a representation] of some other type rather than [being a representation]
  of the type it actually is", ..."
</nit>

One of the things I like about Python is the apparent motivation to unify according to what
makes sense with the abstract aspects of represented values (even though it may sometimes take
some getting used to if one has been steeped in representational details for decades).
E.g., one might find

 >>> [{1:'one'}[k] for k in [1, 1.0, 1L, 1e0]]
 ['one', 'one', 'one', 'one']

surprising at first ;-)

Interesting also the way the initial key's representational type is retained
even when an abstract-value-as-effective-key is used to change the
associated value:

 >>> d = {1.0:'one'}
 >>> d[1]
 'one'
 >>> d
 {1.0: 'one'}
 >>> d[1] = 'integer one'
 >>> d
 {1.0: 'integer one'}
 >>> d[1], d[1.0]
 ('integer one', 'integer one')

And of course true division goes in the same direction.

Regards,
Bengt Richter