Getting started

[Steve Holden]

"James J. Besemer" <jb at cascade-sys.com> wrote in message
news:mailman.1032567390.29374.python-list at python.org...
>
> 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
confusing
> 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
Python.

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

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

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

regards
-----------------------------------------------------------------------
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/
Previous .sig file retired to                    www.homeforoldsigs.com
-----------------------------------------------------------------------