By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,835 Members | 1,951 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,835 IT Pros & Developers. It's quick & easy.

updated pre-PEP: The create statement

P: n/a
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.

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. The ``create`` keyword was suggested by Nick
Coghlan.
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]_.

The create statement introduces a new keyword, ``create``. Thus in
Python 2.6, the create statement will have to be enabled with a
``from __future__ import create`` statement.
Open Issues
===========

Does the ``create`` keyword break too much code? An investigation of
the standard library by Michele Simionato [4]_ suggests some minor
breakage -- about eight instances. In particular, imaplib.IMAP4
objects expose a ``create()`` method, which could be problematic. Is
there a better keyword for the statement?

Instead of following the class statement precedent of a name, tuple
and namespace arguments, should the function be passed \*args and
\*\*kwargs arguments? This would allow things like::

create dict keymap:
A = 1
B = 2

and would simplify the new definition of property (in fact, the
current property signature shouldn't need to change at all). However,
this would pretty severely break the parallel with class statements.
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.
Removing __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.

Removing class statements in Python 3000
----------------------------------------

In the most extreme application of create statements, the class
statement itself could be deprecated in favor of ``create type``
statements.
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)
... [4] Instances of create in the stdlib
(http://mail.python.org/pipermail/pyt...il/335159.html)

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:
Apr 6 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.


Maybe I am thick this evening, but how that would work? It would break
for
classes if we do not follow the signature of 'type'. -1 unless you
explain me
what I am missing.

Michele Simionato

Apr 6 '06 #2

P: n/a
Michele Simionato wrote:
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.


Maybe I am thick this evening, but how that would work? It would break
for
classes if we do not follow the signature of 'type'. -1 unless you
explain me
what I am missing.


Yep, it would break for classes. The question is, what are the primary
use cases? If we believe this is just a replacement for classes, then
clearly the original translation is more appropriate. However, at the
moment, I don't think too many people are going to start replacing their
class statements with ``create type`` statements. So the create
statement doesn't have to be fully compatible with class statements.

I guess another way of asking the question is, are there existing
callables that could be used now with the (name, *args, **kwargs)
signature that couldn't be used with the (name, args, kwargs) signature?
If there are existing callables that could be immediately useful in a
create statement with no changes to their signature, then maybe it would
be better to cater to those. I'm not yet convinced that there are enough
such callables, but I'm willing to be convinced.

There were some errors in my Open Issues discussion of this. I've fixed
them:

http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html
STeVe
Apr 6 '06 #3

P: n/a
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.


Sorry, there were some errors in the copy of the PEP I posted with this
message. (The PEPs at the URLs above are correct though.) Here is the
corrected PEP:

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, 06-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. The ``create`` keyword was suggested by Nick
Coghlan.
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, namespaces could be created as simply as::

create namespace ns:
"""This creates a namespace named ns with a badger attribute
and a spam function"""

badger = 42

def spam():
...

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]_.

The create statement introduces a new keyword, ``create``. Thus in
Python 2.6, the create statement will have to be enabled with a
``from __future__ import create`` statement.
Open Issues
===========

Does the ``create`` keyword break too much code? An investigation of
the standard library by Michele Simionato [4]_ suggests some minor
breakage -- about eight instances. In particular, imaplib.IMAP4
objects expose a ``create()`` method, which could be problematic. Is
there a better keyword for the statement?

Instead of following the class statement precedent of a name, tuple
and namespace arguments, should the function be passed a name, \*args
and \*\*kwargs arguments? This might make the create statement usable
with more existing callables since (name, \*args, \*\*kwargs) matches
more function signatures than (name, args, kwargs). However, changing
the create-statement translation in this manner would break
compatibility with class statements and metaclass usage.
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.::

namespace ns:
badger = 42
def spam():
...

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.
Removing __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.

Removing class statements in Python 3000
----------------------------------------

In the most extreme application of create statements, the class
statement itself could be deprecated in favor of ``create type``
statements.
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)
... [4] Instances of create in the stdlib
(http://mail.python.org/pipermail/pyt...il/335159.html)

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:
Apr 6 '06 #4

P: n/a
Steven> Optional Extensions
Steven> ===================

Steven> Remove the create keyword
Steven> -------------------------

Steven> It might be possible to remove the create keyword so that such
Steven> statements would begin with the callable being called, e.g.::

Steven> namespace ns:
Steven> badger = 42
Steven> def spam():
Steven> ...

Steven> interface C(...):
Steven> ...

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

Someone mentioned using "make" instead of "create". In both my own code as
well as the Python source, use of "make" is much less prevalent than
"create".

Even if you figure out a way to not use a keyword, I wouldn't do that. I
believe almost all Python statements begin with a keyword. The one notable
exception is the assignment statement.

Skip
Apr 7 '06 #5

P: n/a
sk**@pobox.com wrote:
Steven> Optional Extensions
Steven> ===================

Steven> Remove the create keyword
Steven> -------------------------

Steven> It might be possible to remove the create keyword so that such
Steven> statements would begin with the callable being called, e.g.::

Steven> namespace ns:
Steven> badger = 42
Steven> def spam():
Steven> ...

Steven> interface C(...):
Steven> ...

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

Someone mentioned using "make" instead of "create". In both my own code as
well as the Python source, use of "make" is much less prevalent than
"create".
Yep. The next version of the PEP will use "make" instead of "create". I
want to update the patch first though, and that takes a little bit longer.
Even if you figure out a way to not use a keyword, I wouldn't do that. I
believe almost all Python statements begin with a keyword. The one notable
exception is the assignment statement.


That's been my feeling too, especially because without the keyword,
looking up the construct in the documentation becomes much more difficult.

STeVe
Apr 7 '06 #6

P: n/a
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.


Meh. I don't think the args, kwargs is a good idea at all, and wasn't
suggesting that. For this construction not to apply to type objects
would be a mistake. I wanted us to consider whether it was a problem
for it not to work in certain useful cases (such as dicts), and whether
it was deal-breaking, and what to do about it if not.

Off the top of my head, a simple way to make this work for both types
and dicts is to have a special static method called __make__ (or
__create__) that is called by this syntax. For type objects, __make__
is a synonym for __new__. For dict, it can call __new__ with the third
argument.
Carl Banks

Apr 7 '06 #7

P: n/a
Carl Banks wrote:
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.


Meh. I don't think the args, kwargs is a good idea at all, and wasn't
suggesting that. For this construction not to apply to type objects
would be a mistake. I wanted us to consider whether it was a problem
for it not to work in certain useful cases (such as dicts), and whether
it was deal-breaking, and what to do about it if not.

Off the top of my head, a simple way to make this work for both types
and dicts is to have a special static method called __make__ (or
__create__) that is called by this syntax. For type objects, __make__
is a synonym for __new__. For dict, it can call __new__ with the third
argument.


I've updated the PEP along these lines, and I've now submitted it for a
PEP number. The current drafts are now at:

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

I'll post them again once I get a PEP number.

STeVe
Apr 7 '06 #8

P: n/a
Steven Bethard wrote:
I've updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:

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

In this post, I'm especially soliciting review of Carl Banks's point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:

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

instead of the current:

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

The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.
.... 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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.

Cheers, az.
Apr 10 '06 #9

P: n/a
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe
Apr 11 '06 #10

P: n/a
Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...

I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe

You've probably considered this, but I didn't see it in the PEP. How about
returning an dict with 'history' for the namespace, e.g. in essence:

class HistoryDict(dict):
def __init__(self, *a, **kw):
self.history = []
super(HistoryDict, self).__init__(*a, **kw)
def __setitem__(self, k, v):
self.history.append((k, v))
super(HistoryDict, self).__setitem__(k, v)

this would behave as a normal dict, but the additional history attribute could
be useful in cases where order or duplicated names are significant, such as the
xml example above, database table descriptions, overloaded function definitions...

Michael

Apr 11 '06 #11

P: n/a

Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe

Honestly, I don't want the 'create' statement to be used to write XML
in Python. I think this would be a misuse of the functionality. OTOH
I believe that the main selling point for the 'create' statements is
that it make it easy to implement declarative minilanguages, so I have
given an XML example. To solve the ordering issue one should change
the internals of Python, in such a way to pass an ordered dict to the
'create' statement instead of an usual dictionary. I think the main
use case for 'create' would be in things like
object-relational-mappers, not in XML generation. You can pull out the
example in the official PEP, if you like. It was just matter for
thought.

Michele Simionato

Apr 11 '06 #12

P: n/a
Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe


Honestly, I don't want the 'create' statement to be used to write XML
in Python.
I think this would be a misuse of the functionality. OTOH I believe
that the main selling point for the 'create' statements is that it make
it easy to implement declarative minilanguages, so I have given an XML
example. To solve the ordering issue one
should change the internals of Python, in such a way to pass an ordered
dict
to the 'create' statement instead of an usual dictionary.
I think the main use case for 'create' would be in things like
object-relational-mappers,
not in XML generation. You can pull out the example in the official
PEP, if you like.
It was just matter for thought.

Michele Simionato

Apr 11 '06 #13

P: n/a
Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?


Honestly, I don't want the 'create' statement to be used to write XML
in Python. I think this would be a misuse of the functionality. OTOH
I believe that the main selling point for the 'create' statements is
that it make it easy to implement declarative minilanguages, so I have
given an XML example. To solve the ordering issue one should change
the internals of Python, in such a way to pass an ordered dict to the
'create' statement instead of an usual dictionary. I think the main
use case for 'create' would be in things like
object-relational-mappers, not in XML generation. You can pull out the
example in the official PEP, if you like. It was just matter for
thought.

Michele Simionato

Apr 11 '06 #14

P: n/a
Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe


Honestly, I don't want the 'create' statement to be used to write XML
in Python.
I think this would be a misuse of the functionality. OTOH I believe
that the main selling point for the 'create' statements is that it make
it easy to implement declarative minilanguages, so I have given an XML
example. To solve the ordering issue one
should change the internals of Python, in such a way to pass an ordered
dict
to the 'create' statement instead of an usual dictionary.
I think the main use case for 'create' would be in things like
object-relational-mappers,
not in XML generation. You can pull out the example in the official
PEP, if you like.
It was just matter for thought.

Michele Simionato

Apr 11 '06 #15

P: n/a
Steven Bethard wrote:
Azolex wrote:
Steven Bethard wrote:
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"
...


I think this is is a most important eventual use-case, and would like to
see it better worked out - or else declared outside the scope of the
proposed statement. As far as I can see, this does not cut it, since xml
and html allow /sequencial repetition/ of tags and the results of the
statement suites are passed as unordered namespaces/dicts.


Good point. The code above would only work if you didn't care about the
order of elements. I'm half inclined to pull the example, but the
original was due to Michele Simionato, and I haven't quite convinced
myself yet that you couldn't hack it to have ETObject append to an
internal list somehow to keep order. Michele? Did you have a plan for
how this would work?

STeVe


Honestly, I don't want the 'create' statement to be used to write XML
in Python.
I think this would be a misuse of the functionality. OTOH I believe
that the main selling point for the 'create' statements is that it make
it easy to implement declarative minilanguages, so I have given an XML
example. To solve the ordering issue one
should change the internals of Python, in such a way to pass an ordered
dict
to the 'create' statement instead of an usual dictionary.
I think the main use case for 'create' would be in things like
object-relational-mappers,
not in XML generation. You can pull out the example in the official
PEP, if you like.
It was just matter for thought.

Michele Simionato

Apr 11 '06 #16

P: n/a
Michele Simionato wrote:
Honestly, I don't want the 'create' statement to be used to write XML
in Python.
I think this would be a misuse of the functionality. OTOH I believe
that the main selling point for the 'create' statements is that it make
it easy to implement declarative minilanguages, so I have given an XML
example. To solve the ordering issue one
should change the internals of Python, in such a way to pass an ordered
dict ...
That solves "the ordering issue", but not the real issue, which is that
XML can have *multiple* elements with the same name (even though ids
must be unique, but that's irrelevant to the point here). Attributes on
an element are mappings, but elements are (nested) lists of items in
XML, not mappings.
You can pull out the example in the official
PEP, if you like.


Please do. If this is supposed to have anything to do with namespaces,
it has nothing to do with the type of data structures XML is capable of
and the presence of this example would only lead some people to think
there can't be a good use case for the whole idea if that's the best we
can come up with to demonstrate its benefits.

-Peter

Apr 11 '06 #17

P: n/a
Peter Hansen wrote:
Michele Simionato wrote:
> You can pull out the example in the official
PEP, if you like.


Please do. If this is supposed to have anything to do with namespaces,
it has nothing to do with the type of data structures XML is capable of
and the presence of this example would only lead some people to think
there can't be a good use case for the whole idea if that's the best we
can come up with to demonstrate its benefits.


Sorry for the multiple posting (Google failed me) and yes, let's remove
the XML example.

Michele Simionato

Apr 11 '06 #18

P: n/a
Michele Simionato wrote:
Peter Hansen wrote:
Michele Simionato wrote:
> You can pull out the example in the official
PEP, if you like.

Please do. If this is supposed to have anything to do with namespaces,
it has nothing to do with the type of data structures XML is capable of
and the presence of this example would only lead some people to think
there can't be a good use case for the whole idea if that's the best we
can come up with to demonstrate its benefits.


Sorry for the multiple posting (Google failed me) and yes, let's remove
the XML example.


Done. And thanks again everyone for the careful eyes!

STeVe
Apr 11 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.