Getting started

Steve Holden sholden at
Wed Sep 25 09:12:54 EDT 2002

"James J. Besemer" <jb at> wrote in message
news:mailman.1032567390.29374.python-list at
> Alex Martelli wrote:
> >$a = "2.3";
> >$b = 45;
> >print $a+$b;
> >
> >emitting 47.3 is pretty close to what I consider "weak typing".
> >
> I don't see why you call this "weak typing".  In Perl, the "+" operator
> is defined to work with strings or numbers.

Well, it seems pretty weak to me that the *operator* has to examine the
types of its arguments in order to know which operation to perform. Can we
say polymorphism?

>                                                          It may seem more
> at first if you expect "+" also to be the string concatenation operator,
> which it is not.  In the above example,
>     print $a . $b;
> will print the string "2.345".
How very intuitive. I am happy to say I have now forgotten enough Perl for
this to seem totally unreasonable. I usually don't say these things about
Perl because it, too, is a pragmatist's language, and Perl is fine for the
things Perl is fine for. If it's working for someone I can't in all
conscience disturb their busy working day to suggest they rewrite it all in

> This all is no different in principle from Python's:
>     a = 2.3
>     b = 45L
>     print a + b
> and getting 47.3.  The "+" operator is defined for floats and also for
> longs.  Since they're all "numbers" it would seem really strange if they
> did not interact naturally like this.  But fundamentally they're
> distinct types as "type( 2.3 )" and "type( 45L )" illustrate.
It seems very different to me. For example, how does the Perl "+" operator
find out about a new addable type? Is Perl even able to integrate its
intrinsic data objects with user-defined types? Can we say inheritance
hierarchy? In Python it's easy to define methods to integrate your own
classes into the language's architecture. I could never discern enough
architecture in Perl to see how to do that, though I willingly accept that
this deficiency might be in me rather than in Perl.

> Perhaps an even better example is the "*" operator:
>         print  2  * 5     # integer x integer -> integer
>         print [2] * 5     # list x integer -> list
>         print "2" * 5     # string x integer -> string
> This all makes sense even though radically different results and result
> types are produced each time.  It's not "weakly typed" but rather
> strong, dynamic typing.  The outcome is completely determined by the
> operator and the types of the operands and there is no way to break the
> rules.  Since we know Python is strongly typed then it follows that your
> Perl example must be also.

Not really. Python has strongly-typed data with late binding of methods and
operators. This is an organised way to obtain the results you have so far

> Anyway, why should "2" + 5 == "7" be all that much stranger than "2" * 5
> == "22222"?  If the operation is unambiguous and useful what rule would
> it break?  Personally, I think Python would be improved slightly by
> adding this conversion.  It's convenient and there's ample precedent in
> other languages (Awk, Snobol, Icon, Perl, etc.).  But I am sure that
> notion will provoke howls of protest from the True Believers.
Not at all. If I thought such a suggestion would be taken seriously I might
go so far as to advise against that, but I don't see this being a religious

> There are a lot of reasons why Python is better than Perl but strongly
> vs. weakly typed is not one of them.  I don't see a material difference
> in the "strength," per se, of typing between Perl and Python.  They're
> both "strong" and "dynamic", though Python's type model is better
> thought out, particularly since object/type unification.
[C/Fortran irrelevancies]
> These types of errors are not possible in Python or Perl, which
> illustrates that they're both "strong".
For some meaning of strong, I suppose, but please don't bother to define
what this is.

> Curiously, in Python
>     print "%s" % 2.5
> prints the string "2.5" instead of, say, raising an exception.  So
> there's some small precedent for treating numbers as strings in a string
> "context" even in Python.
Well, considering that the %r and %s conversion types are currently
documented as

r String (converts any python object using repr()).
s String (converts any python object using str()).

it should hardly be surprising that conversions take place. Such
conversions, however, are not intrinsic to the *language*, but to the *data*
(where the type is significant) - Python goes so far as to expose explicitly
how the conversions are performed, and they will clearly work for any object
with a suitable (returns a string) __repr__() and/or __str__() method. Just
to clarify the nature of this, try

    "%6.2f" % 2.6

and then try

    "%6.2f" % "2.6"

and we'll see if you still feel that string formatting 'treats numbers as
strings in a string "context"'.

By contrast Perl seems a little muddled, and I personally think it's no
accident that Wall's own writing tends to stress the significance of
*context*. The rules are quite explicit in Python, clouded in Perl. Of
course you must take this as a dim memory frmo one who never claimed to
understand Perl that well in the first place (I used to program Perl, but
I'm all right now ;-).

> I'll go out on a limb and say that most "dynamic typed" languages are
> also "strong" by necessity.  If the user isn't keeping track of the
> types then the system HAS to.  An exception I can think of would be an
> ancient dialect of Lisp where integers also were machine addresses and
> thus callable without restriction.  E.g., if a function name evaluated
> to a number the interpreter performed a subroutine call to that address
> instead of, say, applying a lambda.  It was the mechanism through which
> system builtins were accessed.  However,  nothing prevented a user from
> "calling" an arbitrary integer and leaping off into never never land.
I seem to have lost track of what "dynamic typed" and "strong" mean. Sorry.

> "Strong typing" (the "static" kind) is also the norm in Pascal and C++.
>  I like to think of strong typing as the norm in ANSI C but there is
> still optional and thus may be considered "weak".  Furthermore, C
> programmers are on the "honor" system across module boundaries, as
> there's no link time checking.  There even are ways to cheat in C++, so
> some might still class it as a "weakly typed" language.  Of course, with
> discipline, it's possible to avoid the pitfalls and always use the
> strong typing facilities of C and with effort enjoy most of the benefit.
It's also possible to enjoy some of the benefits of prison by simply
refusing to go outside. Your very confession of C's and C++'s weaknesses
highlights the fact that even "strongly typed" languages have problems
enforcing the rules (whose value I anyway challenge except for the specific
promotion of execution efficiency). Python is just a bit less anal :-)

> >I
> >find it very hard to produce substantial, large programs using
> >weakly-typed languages.
> >
> Given my definition of "weakly typed," I agree it's more difficult than
> in strongly typed languages.
> On the other hand, isn't it the case that much of Python is implemented
> in C, which is weakly typed?  So "weakly typed" makes it harder but not
> impossible, at least not for some.
You can write structured programs in assembler. This does not make it the
ideal vehicle for a GUI-based commercial accounting system. Python is an
object-oriented environment implemented in C. Ultimately C is compiled into
machine code. What's your point? Once the Turing completeness of von Neumann
architectures is accepted the rest is merely linguistic anthropology: what a
system can do is, ultimately, more important to its users than how it does
it (which is a significant concern of the implementors).

> > Python is strongly, albeit dynamically, typed,
> >
> FWIW, so is Perl.
But not, IMHO, in the same way.

> >Unfortunately, some seminal material of a few
> >decades ago confused terminology (I vaguely remember something
> >about it in some early article about Scheme, for example).
> >
> I think you're right.  I originally learned a different taxonomy for
> many of these concepts.
Well, we all have to watch out for Humpty Dumpty in our own output.

Steve Holden                        
Python Web Programming       
Previous .sig file retired to          

More information about the Python-list mailing list