PEP 359: The "make" Statement

[Azolex]

I think that's probably a bad idea because it would make people think
that the statement acts like a function definition, when it actually
acts like a class definition.

maybe this could be marked with an appropriate decorator ?

@namespace(mytype)
def ns(base1,base2) :
...

the decorator could take the function object apart, recover the bases
arguments, run the code with a referenced local dict...

hum, since in 2.4 exec allows a dict-like object as locals, it should
even be possible to hack together a pretty concise hierarchical xml
builder syntax embedded in current python - using neither the 'with' nor
the 'make' statement, but simply defs ! Note that only the root of the
(sub)tree would need to be a decorated "def" since embedded defs could
then be caught through the locals pseudo-dict.

Looks possible... at a first glance, the one thing that's unclear (to
me) is how to deal with closure variables. To learn more, my tendency
would be to launch a challenge :

"Simulate function call and execution using an exec statement, as
precisely as possible"

I'll repeat that question in another thread...

Best, az.

 

[gangesmaster]

?

i really liked it


-tomer

 

[Steven Bethard]

Here's code to do this. It would be probably be better to use elment
tree or some such instead of pushing out the HTML directly, but this
should get the idea across (testing using 2.5a1):

[snip]

Thanks, that's great! If you don't mind, I'm going to steal your code
for the PEP. I think it makes a pretty good case against expanding the
statement semantics to include customizing the dict in which the code is
executed.

STeVe

 

[Mike Orr]

I think this PEP is going off the rails. It's primary virtue was that it
was a simpler, clearer way to write:

class Foo(args):
__metaclass__ = some_metaclass
#...

And it doesn't even do that. What's wrong with "class Foo:
__metaclass__ = blah"? Two lines of code, and the double underscores
indicate something special is happening.

What I would most like to see is 'type' become the default metaclass
without having to type wait for Python 3000 or clutter the code with a
soon-to-be-redundant "(object)" base class. That would obviate my main
use of __metaclass__. How about "from __future__ import
classic_classes" for those few programs that really need old-style
classes?

 

[Carl Banks]

was a simpler, clearer way to write:

class Foo(args):
__metaclass__ = some_metaclass
#...

And it doesn't even do that. What's wrong with "class Foo:
__metaclass__ = blah"? Two lines of code, and the double underscores
indicate something special is happening.

I think you're missing the point somewhat. The real point isn't to
make using metaclasses easier; it's to let the useful semantics of the
class statement be used for things that aren't classes.

Example: I can define the following "metaclass":

def PropertyMaker(name,bases,pdict):
fget = pdict.get("get",None)
fset = pdict.get("set",None)
fdel = pdict.get("delete",None)
doc = pdict.get("__doc__",None)
return property(fget,fset,fdel,doc)

Then, I could define a property inside some class definition like this:

class some_attribute:
__metaclass__ = PropertyMaker
def get(self):
whatever
def set(self,value):
whatever

But the thing is, if I did that, I'd be lying bastard. I'd be using
the class statement and the __metaclass__ property; however, the object
I'm creating is not a class (it's a property), and the thing I'm
assigning to __metaclass__ is not a metaclass (it's a factory
function). With the make statement, I could instead write:

make property some_attribute:
def get(self):
# etc.

Then I'm not lying about it, and I'm using a more straightforward
syntax.

If this proposal were just about metaclasses, I agree that wouldn't be
important enough to justify a new statement. Metaclasses aren't too
common, and are generally used by experts who don't need the
straightforwardness the make statement would provide.

But, properties, dicts, and other things could benefit from some of the
semantics the class statement, and with the make statement, the average
user could take advantage of that without having to worry about all
this circumlocative metaclass hackiness.


Carl Banks

 

[Tim Hochberg]

I think you're missing the point somewhat. The real point isn't to
make using metaclasses easier; it's to let the useful semantics of the
class statement be used for things that aren't classes.

I can see how you might get the impression from the above paragraph, but
you'd be wrong.

Example: I can define the following "metaclass":

def PropertyMaker(name,bases,pdict):
fget = pdict.get("get",None)
fset = pdict.get("set",None)
fdel = pdict.get("delete",None)
doc = pdict.get("__doc__",None)
return property(fget,fset,fdel,doc)

Then, I could define a property inside some class definition like this:

class some_attribute:
__metaclass__ = PropertyMaker
def get(self):
whatever
def set(self,value):
whatever

But the thing is, if I did that, I'd be lying bastard. I'd be using
the class statement and the __metaclass__ property; however, the object
I'm creating is not a class (it's a property), and the thing I'm
assigning to __metaclass__ is not a metaclass (it's a factory
function). With the make statement, I could instead write:

make property some_attribute:
def get(self):
# etc.

Then I'm not lying about it, and I'm using a more straightforward
syntax.

If this proposal were just about metaclasses, I agree that wouldn't be
important enough to justify a new statement. Metaclasses aren't too
common, and are generally used by experts who don't need the
straightforwardness the make statement would provide.

But, properties, dicts, and other things could benefit from some of the
semantics the class statement, and with the make statement, the average
user could take advantage of that without having to worry about all
this circumlocative metaclass hackiness.

Here you've missed the point of my post. The post itself was not all
that clear, I admit, but had you read the subsequent followups, it would
have been clear that I wasn't arguing against the utility of the
statement (nor was I arguing for it), I was arguing against complicating
it for a useless use case. In particular making the namespace associated
with make statement into some sort of quasi namespace in order to
support the generating of HTML seems foolish for two reasons. First, it
doesn't actually work in any but the most trivial of cases. Second,
there is an existing syntax (as of 2.5) that can fill the same roll,
only it actually works, specifically the 'with' statement.

Regards,

-tim

 

[Carl Banks]

I can see how you might get the impression from the above paragraph, but
you'd be wrong.
???

From the above post, I got the impression that it was Mike Orr that

wrote it, not you. If you and he are really the same person, you must
admit I would have no reasonable way to get any other impression.

No really, are you sure I was replying to what you think I was replying
to? I totally agree with you about the XML thing; it'd be a terrible
misuse of the make statement. But the post I responded to had nothing
to do with that.


Carl Banks

 

[Tim Hochberg]

wrote it, not you. If you and he are really the same person, you must
admit I would have no reasonable way to get any other impression.

No really, are you sure I was replying to what you think I was replying
to? I totally agree with you about the XML thing; it'd be a terrible
misuse of the make statement. But the post I responded to had nothing
to do with that.

My bad. I had a stack overflow or something when reading the nesting of
the post and missed who was replying to what.

Sorry,

-tim

 

[skip]

Carl> class some_attribute:
Carl> __metaclass__ = PropertyMaker
Carl> def get(self):
Carl> whatever
Carl> def set(self,value):
Carl> whatever

Carl> But the thing is, if I did that, I'd be lying bastard.... With
Carl> the make statement, I could instead write:

Carl> make property some_attribute:
Carl> def get(self):
Carl> # etc.

Carl> Then I'm not lying about it, and I'm using a more straightforward
Carl> syntax.

I agree. For the specific example of creating properties, you could
probably dream up some other syntax, but I suspect this notion will pop up
again. Even if you comment the heck out of a lying class definition, tools
like pylint and pychecker will think you're creating a class anyway and
incorrectly apply their class heuristics to your whatever-it-is.

Skip