wxPython and macros (was: Why don't people like lisp?

Kenny Tilton ktilton at nyc.rr.com
Sun Oct 26 18:14:02 EST 2003



Brian Kelley wrote:
> Kenny Tilton wrote:
> 
>>
>>
>> mike420 at ziplip.com wrote:
>> <snip>
>>
>>>
>>> Conclusion: you don't need macros here.
>>> Moral: maybe you do not *deserve* macros.
>>
>>
>>
>> They are unworthy? :)
>>
>> You know, I'll say it again, considering the audience (Pythonistas 
>> debating amongst themselves whether to have macros) Lispniks should 
>> have emphasized from the get-go that one of the things macros do is 
>> clean up code visually (as demonstrated above). Some think I over-use 
>> macros, but I think I do so precisely because, like Pythonistas, I 
>> place a premium on visually clean code.
> 
> 
> < snip>
> 
>> Now one very good point is that macros are a big change to make an 
>> already clean-looking language cleaner. ie, The added value may not be 
>> so great in Python as in other languages because another way 
>> (indentation) was found to clean up code (and in my experience the 
>> improvement is dramatic.
>>
> 
> After debating this topic, I have a slightly better understanding of how 
> I would use macros if they existed in python.  My thinking is pretty 
> much dealing with book-keeping and resource handling.
> 
> Specifially talking about wxPython, in some class constructors, any non 
> handled exception (in, for example, wxFrame) can crash the application 
> with no tracebacks.  Additionally, when subclassing some wxPython 
> classes, the base class *must* be called first.  These issues could be 
> solved with macros in a perhaps clean fashion.  Naturally, you don't 
> *need* them, but they do reduce book-keeping and visual clutter in my 
> opinion.
> 
> class wxFrame:
>   def __init__(self, ...):
>     with wxFrame_init(self, ...):
>      special constructor code here
> 
> 
> as opposed to
> 
> class wxFrame:
>    def __init__(self, ...):
>     wxFrame.__init__(self, arguments)
>     try:
>       special constructor code here
>     except ...:
>       # handle errors, perhaps writing to a log
>       #  close down the application with an appropriate
>       #  error message
> 

Is the above meant to be for, say, wxFrame3D, a subclass of wxFrame?

Anyway...Yep. Any time there is boilerplate code one can slap it into a 
macro. In the end only the bit that is different gets coded, so it 
stands out more clearly and code is easier to read.

Now the million dollar question is: how could the longer version above 
be cleaned up without macros, with HOFs or a metaclass hack or something?

kenny

-- 
http://tilton-technology.com

Why Lisp?...

    http://alu.cliki.net/RtL%20Highlight%20Film





More information about the Python-list mailing list