pre-PEP: The create statement

[Carl Banks]

Steven Bethard wrote:
> This PEP proposes a generalization of the class-declaration syntax,
> the ``create`` statement. The proposed syntax and semantics parallel
> the syntax for class definition, and so::
>
>     create <callable> <name> <tuple>:
>         <block>
>
> is translated into the assignment::
>
>     <name> = <callable>("<name>", <tuple>, <namespace>)
>
> where ``<namespace>`` is the dict created by executing ``<block>``.
> The PEP is based on a suggestion [1]_ from Michele Simionato on the
> python-dev list.

And who needs a class statement after that?

create type A:
    <block>

That's probably even more readable than class A, if not as familiar.
My biggest concern with this is the special arguments of the caller.
It breaks my heart that we couldn't do something like this:

create dict keymap:
    A = 1
    B = 2

And it'll probably confuse people as well.  We ought to keep that in
mind.


> Of course, properties are only one of the many possible uses of the
> create statement. The create statement is useful in essentially any
> situation where a name is associated with a namespace. So, for
> example, sub-modules could be created as simply as::
>
>      create module mod:
>          "This creates a sub-module named mod with an f1 function"
>
>          def f1():
>              ...

Let's not do this, really.  A module should be one-to-one with a file,
and you should be able to import any module.  Having in-line modules
complicates everything.  And it becomes a misnomer.  So, please, let's
get a better example.  If you must, call it a scope or namespace.


> Remove the create keyword
> -------------------------
>
> It might be possible to remove the create keyword so that such
> statements would begin with the callable being called, e.g.:
>
>      module mod:
>          def f1():
>              ...
>          def f2():
>              ...
>
>      interface C(...):
>          ...

I don't like it.  It seems to violate the spirit of the pronouncement
on programmable syntax.  I presume if it passes then "class" would
become a regular symbol and a synonym of "type".

Overall, it seems like an idea worth considering.  In fact, I'd be in
favor of phasing out "class" in favor of "create type" in the interests
of there being only one obvious way to do it.  (Obviously not before
Python 3000, though.  The thing is, because the usage of "class" varies
so little, updating code to use "create type" would be pretty
automatic).

Carl Banks