Home Original page

Zope & Python

Alex Martelli aleaxit at yahoo.com
Thu Oct 12 17:12:58 EDT 2000 
"Tom" <nospam at nospam.com> wrote in message
news:K9lF5.118563$dZ2.53141294 at news3.rdc1.on.home.com...
> Regardless of who is technically right about the value of these language
> issues (static type checking, access control), it must be accepted that a
> lot of people want them.
>
> I don't see why these features couldn't be added to Python in a way that
> would be completely optional and wouldn't affect backward compatiblity.
>
> I'm not suggesting that the implementation of these features would be
easy.
> I'm saying that, in theory, we could have the best of both worlds.

Adding ANY feature to a language has costs; let alone a feature that
goes as deep as "static type checking".  Re "access control": Python
already has the part of it that's really useful -- the ability to make
fields and methods private against accidental access, by naming
them with a leading "__".  C++'s protected was a design error --
it's identified as such in Stroustrup's excellent "Design and Evolution"
book.  And protection against *accidental* undesired access (not
against deliberate hacking...) is all that C++'s "private" does (again,
see Stroustrup's book; this holds for most languages -- only Java
has somewhat larger ambitions for _its_ "access control").

Slapping together a half-assed "type checking" kludge, "because a
lot of people want" some kind of buzzword compliance about it,
would be the worst kind of disaster for Python.

There IS a role for (*completely* optional...) type-checking in
Python -- and I'm not the only one to think so.  However, I believe
the "type-checking SIG" has been basically dormant for a VERY
long time.  I opine that, perhaps, there was no basic consensus
reached about what the "type-checking" should accomplish.  The
detailed "means" are of less interest, if the "end" is not agreed
upon, I guess.

>From my POV, a 'dream' typesystem for Python would let me:
-- express and name interfaces -- collections of methods and
    semantic assertions about those methods -- ideally with
    the same feature as Haskell's typeclasses, namely the
    ability to give a 'typical/reference' implementation of some
    methods in terms of others (and a minimal set of sets
    of methods that _must_ be overridden to implement the
    interface);
-- _retroactively_ state "and this type/class X satisfies this
    interface Y, via these overridings" (minimal or not), as
    well as doing it contestually to the type or class's definition;
-- for any given 'semantic assertion' or groups thereof, let
    me choose (at runtime) between checking it OR accepting
    it as given (potentially allowing some optimizations by
    deduction from those "givens"...);
-- let me state that a certain argument (or field, or...) must
    satisfy a certain interface (treating it as either something
    to check, or on which to base optimizations, just as for
    any other semantic assertion, see previous point).

I do wonder if we'll ever see all of this in the development
line of the present Python, or if it all must wait for the
utopia of the future/hypothetical "Python 3K"...


Alex
More information about the Python-list mailing list