Inheritance question

castironpi at gmail.com castironpi at gmail.com
Tue Mar 25 14:44:20 EDT 2008


On Mar 25, 12:01 pm, Robert Bossy <Robert.Bo... at jouy.inra.fr> wrote:
> Hi,
>
> I'm not sure what you're trying to actually achieve, but it seems that
> you want an identificator for classes, not for instances. In this case,
> setting the id should be kept out of __init__ since it is an instance
> initializer: make id static and thus getid() a classmethod.
> Furthermore, if you have several Foo subclasses and subsubclasses, etc.
> and still want to use the same identificator scheme, the getid() method
> would better be defined once for ever in Foo. I propose you the following:
>
> <code>
> class Foo(object):
>     id = 1
>
>     def getid(cls):
>         if cls == Foo: return str(cls.id)
>         return '%s.%d' % (cls.__bases__[0].getid(), cls.id) # get the
> parent id and append its own id
>     getid = classmethod(getid)
>
> class FooSon(Foo):
>     id = 2
>
> class Bar(Foo):
>     id = 3
>
> class Toto(Bar):
>     id = 1
>
> # Show me that this works
> for cls in [Foo, FooSon, Bar, Toto]:
>     inst = cls()
>     print '%s id: %s\n    also can getid from an instance: %s\n' %
> (cls.__name__, cls.getid(), inst.getid())
> </code>
>
> One advantage of this approach is that you don't have to redefine the
> getid() method for each Foo child and descendent. Unfortunately, the
> "cls.__bases__[0]" part makes getid() to work if and only if the first
> base class is Foo or a subclass of Foo. You're not using multiple
> inheritance, are you?
>
> RB

It is clear there are always two vectors is programmer thoughtspace:
class and instance, and that they are orthogonal, and even
orthonormal.  Every (human-thought native) data structure can be
expressed as a sum of two vectors, scalar * unit, scalar * unit in a
particular order (cf. Gram-Schmidt), or a tuple.  Writing code is
simply the specification of scalar and scalar.

Clearly the alphabet-space of programs ( symbol* ) contains (improper)
the alphabet-space of Python programs, (which) contains (proper) the
token-space of Python programs, (which) contains (proper) the grammar-
space of Python programs, yet but here we lose thought; do you think
in Python?

Python ignores some subset of distinctions we make in thought, and we
ignore some subset of distinctions Python require (w.c.)s.  How do we
effectively communicate with it?

Order is a non-commutative relation.  (a,b) did come from reality, but
does not fulfill Rab; conclude (a,b) did not come from reality; and R
is a truth relation.  </lemma>

Conclude Rab is a scalar.  Is a gram a pound?  Is it two pounds?
Newton's zero-find method finds b given a and Rab.  (Expected time to
zero pent).  Do you think in Newton's method?  Are functions scalars?
'''In the mid-20th century, some mathematicians decided that writing
"g o f" to mean "first apply f, then apply g" was too confusing and
decided to change notations. They wrote "xf" for "f(x)" and "xfg" for
"g(f(x))". This can be more natural and seem simpler than writing
functions on the left in some areas.''' - wikipedia.

Does anyone know category theory or pointless topology?  My point in
asking, is if we can explain in a really easy way using those
establishments, to Python how we think, (several symbols, what when),
we would like it, assuming it likes us.

To effectively communicate with Python, what does the assumption that
'we want something', that 'there's a reward' exclude?  Python wants to
reward programmers often enough.  (Python + Usenet does!)  Do we like
to be frustrated?  What's good for us is good for Python.  What
frustrates you the most?



More information about the Python-list mailing list