[Types-sig] Handling attributes

Tim Peters tim_one@email.msn.com
Fri, 17 Dec 1999 02:25:55 -0500


[PP]
> ...
>         b. do we check assignments to class and module
> attributes from other modules at runtime?

As an eventual end user, if I declare the type of a name (*any* name), and
I've enabled type checking, I expect that there is no possibility of that
name getting bound to an object not of the declared type.  I expect to get
an error at compile-time if that's feasible, but I understand it may not be.
In the latter case I expect a runtime error pointing at the offending
binding.  I also accept that the program may run slower because of this!

> ...
>         c. should we perhaps just disallow writing to "declared"
> attributes from other classes and modules?

OK by me at the start.  It's one way to satisfy my "no possibility", about
which I'm serious because users will be serious.  Unfortunately, I'm also a
typical user in demanding the impossible <wink> -- that is, "no" is a very
strong word, covering things like "disguised" rebindings via direct __dict__
access too.  So as a reasonable user, I settle for "no possibility, with
this peculiar but precise meaning of 'no': ...".

>         d. is it possible to write to UN-declared attributes from
> other people's classes and modules? And what are the type safety
> implications of doing so?

Sure and none, for some peculiar but precise meanings of "sure" and "none"
<wink>.  For example, it may or may not totally screw up the conclusions
reached by a type inferencer -- we'd have to see the type inferencer first
to know for sure.  Or if Guido's "optimize builtin" (yay!) idea is
implemented, my doing

    yourmodule.len = lambda any: 42

will likely have no visible effect (for some peculiar but precise ...).

but-i'd-call-that-a-feature!-ly y'rs  - tim