"Frozen" modules w/ static semantics[was Re: Zope 3.0, and why I won't use it]

[Ville Vainio]

>>>>> "Alex" == Alex Martelli <aleaxit at yahoo.com> writes:

    >> situations in type inference? Type declarations would of course be
    >> optional, and they could be a big win esp. for non-cpython

    Alex> My prediction is that, once 'of course optional' type
    Alex> declaration gets in, it will become the mandated approach in
    Alex> most new-to-Python shops, by

I don't think this has happened with Lisp either, so it doesn't
necessarily happen with Python. Python has a strong culture of dynamic
typing, it wouldn't disappear overnight. It's a matter of education,
mostly.

    Alex> And of course the 'foo' type will generally be built up in
    Alex> another module, so we're talking about a compiler that
    Alex> examines other modules in order to be able to compile this
    Alex> one.  Whole-program compilation with compile-time inferred
    Alex> name-object bindings would be such a huge and total
    Alex> revolution wrt today's Python that very little would stay
    Alex> the same.  OK, then, if that's the revolution that's in
    Alex> Python's future, let's see it come _first_ -- there would be
    Alex> huge wins without requiring any source code changes _IF_
    Alex> name-to-object resolution could be uniformly done at
    Alex> compile-time rather than at runtime, even across modules.

Ok, let's :-).

I figure the concept of "frozen" modules would need to be introduced:

python -f a.py b.py c.py

=> a.pyf b.pyf c.pyf

It would now be impossible to introduce new names in the module global
area. All the classes introduced in the module would be immutable,
i.e. no rebinding of methods. Attributes would work through
__slots__. Imports would need to only address other frozen modules
(which would apply to most of the standard library at some point :-).

Granted, it's not the laissez-faire Python we all know and love, but
many problems could be solved by using that kind of programming style
alone. Several more "sophisticated" frameworks could be able to use a
lean, "frozen" subset of classes and functions.

    Alex> I don't see "falling back" to a lower-level language where
    Alex> you need one as a disaster.  Doesn't have to be _AS_
    Alex> low-level as C# or Java or C, of course; I think pyrex does
    Alex> a great job of showing how a restricted Python
    Alex> dialect/variant which, among other things, includes optional
    Alex> declarations, can make your life much easier.  I don't see

I admit that the concept of frozen modules is somewhere b/w an
additional lower level language and an extension to Python as an
idea. 

    Alex> couldn't be pyrex# or Jirex versions, or even languages
    Alex> inspired from Python but farther from it than Pyrex is, such
    Alex> as Bobo.

I assume you mean Boo here.

-- 
Ville Vainio   http://tinyurl.com/2prnb