Steven Bethard wrote:
> Tim Hochberg wrote:
>> Steven Bethard wrote:
>>> Steven Bethard wrote:
>>>> Duncan Booth wrote:
>>>>> make Element html:
>>>>> make Element body:
>>>>> make Element p:
>>>>> text('But this ')
>>>>> make Element strong:
>>>>> text('could')
>>>>> text(' be made to work')
>>>>
>>>> This is nice. I'll have to play around with it a bit to see how
>>>> hard it would be to make it work.
>>>
>>> Okay, I think it'll work[1]. I'm going to update this section to
>>> something more like:
>>>
>>>
>>> Open Issues
>>> ===========
>>>
>>> ...
>>>
>>> Should users of the make statement be able to determine in which dict
>>> object the code is executed? This would allow the make statement to
>>> be used in situations where a normal dict object would not suffice,
>>> e.g. if order and repeated names must be allowed. Allowing this sort
>>> of customization could allow XML to be written like::
>>
>> 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
>> #...
>>
>> Once it starts calling secret magic methods behind the scenes it's
>> losing that virture. And for what? Supporting some use cases that have
>> reasonable solutions already?
>
> That's why it's in the Open Issues section. I expect most of these open
> issues to be resolved by rejection. (At least, that's my preferred
> resolution.) But since they people have brought them up, I think they
> need to be addressed as completely as possible.
>
> But I think you make a good point that this particular case can be just
> as easily done using a with-statement (I think). I'll add that to this
> part of the PEP (once I'm sure it works).
Hmm... Actually, while the with-statement can probably help out with
the nesting, it doesn't help out with the DRY; you still have to repeat
the element name (once for the call to Element, and once as the name
that Element object is bound to).
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
