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