[Types-sig] type declaration syntax

[John Machin]

[John Skaller]
> > I guess that NO python programmer wants to declare the type
> > of every single name, which is what APC style static type
> > checking requires.
> [Tim]
> I would be delighted to if it sped some of my "marginal" programs by a
> factor of 2.  My employer would be delighted to if it saved them from
> runtime TypeErrors next week instead of next year.  Any tradeoff you can
> think of has a larger audience than you can imagine <wink -- but that
> includes an audience for Viperish global inference too!>.
> 

Indeed. Further, from what we of the APC persuasion also desire 
salvation is the speed-driven need to cache references to methods and 
functions in local variables e.g.

   def myfunc(real_arg_1, real_arg_2, srepl = string.replace):
      # known favourite trick of Tim's
      # as Tim has said recently, it's not robust in the face of caller 
      # going myfunc("foo", "bar", "you lose")
or one of mine:
   wlist = []
   wapp = wlist.append
   for x in some_long_sequence:
	wapp(some_func(x))

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?

Some possibilities:

(a) declare that certain objects are unpokeable --- pragma nopokeever 
at the top of the sys module would trap sys.maxint = "gotcha" at 
compile-time

(b) others may be pokeable initially but then frozen
   some_module.some_func = my_better_func
   nopokeanymore(some_module)
or
   my_soon_to_be_read_only_data_structure = load_from_file(.......)
   nopokeanymore(my_soon...)
so that run-time checks could made on attempts to poke at the object?

(c) declare that code in the current module doesn't poke in 
replacements for methods in other modules (or in itself) and neither do 
the modules it calls and if they do then I'll take the rap .... so that 
an optimising compiler
could move the resolution of wlist.append outside the loop as in my 
example, or even as in Tim's trick do the resolution when the module is 
loaded ...

(d) I really miss #define and const and enum; how about 

   const INITIAL_STATE = 0
   const NEXT_STATE = 1
   const ANOTHER = 2

so that faster and more robust code could be generated?

Don't-stop-at-bytecode-hacks-the-ultimate-dynamic-language-would-allow-
"poke(arbitrary_memory_address)=expression"-ly yours

John