pre-PEP: The create statement

[Steven Bethard]

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html

PEP: XXX
Title: The create statement
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Steven Bethard <st************@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006
Abstract
========

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.
Motivation
==========

Class statements provide two nice facilities to Python:

(1) They are the standard Python means of creating a namespace.
All statements within a class body are executed, and the resulting
local name bindings are passed as a dict to the metaclass.

(2) They encourage DRY (don't repeat yourself) by allowing the
class being created to know the name it is being assigned.

Thus in a simple class statement like::

class C(object):
x = 1
def foo(self):
return 'bar'

the metaclass (``type``) gets called something like::

C = type('C', (object,), {'x':1, 'foo':<function foo at ...>})

The class statement is just syntactic sugar for the above assignment
statement, but clearly a very useful sort of syntactic sugar. It
avoids not only the repetition of ``C``, but also simplifies the
creation of the dict by allowing it to be expressed as a series of
statements.

Historically, type instances (a.k.a. class objects) have been the
only objects blessed with this sort of syntactic support. But other
sorts of objects could benefit from such support. For example,
property objects take three function arguments, but because the
property type cannot be passed a namespace, these functions, though
relevant only to the property, must be declared before it and then
passed as arguments to the property call, e.g.::

class C(object):
...
def get_x(self):
...
def set_x(self):
...
x = property(get_x, set_x, ...)

There have been a few recipes [2]_ trying to work around this
behavior, but with the new create statement (and an appropriate
definition of property), the getter and setter functions can be
defined in the property's namespace like::

class C(object):
...
create property x:
def get(self):
...
def set(self):
...

The definition of such a property callable could be as simple as::

def property(name, args, namespace):
fget = namespace.get('get')
fset = namespace.get('set')
fdel = namespace.get('delete')
doc = namespace.get('__doc__')
return __builtin__.property(fget, fset, fdel, doc)

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():
...

and named, nested hierarchies like XML documents could be created
like::

create ETobject html:
"This statement would generate an ElementTree object"

create ETobject head:
"generate the head"
...

create ETobject body:
"generate the body"
...

If Python acquires interfaces, given an appropriately defined
``interface`` callable, the create statement can support interface
creation through the syntax::

create interface C(...):
...

which would mean that interface systems like that of Zope would no
longer have to abuse the class syntax to create proper interface
instances.
Specification
=============

Python will translate a create statement::

create <callable> <name> <tuple>:
<block>

into the assignment::

<name> = <callable>("<name>", <tuple>, <namespace>)

where ``<namespace>`` is the dict created by executing ``<block>``.
The ``<tuple>`` expression is optional; if not present, an empty tuple
will be assumed.

A patch is available implementing these semantics [3]_.
Optional Extensions
===================

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(...):
...

However, this would probably add some complexity in the grammar and
so far I (Steven Bethard) have not been able to implement the feature
without the keyword.
Deprecating __metaclass__ in Python 3000
----------------------------------------

As a side-effect of its generality, the create statement mostly
eliminates the need for the ``__metaclass__`` attribute in class
objects. Thus in Python 3000, instead of::

class <name> <bases-tuple>:
__metaclass__ = <metaclass>
<block>

metaclasses could be supported by using the metaclass as the callable
in a create statement::

create <metaclass> <name> <bases-tuple>:
<block>

Removing the ``__metaclass__`` hook would simplify the BUILD_CLASS
opcode a bit.
References
==========

... [1] Michele Simionato's original suggestion
(http://mail.python.org/pipermail/pyt...er/057435.html)
... [2] Namespace-based property recipe
(http://aspn.activestate.com/ASPN/Coo.../Recipe/442418)
... [3] Create Statement patch
(http://ucsu.colorado.edu/~bethard/py/create_stmt.patch)

Copyright
=========

This document has been placed in the public domain.

...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:

[Paul Rubin]

I haven't looked at this enough to really understand it, but it looks
interesting and promising.

[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

[Paddy]

I wonder if the resulting code would look like Python.
It seems a great way to unify how things are defined, but I would not
want to mix the syntax with the current style.

- Pad.

[Michele Simionato]

Steven Bethard wrote:

The PEP is based on a suggestion [1]_ from Michele Simionato on the
python-dev list.

True, but I would also mention that the idea of the 'create' keyword
come from
Nick Coghlan:

http://mail.python.org/pipermail/pyt...er/057531.html
Michele Simionato

[bruno at modulix]

Steven Bethard wrote:

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html

PEP: XXX
Title: The create statement
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Steven Bethard <st************@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006
Abstract
========

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.

Seems mostly clean. +1.

(and I do prefer it with the 'create' statement - more explicit and
readable than Michele's original proposition IMHO).

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Serge Orlov]

bruno at modulix wrote:

Steven Bethard wrote:

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

[snip]

Seems mostly clean. +1.

That's what Trojans said when they saw a wooden horse at the gates of
Troy ;)

Serge.

[Michele Simionato]

bruno at modulix wrote:

Seems mostly clean. +1.

(and I do prefer it with the 'create' statement - more explicit and
readable than Michele's original proposition IMHO).

Well, I do agree ;)

Actually, Steven's original PEP draft was closer to my original
proposal,
but I suggested him to propose the PEP with the 'create' keyword, just
to have a nicer title ;)

Michele Simionato

[bruno at modulix]

Serge Orlov wrote:

bruno at modulix wrote:

Steven Bethard wrote:

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

[snip]

Seems mostly clean. +1.

That's what Trojans said when they saw a wooden horse at the gates of
Troy ;)

<sardonic-laughter>he he he...</sardonic-laughter>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Michael Ekstrand]

Carl Banks wrote:

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

Why couldn't you? Maybe I'm not reading carefully enough, but I didn't
see anything in the PEP prohibiting that. As long as dict knows how to
take arguments appropriately.

- Michael

--
mouse, n: a device for pointing at the xterm in which you want to type.
-- Fortune
Visit me on the Web: http://www.elehack.net

[Michael Ekstrand]

Steven Bethard wrote:

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html

PEP: XXX
Title: The create statement
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Steven Bethard <st************@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006
[large amount of crunchy goodness snipped]

+1 from me on this one.

Something it could be useful to try to add, if possible: So far, it
seems that this create block can only create class-like things (objects
with a name, potentially bases, and a namespace). Is there a natural way
to extend this to other things, so that function creation can be
modified? For example:

create tracer fib(x):
# Return appropriate data here
pass

tracer could create a function that logs its entry and exit; behavior
could be modifiable at run time so that tracer can go away into oblivion.

Given the current semantics of create, this wouldn't work. What would be
reasonable syntax and semantics to make something like this possible?

Maybe this would need to be a separate PEP. But it seems at least
somewhat related.

- Michael

--
mouse, n: a device for pointing at the xterm in which you want to type.
-- Fortune
Visit me on the Web: http://www.elehack.net

[Tim N. van der Leeuw]

>From what I read here it would make a huge useability improvement for
properties, and for that alone I would vote this a +1 if I were given
the right to vote.

Could this still make it in Python 2.5 even? If it's pushed hard
enough? I don't know if this has been discussed on the python-dev
mailing lists and what the reactions of python-devs and GvR was?

regards,

--Tim

[Kay Schluehr]

Steven Bethard wrote:

Python-Version: 2.6

Have you a rough estimation how many modules will be broken when
"create" is introduced as a keyword?

[Michele Simionato]

Kay Schluehr wrote:

Steven Bethard wrote:

Python-Version: 2.6

Have you a rough estimation how many modules will be broken when
"create" is introduced as a keyword?

This is a very relevant question. I would expect the new keyword would
break lots
of modules. However measuring is better than speculating.

$ echo count_name.py
"""
Count the occurrences of a name in a Python script. For instance:

$ find /usr/lib/python2.4 -name \*.py | xargs python2.4 count_name.py
create
"""

import sys, tokenize, token

def count_name(name, script):
"Count the occurrences of a Python name in a script"
counter = 0
for tok_code, tok_value, (srow, scol), (erow, ecol), line in \
tokenize.generate_tokens(file(script).readline):
if tok_code == token.NAME and tok_value == name:
counter += 1
print 'line %s: %s' %(srow, line),
if counter: print '*** %s ***\n' % script
return counter

if __name__ == '__main__':
name = sys.argv[1]
scripts = sys.argv[2:]
total = sum(count_name(name, script) for script in scripts)
print 'Found %d occurrences of %r' % (total, name)

Here is the output on my box:

line 132: def __init__(self, filename, dbhome, create=0,
truncate=0, mode=0600,
line 140: if create:
*** /usr/lib/python2.4/bsddb/dbtables.py ***

line 312: def get_finalized_command (self, command, create=1):
line 318: cmd_obj = self.distribution.get_command_obj(command,
create)
*** /usr/lib/python2.4/distutils/cmd.py ***

line 828: def get_command_obj (self, command, create=1):
line 835: if not cmd_obj and create:
*** /usr/lib/python2.4/distutils/dist.py ***

line 379: def create(self, mailbox):
*** /usr/lib/python2.4/imaplib.py ***

line 1569: self.tk = _tkinter.create(screenName, baseName,
className, interactive, wantobjects, useTk, sync, use)
*** /usr/lib/python2.4/lib-tk/Tkinter.py ***

[Steven Bethard]

Michael Ekstrand wrote:

Something it could be useful to try to add, if possible: So far, it
seems that this create block can only create class-like things (objects
with a name, potentially bases, and a namespace). Is there a natural way
to extend this to other things, so that function creation can be
modified? For example:

create tracer fib(x):
# Return appropriate data here
pass

tracer could create a function that logs its entry and exit; behavior
could be modifiable at run time so that tracer can go away into oblivion.

Given the current semantics of create, this wouldn't work. What would be
reasonable syntax and semantics to make something like this possible?

Maybe this would need to be a separate PEP. But it seems at least
somewhat related.

I think this probably needs a separate PEP. Function definitions are
really very different from class definitions. But feel free to write
that PEP. ;)

STeVe

[Michael Ekstrand]

Steven Bethard wrote:

Michael Ekstrand wrote:

Something it could be useful to try to add, if possible: So far, it
seems that this create block can only create class-like things (objects
with a name, potentially bases, and a namespace). Is there a natural way
to extend this to other things, so that function creation can be
modified? For example:

create tracer fib(x):
# Return appropriate data here
pass

tracer could create a function that logs its entry and exit; behavior
could be modifiable at run time so that tracer can go away into oblivion.

Given the current semantics of create, this wouldn't work. What would be
reasonable syntax and semantics to make something like this possible?

Maybe this would need to be a separate PEP. But it seems at least
somewhat related.

I think this probably needs a separate PEP. Function definitions are
really very different from class definitions. But feel free to write
that PEP. ;)

If I have extra time this summer, maybe. It'd be fun to write a PEP and
figure out how to add it in to Python. But that will definitely have to
wait until *after* semester tests, if I can even get to it at all...

- Michael

--
mouse, n: a device for pointing at the xterm in which you want to type.
-- Fortune
Visit me on the Web: http://www.elehack.net

[Sion Arrowsmith]

Kay Schluehr <ka**********@gmx.net> wrote:

Steven Bethard wrote:

Python-Version: 2.6

Have you a rough estimation how many modules will be broken when
"create" is introduced as a keyword?

A quick scan of the standard library suggests that it will have
a grand total of 3 modules requiring a fix (it's a method name
in imaplib and a named argument in a couple of places in bsddb
and distutils). Your own code my fare worse (mine does, but not
by much).

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Azolex]

Michele Simionato wrote:

Steven Bethard wrote:

The PEP is based on a suggestion [1]_ from Michele Simionato on the
python-dev list.

True, but I would also mention that the idea of the 'create' keyword
come from
Nick Coghlan:

http://mail.python.org/pipermail/pyt...er/057531.html
Michele Simionato

I'd advocate for the shortest possible keyword, and - maybe because
English is not my native language - I'd thus prefer "make" if any is
really required.

[Michele Simionato]

Sion Arrowsmith wrote:

Kay Schluehr <ka**********@gmx.net> wrote:

Steven Bethard wrote:

Python-Version: 2.6

Have you a rough estimation how many modules will be broken when
"create" is introduced as a keyword?

A quick scan of the standard library suggests that it will have
a grand total of 3 modules requiring a fix (it's a method name
in imaplib and a named argument in a couple of places in bsddb
and distutils). Your own code my fare worse (mine does, but not
by much).

This agrees with my scan (except I also found an occurrence of 'create'
in Tkinter).
BTW, I would be curious to see the script you are using for the
scanning. Are you
using tokenize too? In am quite fond of the tokenize module ;)

Michele Simionato

[Ron Adam]

Abstract
========

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.

I'll have to think on this one a bit. So I'm undecided for now.
Could it possibly use the 'as' keyword?

create <callable> <tuple> as <name>:
<block>

It has also been suggested that a pattern where functions and classes
are assigned be used. Possibly something like...

name = class():
<block>

name = def():
<block>

name = create():
<block>
Or it could be...

name = object():
<block>
This is a bigger change than adding the create keyword, (definitely not
a pre-P3k item), and I'm not sure if it fits your use case, but it does
allow for a larger variety of types without adding additional keywords.

Cheers,
Ron

[Steven Bethard]

Tim N. van der Leeuw wrote:

Could this still make it in Python 2.5 even? If it's pushed hard
enough? I don't know if this has been discussed on the python-dev
mailing lists and what the reactions of python-devs and GvR was?

Unlikely. I haven't posted it to python-dev yet, and they've basically
said that anything that isn't yet in the release schedule (`PEP 356`_)
won't make it into Python 2.5. I will try to post it there soon though
as it seems like it's gotten pretty good feedback.

... _PEP 356: http://www.python.org/dev/peps/pep-0356/

STeVe

[Sion Arrowsmith]

Michele Simionato <mi***************@gmail.com> wrote:

Sion Arrowsmith wrote:

A quick scan of the standard library suggests that it will have
a grand total of 3 modules requiring a fix (it's a method name
in imaplib and a named argument in a couple of places in bsddb
and distutils). Your own code my fare worse (mine does, but not
by much).

This agrees with my scan (except I also found an occurrence of 'create'
in Tkinter).
BTW, I would be curious to see the script you are using for the
scanning.

Old-fashioned egrep '\Wcreate\W' and eyeball out the false positives
8-) . I missed the Tkinter one because I don't appear to have it
installed.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Steven Bethard]

Carl Banks wrote:

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.

This is definitely an important point. I've thought about this a bit
and I'm still not sure which way is the right way to go on this. If the
tuple and dict arguments actually get passed as *args and **kwargs
arguments, the create statement could be used with a much wider variety
of existing callables. I've updated the open issues section of the PEP
to point this out.

STeVe

[Azolex]

Steven Bethard wrote:
....

Optional Extensions
===================

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(...):
as someone else noted, this is not the ideal example
...

However, this would probably add some complexity in the grammar and
so far I (Steven Bethard) have not been able to implement the feature
without the keyword.

Well, I can't pronounce myself on the technical difficulties, but I'd
like to point out that the proposal of the pep (especially without
keyword I'd say) offers part of what would be needed to endow python
with a standard bidirectional source-to-source transform to/fro xml. But
it might as well miss the opportunity...

I feel the python grammar offers more readable solutions (or
near-solutions) to the problems solved by the cumbersome grammar of xml.
So whenever I need to work with xml source or templates, I dream of a
reversible transformer that would allow me to work with a transparent
"mock-python" rendering of my xml file - it would replace closing tags
with indentations, attributes with keyword parameters syntax, cdatas
with triple quotes and perhaps xmlns with import statements - doing away
with all the unnecessary <xml/> cruft.

Symmetrically, I feel a (family of) standard xml rendition(s) of python
source would be quite useful. For one, it would facilitate access of
python source to vehicles designed for xml. For two, it would provide
python with an equivalent to lisp s-expression syntax. To illustrate :
imagine processing python source code using xslt over an xml
representation of python source with the relevant xslt itself expressed
in transparent python source.

So what I'd ideally want (and also to attract "foreign" programmers to
python) is to modify python syntax and semantics conservatively to eg
"xpython" that would make the following possible :

(a) given arbitrary "xpython" source code, there is a clearly obvious
way to express in xml a superficial parse of the code (ie a parse of
statement-level syntax).

(b) given arbitrary xml, there is a clearly obvious way to transform it
to mimetic "xpython" source code.

(c) the transforms are mutual inverses.

(d) running any "xpython" obtained from arbitrary xml will reconstruct
the original xml.

Similar wish, anyone ?

As relates to the pre-pep :

+1 for adding this general style of statement,

-0.5 on requiring a keyword,

-1 on choosing a *verb* keyword that forces to the imperative
interpretation of the code (since I'd want "xpython" to function as well
as a declarative language equivalent to xml)

-0.8 on the parameter syntax that restricts to positional parameters
while leaving out keyword arguments

Cheers.

[Michele Simionato]

Sion Arrowsmith wrote:

Michele Simionato <mi***************@gmail.com> wrote:

Sion Arrowsmith wrote:

A quick scan of the standard library suggests that it will have
a grand total of 3 modules requiring a fix (it's a method name
in imaplib and a named argument in a couple of places in bsddb
and distutils). Your own code my fare worse (mine does, but not
by much).

This agrees with my scan (except I also found an occurrence of 'create'
in Tkinter).
BTW, I would be curious to see the script you are using for the
scanning.

Old-fashioned egrep '\Wcreate\W' and eyeball out the false positives
8-) . I missed the Tkinter one because I don't appear to have it
installed.

I am impressed by your eyeball ability! I was unable to disentangle the
false
positive, so I was forced to write the script ;)

[Michele Simionato]

Carl Banks wrote:

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.

You are right, I think I am responsible for the wrong choice of the
name.
What I had in mind was a namespace or, if you wish, a named dictionary.
An simple-minded implementation could be

class Namespace(object):
def __init__(self, name, args, dic):
self.__name__ = name
self.__dict__.update(dic)

create Namespace keymap:
A = 1
B = 2

and nothing forbids to have the Namespace class in some module of the
standard
library ;)

Michele Simionato

[Steven Bethard]

Michele Simionato wrote:

Carl Banks wrote:

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.

You are right, I think I am responsible for the wrong choice of the
name.
What I had in mind was a namespace or, if you wish, a named dictionary.
An simple-minded implementation could be

class Namespace(object):
def __init__(self, name, args, dic):
self.__name__ = name
self.__dict__.update(dic)

create Namespace keymap:
A = 1
B = 2

I changed the PEP to use "namespace" instead of "module":

http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html
STeVe

[Terry Reedy]

"Azolex" <cr****@des.alpes.ch> wrote in message
news:44********@news.bluewin.ch...

I'd advocate for the shortest possible keyword, and - maybe because
English is not my native language - I'd thus prefer "make" if any is
really required.

While currently +0 on the proposal, I am +1 on 'make' versus 'create'.
Aside from the above, factories don't create things, they make them.

Terry Jan Reedy

[Terry Reedy]

"Michele Simionato" <mi***************@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

This is a very relevant question. I would expect the new keyword would
break lots
of modules. However measuring is better than speculating.

Please run also with alternatives, such as 'make'.

tjr

[Steven Bethard]

Terry Reedy wrote:

"Michele Simionato" <mi***************@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

This is a very relevant question. I would expect the new keyword would
break lots
of modules. However measuring is better than speculating.

Please run also with alternatives, such as 'make'.

I ran a check on my stdlib with 'make' and all I got was:

$ count_names.py make "C:\Program Files\Python\Lib"
*** C:\Program Files\Python\Lib\site-packages\win32\test\handles.py ***
line 73: def make():
line 77: make()
Found 2 occurrences of 'make'

So it only happens in testing code in the stdlib, which isn't bad
breakage-wise as far as I'm concerned. So it looks like 'make' is a
much better option. I'll probably update the PEP and the patch to use
'make' soon unless I hear good reasons not to.
FWIW, here's what I got with 'create':

$ count_names.py create "C:\Program Files\Python\Lib"
*** C:\Program Files\Python\Lib\imaplib.py ***
line 379: def create(self, mailbox):
*** C:\Program Files\Python\Lib\bsddb\dbtables.py ***
line 132: def __init__(self, filename, dbhome, create=0, truncate=0,
mode=0600,
line 140: if create:
*** C:\Program Files\Python\Lib\bsddb\test\test_dbtables.py ***
line 54: filename='tabletest.db', dbhome=homeDir, create=1)
*** C:\Program Files\Python\Lib\distutils\cmd.py ***
line 312: def get_finalized_command (self, command, create=1):
line 318: cmd_obj = self.distribution.get_command_obj(command,
create)
*** C:\Program Files\Python\Lib\distutils\dist.py ***
line 828: def get_command_obj (self, command, create=1):
line 835: if not cmd_obj and create:
*** C:\Program Files\Python\Lib\lib-tk\Tkinter.py ***
line 1569: self.tk = _tkinter.create(screenName, baseName,
className, interactive, wantobjects, useTk, sync, use)
*** C:\Program Files\Python\Lib\test\test_mhlib.py ***
line 264: def create(n):
line 268: create(7)
line 269: create(8)
line 270: create(9)
line 285: create(10)
line 286: create(11)
line 287: create(12)
*** C:\Program Files\Python\Lib\test\test_site.py ***
line 75: pth_file.create()
line 88: pth_file.create()
line 109: def create(self):
Found 19 occurrences of 'create'
And here's my slightly modified version of Michele's script:

import glob
import optparse
import os
import sys
import token
import tokenize

def count_name(name, filename):
"Count the occurrences of a Python name in a script"
counter = 0
tokens_gen = tokenize.generate_tokens(open(filename).readline)
for tok_code, tok_value, (srow, scol), _, line in tokens_gen:
if tok_code == token.NAME and tok_value == name:
if not counter:
print '*** %s ***' % filename
counter += 1
print 'line %s: %s' %(srow, line),
return counter

if __name__ == '__main__':
parser = optparse.OptionParser(usage='%prog name dir [dir ...]')
options, args = parser.parse_args()
try:
name = args[0]
args[1] # trigger an IndexError if no dirs are provided
dirnames = args[1:]
except IndexError:
parser.error('wrong number of arguments')
total = sum(count_name(name, os.path.join(dirpath, filename))
for dirname in dirnames
for dirpath, _, filenames in os.walk(dirname)
for filename in filenames
if filename.endswith('.py'))
print 'Found %d occurrences of %r' % (total, name)
STeVe

[Ben Cartwright]

Michael Ekstrand wrote:

Is there a natural way
to extend this to other things, so that function creation can be
modified? For example:

create tracer fib(x):
# Return appropriate data here
pass

tracer could create a function that logs its entry and exit; behavior
could be modifiable at run time so that tracer can go away into oblivion.

Given the current semantics of create, this wouldn't work. What would be
reasonable syntax and semantics to make something like this possible?

The standard idiom is to use a function wrapper, e.g.

def tracer(f):
def wrapper(*args):
print 'call', f, args
result = f(*args)
print f, args, '=', result
return result
return wrapper

def fact(x):
if not x: return 1
return x * fact(x-1)
fact = tracer(fact) # wrap it

The decorator syntax was added in Python 2.4 to make the wrapper
application clearer:

@tracer
def fact(x):
if not x: return 1
return x * fact(x-1)

http://www.python.org/dev/peps/pep-0318

--Ben

[Michele Simionato]

I think looking at the occurrences in the standard library only is
unfair. I have a large "Zope +Plone+my stuff" installation and I get
154 occurrences of 'create' but nearly 0 occurrences
of 'make' (only a few in Zope/lib/python/BTrees/tests/testSetOps.py). I
guess 'make' sounds
too Lispy, this is why it is never used in Pythonland.

Michele Simionato

[jantod]

Serge Orlov wrote:

bruno at modulix wrote:

Steven Bethard wrote:

The PEP below should be mostly self explanatory. I'll try to keep the
most updated versions available at:

[snip]

Seems mostly clean. +1.

That's what Trojans said when they saw a wooden horse at the gates of
Troy ;)

Serge.

QOTW!

[skip]

Michele> I think looking at the occurrences in the standard library only
Michele> is unfair.

In addition, when considering the standard library you need to search the
source repository, not just what's installed on your platform. I noticed in
your earlier post that you pointed your count_names script (very handy, btw)
at your /usr/lib/pythonN.M directory. Pointing it at the source repository
picks up stuff in the platform-dependent sections as well as searching
through other less-used code.

Michele> I guess 'make' sounds too Lispy, this is why it is never used
Michele> in Pythonland.

It doesn't seem lispish to me. OTOH, "make" seems more utilitarian than
"create". For instance, cooks make things while chefs create things.
Perhaps "make" is better anyway. The proposed statement is essentially a
namespace factory. I think of object factories as very utilitarian beasts.

Skip

[John J. Lee]

"Michele Simionato" <mi***************@gmail.com> writes:
[...]

This agrees with my scan (except I also found an occurrence of 'create'
in Tkinter).
BTW, I would be curious to see the script you are using for the
scanning. Are you
using tokenize too? In am quite fond of the tokenize module ;)

Having seen Sion's (non-existent) script, how about posting yours? I
regularly grep for things in Python code, and it hadn't occurred to me
that I could instead use module tokenize.

Module tokenize looks pretty simple, but would be nice to see some
code that has already been used.
John

[Steven Bethard]

John J. Lee wrote:

"Michele Simionato" <mi***************@gmail.com> writes:
[...]

This agrees with my scan (except I also found an occurrence of 'create'
in Tkinter).
BTW, I would be curious to see the script you are using for the
scanning. Are you
using tokenize too? In am quite fond of the tokenize module ;)

Having seen Sion's (non-existent) script, how about posting yours? I
regularly grep for things in Python code, and it hadn't occurred to me
that I could instead use module tokenize.

Module tokenize looks pretty simple, but would be nice to see some
code that has already been used.

Michele's code:
http://groups.google.com/group/comp....4e36ad10d78303

My derivative:
http://groups.google.com/group/comp....6dd53c267c7c77

STeVe

[BBands]

In the invaluable 'Dr. Dobb's Python-URL! - weekly Python news and
links' of April 17 Peter Otten writes: "Michele Simionato's little
script lets you search for a name in Python scripts, avoiding false
positives that a standard tool like grep would yield." Can someone
explain why this is so? I have attached the script below.

import sys, tokenize, token

def count_name(name, script):
"Count the occurrences of a Python name in a script"
counter = 0
for tok_code, tok_value, (srow, scol), (erow, ecol), line in \
tokenize.generate_tokens(file(script).readline):
if tok_code == token.NAME and tok_value == name:
counter += 1
print 'line %s: %s' %(srow, line),
if counter: print '*** %s ***\n' % script
return counter

if __name__ == '__main__':
name = sys.argv[1]
scripts = sys.argv[2:]
total = sum(count_name(name, script) for script in scripts)
print 'Found %d occurrences of %r' % (total, name)

jab--who laments the day that Doctor Dobbs' Journal of Computer
Callisthenics and Orthodontics changed its name.

[Fredrik Lundh]

"BBands" wrote:

In the invaluable 'Dr. Dobb's Python-URL! - weekly Python news and
links' of April 17 Peter Otten writes: "Michele Simionato's little
script lets you search for a name in Python scripts, avoiding false
positives that a standard tool like grep would yield." Can someone
explain why this is so?

consider grepping for "main" in this script:

def main():
# this is the main function
print "hello, main"

if __name__ == "__main__":
main()

a standard grep will find five instances. a word grep will find four. a name
token grep will find two.

</F>