Getting started

Wed Sep 25 14:45:32 EDT 2002

Steve Holden wrote:

>"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?
>

However "lame" or "weak" you may consider this feature to be, it does 
NOT constitute "weak typing" per the formal definition.  This is simple 
polymorphism, as you seem to acknowledge, same in Perl as in Python.

The proper definition of "weak typing" is that in an otherwise strong 
typing system there are ways to cheat the system and apply illegal 
operations to certain types.  The quintessential example is in C++, 
where, despite a fairly robust and secure type system, you always can 
cast objects to the wrong type and force illegal operations on them.   
This is in contrast to Strong typing, where such "type errors" are 
strictly prohibited.  These type errors are not possible in Python nor 
in Perl.  Thus neither is "weakly typed" in the formal sense.  They're 
both strongly, dynamically typed.  

You say "the operator has to examine the types..."  as if this is 
somehow different from Python.  But, e.g., Python's "*" operator has to 
examine it's arguments in order to know which operation to perform, does 
it not?   You don't like to think of it that way but if the notion 
applies to Perl then it applies equally well to Python..  

In FACT, if you examine the source code, this is EXACTLY how both 
languages are implemented.  There is but one each binary "+" and "*" 
operators in Python's byte codes.  At runtime, the interpreter takes the 
operator and then LITERALLY "examines the types of it's arguments (on 
the top of stack) in order to know which operation to perform".  E.g., 
binary_multiply "looks" at it's arguments to decide if  it's to perform 
a string operation, a list operation or a numeric computation. 
 Similarly, the binary subscript has a special test inline if the left 
argument is a List and the right one is an Integer, in which case it 
directly executes PyList_GET_ITEM(); otherwise, it calls the more 
generic PyObject_GetItem(), which in turn continues the decision tree 
down for each valid combination of operand types, ultimately throwing an 
exception if the combination is invalid.

Now that's how it WORKS.  Underneath the hood, Python is implemented in 
flat C code that emulates objects.  The code "switches" on operators 
that in turn inspect object types to decide what specific operation to 
perform.  Now, in principle, you also can "say" that operations are 
defined on a per object basis, since that is the abstraction ultimately 
provided and because we all prefer to view the universe from that 
perspective.  But in any case, the implementation and the fundamental 
abstraction are the same for both Python and Perl.  You can call it OO 
or you can call it operator-inspection.  The difference is merely your 
point of view.

The only real difference between the two languages is the particular 
choice of operators and valid operands  -- and arguably the relative 
wisdom of those choices.

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

I agree "+" is too subtle an example.  "*" is better.

>For example, how does the Perl "+" operator
>find out about a new addable type? 
>

I don't know.  Look it up and you tell me.   In Perl, the greater number 
of builtins are keyword based and Perl classes definitely CAN 
override/overload builtin keywords.

>Is Perl even able to integrate its
>intrinsic data objects with user-defined types? 
>

No.  I don't think so.  Perl's OOP features have lagged behind Python's. 
 And in all fairness, it's a new feature to Python.

>Can we say inheritance hierarchy? 
>

Yes, Perl's OO mechanism includes inheritance.

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

Certainly, Perl's object model is not as good as Python's.  At best, 
it's more like Python's was before type/object unification (and it's not 
even that good).  Nevertheless, the Quality of the object model (and the 
questions you raise above) is IMMATERIAL to my original claim, regarding 
weak vs. strong typing (in the formal sense).  In fact, weak vs. strong 
typing is a distinction that applies equally well to languages without 
any OOP support at all.  It has to do with "type safety", not the 
OOP-ed-ness of the language.  It's not a sliding scale, 0 to 100%; it's 
binary, black vs. white.  Can the user violate the type rules of the 
language (whatever they may be), yes or no?  If yes then Weak; if not 
then Strong.  Perl, like Python, protects its objects with dynamic 
runtime checks, thus it is strong not weak.

I think this is the KEY misunderstanding when you and others attempt to 
argue with me.  Read Cardelli's paper.  Either you concede this point 
and thus my original premise, or else you're simply wrong and I'll have 
done all I can to set you straight.

>>Perhaps an even better example is the "*" operator:
>>
>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.
>

Perl and Python work exactly the same way in this regard.  

The confusion is that Perl defines many more primitive operations and 
defines meaning for many operator/type combinations where Python does 
not.  Now you can argue that Perl is flawed in this way but in principle 
there is no difference in how the two work.  Both are absolutely 
deterministic in what specific operation is applied to what object in 
every legal context.  Only Perl defines extra ones, such as arithmetic 
on strings, that Python does not.

One way to think about Perl's "+" and "." operators formally is that 
there actually are several of them, all producing similar (but subtly 
different) results.  

    string + string -> number
    string + number -> number
    number + string -> number
    number + number -> number
    string . string -> string
    string . number -> string
    number . string -> string
    number . number -> string
    list + list -> list
    string * number -> string
    list * number -> list

    (many others)

In principle, it's no different from Python (except in choice of operators):

    string + string -> string
    number + number -> number
    list + list -> list
    number * number -> number
    string * number -> string
    list * number -> list

    (many others)

Fundamentally it's just polymorphism.  This way, you don't have to think 
about the "operators making a decision," if you don't like.   Whether 
the operator or the object "decides" really is an implementation detail. 
 The abstraction is that there exists a thorough enumeration of  valid 
combinations of operations and object types that maps onto a set of 
operations.  In this fundamental sense, the languages are the same.

Of course, each may have some back-door C module that implements "peek" 
and "poke" or some mechanism that does in fact allow type safety to be 
violated.  But I'm intentionally disregarding limit cases such as that; 
certainly they do not constitute the overall intent of either language.

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

Many other languages have worked this way.  And it certainly has some 
utility.  If you don't like it, fine, but there's ample precedent by 
smarter inventors than you and me that indicate it's not a crazy idea.

Anyway, I'm not arguing for the feature's inclusion into Python.  My 
only point is it does not make Perl "weakly typed" in the formal sense.

>For some meaning of strong, I suppose, but please don't bother to define
>what this is.
>

EEEK!  Sarcasm.  ;o)

These terms has been bandied about so much on this list that I thought 
it was generally understood.  Geeze, they're part of the standard 
mantra.  And I didn't start the discussion; I only took issue with 
Alex's misclassification of Perl.  Curiously, this thread reveals that a 
lot of people don't have the first idea what these terms mean..

Anyway, I did give a clear definition at the start of this post, with 
references to back it up.  Also, if you do a google search, you'll find 
a bunch of hits that are consistent with my definition (along with some 
that equate "weak typing" with "dynamic typing", which I'm sure 
everybody here will agree is practically the Opposite of what we all 
mean (perhaps this is why we're confused ourselves)).  

Equates weak and dynamic [Bogus]

   http://www.lispme.de/lispme/doc/lm_sema.htm
   http://www.perlmonth.com/perlmonth/issue5/modules.html

http://www.usenix.org/publications/library/proceedings/%20tcl98/full_papers/howlett/howlett.pdf 

   http://www.ruby-lang.org/en/testimony.html

Strong is Safe vs. Weak is Unsafe (specifically preventing vs. allowing 
"type errors"):

http://www-lp.doc.ic.ac.uk/UserPages/staff/ft/alp/net/typing/strong.html 
(weak is unsafe)
   http://www.cise.ufl.edu/~jnw/OOCourse-95/Lectures/Jan.31.html (strong 
is safe)
   http://www.cs.auc.dk/~normark/prog3-01/html/notes/fu-intr-1-book.html 
(lead to errors)

http://216.239.39.100/search?q=cache:oBq2r3PwR1kC:www.cs.cornell.edu/courses/cs412/2002sp/lectures/lec12.ps+definition+weak+typing&hl=en&ie=UTF- 

Weak == otherwise Strong + Means to override e.g., C:

   http://www.wkonline.com/d/weak_typing.html
   http://www.wkonline.com/d/strong_typing.html ("strict enforcement")

"Strong types for weak minds" [a cute quote I thought y'all'd enjoy] -- 
strong typing is either overly restrictive (Pascal) or allows overrides 
(C) [which is definition of] "weak typing".

   http://people.cs.uct.ac.za/~gaz/teach/cpl/lect2.ppt

Read and understand.

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

Perl documents the (surprising to you) behavior of "+".  If it's working 
as advertised it's standard behavior cannot be considered a "type error" 
and thus it's not a sign of weak typing.

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

True but irrelevant to strong vs. weak typing.

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

I said it treats numbers as strings, not the reverse.  I'll let this go, 
though, as I am NOT advocating such a change to Python.

>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 agree Perl is muddled.  It's a pile of crap.  It's a hack on a hack, 
raised to the 1e5th power.  Perl's notion of scalar vs. array "context" 
is the worst idea ever.  Blah blah blah.  I agree it's a crock.  But 
that does not make the language "weakly typed".  It's strongly typed, 
like Python, as it does not allow "type errors."

>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 :-)
>
These deficiencies of C and C++ make them "weakly typed" by definition. 
 They're good examples while Perl is not one.  Yes, otherwise "strongly 
typed" languages are instead weak if they permit cheating.  Pascal would 
be strong if a few tiny cracks were plugged.

I had an even longer reply to this thread that was rejected for being 
too long.  I think this reply sums things up better in less space.

Anyway, I'm just picking a nit.  Perl is inferior to Python in just 
about every conceivable manner -- except this one, highly technical sense.

Regards

--jb

-- 
James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at cascade-sys.com
				http://cascade-sys.com	