James J. Besemer
jb at cascade-sys.com
Wed Sep 25 23:52:40 EDT 2002
Erik Max Francis wrote:
>The problem here is that there is no official "formal definition."
That's a real problem, as a definition for the term was the OP's
>use "weak typing" to mean any type system where the typing can be foiled
The majority of Google references and the one Cardelli reference I was
able to locate all support this view. Some of the Google references are
from University course curriculum, so it's what's being taught to CS
students. It's the most authoritative and meaningful definition anyone
has brought to the table thus far.
>some use it to mean any system where operations, not the
>objects themselves, determine the types of the objects.
By my count, only 2 or 3 people (including yourself), all on this list,
use this interpretation. From Google, nobody gave this definition. The
only definitions I found contrary to the first alternative was that
"weak typing" was synonymous with "dynamic typing", which I think
everybody here rejects.
Furthermore, with elaborate review of the abstractions involved and
details of the Python implementation, I showed that the above statement
is really meaningless. On the one hand, it IS how Python intrinsics are
implemented internally (operations literally inspect object types, not
the reverse). But OTOH it is NOT the abstraction we tend to think of
when we use the language (objects define operations). It's one of two
ways of looking at a language but it's not a way to distinguish one
language from another. You have objects and you have operations which
are associated somehow. In actuality, neither the object or the
operation "determines" or makes any decision about anything. It's the
runtime environment that glues it all together.
With user defined types (different implementation than system
intrinsics), we know there's a dictionary of function names pointed to
by each object. But "who" does this lookup? Who applies the function
to self (and to self only by convention)? There's no code in the Object
to do this. Nor is there any code in the member function to do the
lookup. So, it's not really fair to say that either one "determines"
what to do, is it? Else, in which one does the apply() occur?
In fact, in Python, the answer is none of the above. It is the
LOAD_ATTR primitive operator (".") that examines its two arguments
(faulting if they're not specifically an object reference and a string)
and then does the dictionary lookup which fetches the resulting
attribute and pushes it onto the stack. Then (if the result is a
function) it's is the CALL_FUNCTION (or a related) operator which looks
at its arguments on the top of stack and figures out how to proceed
(primitive function, a method or what?). So in the end, even Python's
OOP features are based on (multiple) explicit "operators that have to
examine the types of its arguments in order to know what operation to
perform." But this is in contradiction to how we all "know" objects
work, so in reality the distinction is meaningless.
>(I favor the
>latter definition, since it carries more information about the
It doesn't really tell you anything.
Else, in 25 words or less, why does Perl's "+" operator supposedly work
the one way and Python's "*" operator work the other way?
>This is simply a case of differing terminology.
In this thread I've been twice accused of, Humpty Dumpty like, using
terminology of my own device in lieu of some mythical, more
authoritative source. And yet many explicit 3rd party references
(including one of Alex's own) contradicts his interpretation in favor of
the one I have thus substantiated.
I dunno -- I tracked down and presented all the references I could find.
If the definition I offer from that perspective is not sufficiently
WORTHY for this group then clearly I have wasted my time.
You can lead a pig to pearls....
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
More information about the Python-list