2.2 features

[Michael Robin]

Marcin seems to have covered much more detail then I could have, but I
thought it intersting to mention one more (simple) thing.
Python has not only a single-reciever method dispatch syntax, but also
keywords and built-in operators, and it uses these it's advantage to
escape a restrictive dispactch. (Python x.plus(y) (with no
__overrides__ :)) or Smalltalk x+y or x plus: y has little choice but
to depend only on x.) The Python bulit-ins operate in a sometimes
arbitrary manner, but they try and do the most "useful thing" and
rules are few and can be learned. Take "/" (and PEP238) as an example
of how a built-in is special. (Also, [3]*2 == [3,3] but not [[3],[3]],
or [6], or an error.)
(One could argue that a more generic dispatch (mutli-methods or
whatever) could be used to bring the behavior to the user level - but
we have other languages for that.)
So I think "obj in Class/Type" is useful shortcut as long as it
doesn't break something essential.

OTOH, (why is there always an OH?) this does suffer from the "it just
sounds good" syndrome which could lead to improper uses of "in", like
"is" is abused today in place of "==".  (I can also see "x is <type>"
getting used (and again meaning the wrong thing), as it "sounds good".
(Maybe in this case we'd be better off with just "id(x)==id(y)".) "x
isa <type>" is really what we want if we want a keyword.


m



-------------
Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote in message news:<slrn.pl.9m6a5m.kmu.qrczak at qrnik.zagroda>...
> 28 Jul 2001 18:33:33 GMT, Quinn Dunkan <quinn at retch.ugcs.caltech.edu> pisze:
> 
> > This implies (at least to me) that 'in' would be a general shorthand
> > for 'isinstance'.  But then I would sort of expect '3 in [1,2,3,4]'
> > to behave like 'isinstance(3, [1,2,3,4])'
> 
> If you forget about 'isinstance' then everything is ok, right?
> 'in' performs some membership test whose details depend on the second
> argument. It should not be more confusing that '+' being either addition
> of numbers and concatenation of sequences. We don't expect "a"-(-"b")
> to be equivalent to "a"+"b" just because 3-(-4) is equivalent to 3+4.
> 
> Now thow in 'isinstance' as an old way to spell a specific membership
> test (for types and classes) which doesn't have to be learned about
> at all.
> 
> > Or you could just say that type objects implement a __contains__
> > method that does an isinstance. But if classes and types are unified,
> > that would get in the way of classes that define __contains__.
> 
> It indeed shows a flaw in unifying "attributes of instances which
> are defined by their classes" with "attributes of class objects
> themselves".
> 
> For example many objects are hashed by what o.__hash__() returns,
> but not type objects, because their __hash__ is something completely
> different (it expects an argument and hashes it instead of the
> receiver). Similarly for most magic methods.
> 
> It more or less works because intersection of proper attributes of
> type objects and attributes which are always polymorphically extracted
> using names (and not slots in the representation of type objects)
> happens to be empty.
> 
> This is so hardwired into Python and pushed by type/class unification
> that I don't believe it can be avoided without redesigning the language
> from scratch.
> 
> This particular case of __contains__ is not different than e.g.
> __hash__ or __str__. You can't redefine in Python how your class object
> (or type object in Python-2.2) will be hashed or printed, you won't
> be able to override the membership test either (and you can't now
> AFAIK) - unless something solves the generic problem of putting class
> attributes and static instance attributes in one namespace.