On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote: [snip examples using class/__metaclass__ statements to create non-types] > >The question is, is the intent still clear? > > Depends on your use case. I'm just saying that the PEP would be tons > clearer if it started out by saying right up front that its goal is to > provide a prominent form of syntax sugar for __metaclass__ uses in cases > where the thing being create isn't particularly class-like.
Good point. I'll try to elaborate on that a bunch. > The PEP also doesn't explain why, for example, it shouldn't simply allow > 'callable' to be an arbitrary expression, invoked with > 'callable(name,namespace)'. I'd presume this is to allow backward > compatibility with metaclasses... except the statement is for making > things that *aren't* classes, so why is compatibility needed? > > The PEP also doesn't explain why the particular syntax order is > chosen. Why is it "make callable name(tuple):" and not, say, "make > name(tuple) from callable:" or "name = callable(tuple):" (which doesn't > require a new keyword). Thanks for the feedback. I'll put that into the PEP too, but in short the answer is that the particular syntax follows the class syntax exactly except that "class" is replaced by "make <callable>". There have been a lot of other proposals that try to introduce dramatically new syntax for these sorts of things, e.g. `Nick Coghlan's suggestion`_ to allow ** to indicate that keyword arguments would be supplied on the following block, e.g.:: options = dict(**): def option1(*args, **kwds): # Do option 1 def option2(*args, **kwds): # Do option 2 (Nick's doesn't solve the DRY issue when you need to know the name of the thing being created, but I'll ignore that for the moment.) Basically, I was trying to be as un-creative syntactically as possible, hoping that Python programmers would be able to translate their knowledge of how the class statement works into knowledge of how the make statement works. .. _Nick Coghlan's suggestion: http://mail.python.org/pipermail/python-3000/2006-April/000689.html STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com