Zope/DTML Infuriating...

[Michael Torrie]

Jens wrote:
> - Why is it, when primitive data types seem to be objects (similar to
> javascript), that type casting is done through build-in functions
> rather than methods, e.g. String.toInt('5') or '5'.toInt() or x =
> Integer.fromString('5').

Mainly because it's much cleaner to do it the python way (absolutely
explicit), and just as clear or clearer what you are intending to do.
Digging a little deeper, you'll find that the built-in function "str,"
for example, actually calls object.__str__().  This is nice because it
allows any object class to define that method and have it work with
str() in a manner consistent across python.  It preserves some amount of
uniformity.

The second example, x = Integer.fromString('5') demonstrates a huge
weakness in Java.  In python, rather than asking an integer object to
convert from a limited selection of other objects, python works the
other way, asking objects to convert themselves to integers (if they
can).  We don't worry about the size of integers, since python's
integers are auto-sizing.  So any object that implements the __int__()
method can be used with the classic "int()" built-in function.  The same
goes for __float__ and float().

Little things like this really make me happy about how python does
things generally.  I think much of how Java works with Integer and
String (as you describe above) is because Java has primitive types
(which aren't objects at all) and then boxed objects around the
primitive types.  Python eliminates this idea, and makes everything,
even "simple" types objects.

Now sure python could just say always call the "int()" or "float()" or
"str()" method on objects to produce those respective conversions.  But
using a combination of a built-in language function and a specialized,
reserved class method name, allows a lot of flexibility without
infringing on the programmer's need to use method names like "int,
float, or str" if he or she so desired.