What is the class of myobj?

[Erik Max Francis]

JXStern wrote:

> Well, this real polymorphism is interesting stuff.
> 
> Just because an object Y has an interface for tinkle with two
> parameters, do we assume it's the same tinkle with two parameters that
> object X has?

I'm not exactly sure what you're getting at here; I was just showing you
a possible "preflight" test you could do as an assert so that you could
get some feel for whether or not the object you've been passed supports
a sequence interface.  The best way to tell whether or not it actually
does support it is to just use it.

> Is it really a bad thing to own a static analysis of the parameters
> and semantics of your classes and objects?

It's not _bad_ thing, but it does mean that you may be limiting yourself
unnecessarily; it's usually considered un-"Pythonic."  Python is fully
dynamic, so as long as the object I've passed you has the interface
you're expecting, it shouldn't matter whether that object is of a
builtin type or a particular type you're expecting.

It's perfectly valid to test whether an object is, say, a tuple, or a
list, or an instance of a special MyOwnSequence class, but you're
leaving out a huge number of opportunities.  The idea of adding
interfaces to Python has been brought up before, but it's hard to make
it fit in with its dynamic nature.  For one obvious thing, even if an
instance claims to support an interface, it may not properly support it,
and thus errors would be thrown in the process of attempting to use it. 
Since the "declaration" of an interface can't really avoid this problem,
one has to wonder if it's anything more than just a "hint," and if so,
why you're not just left with easier-to-ask-forgiveness-than-permission
approach of "just use it; if it's wrong, it won't work."

> I'm rather unpleased with
> Python's lack of strong typing when you want it, and of the lack of
> declarations to avoid accidental naming errors, especially when
> case-sensitive.

As a usage note, I suspect you probably mean "static typing" rather than
"strong typing."  Peoples' definition of strong typing varies, but it
usually means something like the type system cannot be subverted or that
objects, not operations, determine the meaning operations on them.  By
most considerations Python is (at least fairly) strongly typed; for a
strong vs. weak constrast within dynamically typed languages, consider
Python vs. Perl.  It _is_ true that Python is dynamically, not
statically typed, meaning that one does not write declarations of
objects and names can be bound (and rebound) to objects of any type.

That aside, I've found that Python's dynamicism doesn't really cause
much penalty in terms of typos.  They happen, to be sure, but I've never
really had a situation where I was _seriously_ inconvienced because of a
typo on my part.

It is true, though, that you can get into hot water if you use excessive
numbers of try: ... except: ... clauses without explicitly listing the
exceptions you want to catch, since these would catch NameErrors and
AttributeErrors that might simply be associated with typos.  But this is
just a general property of exception handling:  You want to catch on
only the exceptions you expect the block of code will throw; other
exceptions that get thrown are either design flaws or are attributed to
larger-scale errors.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ Nine worlds I remember.
\__/ Icelandic Edda of Snorri Sturluson
    HardScience.info / http://www.hardscience.info/
 The best hard science Web sites that the Web has to offer.