The problem to which super is a (general and tricky) solution is the consequences of multiple class inheritance rather than class inheritance. A single-inheritance super could be realized in a less tricky way.

    > I don't see much difference [..]

1) Inline classes

A pattern I sometimes use involves creating an object to maintain state before a for loop. Example scenario: parsing characters as they come in over a network line. Say the data has qutation blocks that create nesting situtaion. You want to support both ' and " blocks.

It's a simple situation. You want an object that will store some kind of mode for what scope you're in at the moment, and you'll be accumulating the structure you're parsing. [1] You might want the object to have a render(self) method as well, to dump the data once you've parsed it.

In io you can just say "Make me an object that does this". In python you declare a class, and then instantiate an instance of it. It's needless to create the class - there is absolutely only one time that I'm going to build this thing. [2]

You could create a syntax that worked like python, but had a syntax that addressed this without technically being a prototype language.

2) Adding functions to existing objects

In python there is ugliness involved in tapping a new function onto an existing object. Python's a bit confusing here partly because of the way self works. When I encounter this in python I usually do a lambda trick to make the function a member of the object, and then I'll have some method on the object that will refer to it. The equivalent in io is more straightforward.

    > A single-inheritance super could be realized in a less
    > tricky way.

I remain interested in this broader issue of - is class-based inheritance a good thing at all?

==

[1] In python you have to use a structure for this, because once you're in the 'for' loop, it won't let you rebind variables outside the scope of the for loop, only modify them.

I haven't played with 'inline' yet.

[2] You could also use a dictionary, but I think that's a bit more verbose. An object is just what I want in these situations.

2) Actually, I don't mind if adding methods to other developers' objects is hard; it always seemed to me like a dirty hack.

    num = 42

    def num.to_whatever
      "whatever"
    end

    num.to_whatever # => 42
    41.to_whatever # => NoMethodError

For #2, the method documented in http://stackoverflow.com/questions/972/adding-a-method-to-an... doesn't seem so bad to me.

  object.methodname = new.instancemethod(function, object, class)

    > For #1 you can just use a closure.

Perhaps if you gave an example of what you think doesn't work, I might understand your point.

You can create classes inline via `type`, and Python 2.6 has named tuples which are basically record types. You could also create a one-off class onto which you'd graft attributes as needed:

    >>> class Object(object): pass
    … 
    >>> a1 = Object()
    >>> a1.a = 3
    >>> a1.b = 'foo'
    >>> a2 = Object()
    >>> a2.stuff = 42

    >>> a3 = copy.copy(a2)
    >>> a2.stuff
    42
    >>> a3.stuff
    42
    >>> a3.stuff = 43
    >>> a2.stuff
    42
    >>> a3.stuff
    43

By about 4 characters per key access.

> In python there is ugliness involved in tapping a new function onto an existing object. […] When I encounter this in python I usually do a lambda trick to make the function a member of the object

What lambda trick? Why not just create a (bound) instance method from your function and graft that onto your object? Granted it's not going to be as sexy as doing so in IO, but it takes all of one line:

    >>> def foo(self): print 'Instance method of', self
    … 
    >>> # naïve version, not going to work as it doesn't bind the function to the instance, it just sets a function as a member of the object
    >>> a3.foo = foo
    >>> a3.foo()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: foo() takes exactly 1 argument (0 given)
    >>> a3.foo = types.MethodType(foo, a3, Object)
    >>> a3.foo()
    Instance method of <__main__.Object object at 0x1004cdf50>

If you use single inheritance always, you can just get rid of `super` altogether: just call the relevant method on your superclass.

> [1] In python you have to use a structure for this, because once you're in the 'for' loop, it won't let you rebind variables outside the scope of the for loop, only modify them.

I hope I misunderstand what you mean, because what I'm reading here is downright wrong: Python only has function-level scoping (and a special scope for listcomps, but that's a different issue) so any binding you create or modify within a for loop (or a `with` statement, or an `if` or whatever else you may think of) will be visible from outside the block:

    >>> a
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'a' is not defined
    >>> for i in range(1):
    ...     a = i
    ... 
    >>> a
    0

    >>> for i in range(2):
    ...     a = i
    ... 
    >>> a
    1

    > did I miss something?

Perhaps this code demonstates what I'm getting at.

    def my_function():
        a = 1
        def modify_a():
            a = 2
        modify_a()
        print a # prints 1
        #
        b = [1]
        def modify_b():
            b = 2
        modify_b()
        print b[0] # prints 1
        #
        c = [1]
        def modify_c():
            c[0] = 2
        modify_c()
        print c[0] # prints 2

    my_function()

Lua is prototype based. It's also quite fast. What if we ported the Python standard library and added list-comprehension?