PEP 359: The "make" Statement

[Steven Bethard]

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

STeVe