[Types-sig] type declaration syntax

skaller skaller@maxtal.com.au
Thu, 23 Dec 1999 10:58:39 +1100


John Machin wrote:

> Now I do appreciate the possibilities and practicalities of replacing
> functions and methods on the fly, the reflective capabilities, the
> whole dynamic thing, but please please please can't we have a way of
> declaring that we're peeking, not poking, 99% of the time?

	Why not the OTHER way around, to match the statistics?

1) Ban rebinding module variables after importing is done
	
2) Specify that 'def' creates an immutable binding. You can't
   rebind (or del) the name. Same for 'class'. [This includes
    defs inside classes]

3) It isn't necessary to introduce 'const', at least for modules and
classes:
   Here's why:
   Given (1), the only ways to change a module level variable are:

	a) a module level assignment -- easy to detect
	b) an assignement in a function defined in the same module,
           which has a global directive for that variable
	c) exec statement [if you see one, abandon hope of optimisation]
	d) __dict__ hackery from outside the module

The only hard case is (d). This cannot be statically checked.
It can be banned all the same (and on the programmers head be it),

I.e. TWO bans fix most problems. The ban on module level rebindings
is a significant restriction. The ban on changing 'def' and 'class'
bindings can be worked around [use another variable] and so
no functionality is lost, provided that the author takes
this into account. EG:

	class X:
		def f(..): pass
		g = f # g can be rebound, f cannot be

I think this covers:

	caching all module and class level variables
	caching instance methods

what is not covered is caching instance attributes.

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850