2.2 features

[Quinn Dunkan]

On Fri, 3 Aug 2001 16:05:23 +0200, Charlie Clark <charlie at begeistert.org> wrote:
>I understand the problem like this: Classes keep lists of their
>sub-classes *and* of their instances and "in" is a keyword which checks
>for membership in sequences.
>
>class Programmer
>	pass
>
>class GoodProgrammer(Programmer)
>	pass
>
>class BadProgrammer(Programmer)
>
>guido = GoodProgrammer()
>charlie = BadProgrammer()
>
>Is this the right way of thinking about it? If so we could then ask our
>classes to list their instances and subclasses and apply membership
>tests to them.
>
>Programmer.instance()
>>>> ['']
>Programmer.subclasses()
>>>> ['GoodProgrammer', 'BadProgrammer']
>GoodProgrammer.instance()
>>>>'Guido'
>GoodProgrammer.subclass()
>>>>['']
>etc.

If they did, they couldn't keep them as lists of strings, because instances
don't have to have names, and can have more than one, etc.  If they kept track
of a list of instances, it would have to be with weak references because
otherwise nothing would ever die.  And even if they used weak references, they
wouldn't know about things coming out of a marshal or pickle (well, I'm sure
pickle could call a registering routine, but it would be ugly).  And, if this
were implemented, 'in' wouldn't be the right operator, because you want
identitiy (is), not similarity (==).

And it wouldn't scale.  If you say 'x in int.instances()', is the system
supposed to track down every single living number and do a linear search
through all of them?  What if int has subclasses?  It would need to track all
those down too.

So, no, thinking about things as if classes keep track of all their instances
is not the right way, it's the other way around.  In dynamically typed
languages without optimizing compilers, all objects have a type tag that tells
them what they are.  Nice try, though, it's good to make those kind of
generalizations where they make sense.

Other object-oriented languages provide a 'conforms_to' or 'kind_of' message.
I don't see why python couldn't do the same:

x.instance_of(int)

>I still don't get generators btw. What does 'yield' do that 'return'
>can't

`yield' can be resumed.

def f():
    return 1
    return 2

'f' will never get to the 'return 2' no matter how many times you call it.

def f():
    yield 1
    yield 2

First of all, the new 'f' doesn't return an integer, it returns an iterator.
But the second time you call the iterator's next() method you will get a 2.