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

Pascal Costanza costanza at web.de
Sun Oct 26 18:40:48 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.

Yes, exactly! :)

> Perhaps I have become converted :)  I also think that this could fit in 
> nicely to the python environment.  Much more than I would have before. I 
> wouldn't use macros to change the language, but to provide fail-safe 
> handling for common tasks, sort of why I wanted to use python in the 
> first place.

Well, but that's exactly what language design is all about.

Consider the following two functions that both do the same thing:

(defun example-1 (x)
   (let ((i 0))
     (tagbody
       :loop
       (when (> i x) (go :end))
       (print i)
       (incf i)
       (go :loop)
       :end)))

(defun example-2 (x)
   (loop for i from 0 to x
         do (print i)))

EXAMPLE-1 requires lots of book-keeping in your head, especially when 
things get messier. EXAMPLE-2 uses a for loop "just" to reduce 
book-keeping and visual clutter. ;)


Pascal





More information about the Python-list mailing list