gah! I hate the new string syntax

[Alex Martelli]

"Pieter Nagel" <pieter at nagel.co.za> wrote in message
news:Pine.LNX.4.21.0103161647280.2809-100000 at bast.jhb.equinox.co.za...
> On Fri, 16 Mar 2001, Alex Martelli wrote:
>
> > "Pieter Nagel" <pieter at nagel.co.za> wrote in message
> > news:Pine.LNX.4.21.0103161339210.2809-100000 at bast.jhb.equinox.co.za...
> >     [snip]
> > > Of course you can. The technique is to modify the String class itself
> >
> > It's not a class.  It's a non-class type, and does not support
> > modification.
>
> Yes. But the author I responded to said "assuming that String is a
> class, not a type". My answer was made within the context of that
> assumption.

All classes NOW allow you to change their methods -- but strings
NOW are not a class.  If we assume Python changes enough that
strings become class instances, we might also get a 'lock' feature
on dictionaries to let a dictionary using object avoid modifications
thereof by client-code -- and it might well be used to safeguard
certain crucial 'system-types'.  Thus, the ability to invasively
modify builtin types should not be assumed -- even if the type/class
split gets healed.

Non-invasive mods would be a better target -- and I think a
runtime variation of Haskell typeclasses might be a nice way
to present such mods.  E.g., suppose that, parallel to the
existing builtin 'isinstance(object, [class or type object])',
that just returns 0 or 1, we have in some future Python a
new builtin:
    getinstance(object, [typeclass object, or etc etc])
which returns either None (meaning the required 'cast' is
not feasible) OR a reference x such that the axiom:
    x = getinstance(y, z)
        =>
    x is None or isinstance(x, z)
is satisfied, and x 'represents y as a z' -- for example
if isinstance(y, z), then x is y should hold; if z was
type(1), then x==int(y), etc; the actual novelty would
come if z was a 'typeclass object', a new kind of things.

Typeclasses would be a new kind of classes, not directly
instantiable, such that: a class A might inherit from a
typeclass B, and then everything would work as if B was
a regular class; but also, a pre-existing class C could
be *post facto, non invasively on C* be made to belong to
B, contextually overriding some of B's methods (this
post-facto-instantiation would be recorded in B, not
in C).  This would, I believe, be implementable today
in pure Python.  Hmmm, I feel _close but not quite
there_ to thinking up that implementation -- maybe it
needs some metaclass black-magic (or resignation to a
rather slow example implementation, as it _would_ be
just an example anyway) -- I wouldn't want a class that
inherits from a typeclass to automatically be a typeclass
itself, for example.


Alex