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

[mike420]

Tayss wrote:

app = wxPySimpleApp()
frame = MainWindow(None , -1, "A window")
frame.Show(True )
app.MainLoop()

Why do you need a macro for that? Why don't you just write

def start_window(na me) :
app = wxPySimpleApp()
frame = MainWindow(None , -1, name)
frame.Show(True )
app.MainLoop()
return (app, frame)

Macros are used for other things!

With this function, you can do

app, frame = start_window("a window")
app.do_stuff()
frame.do_whatev er()

With a "macro" (if Python had them), you could define
with_open_windo w(name), and do

with_open_windo w("a window")
app.do_stuff()
frame.do_whatev er()

Conclusion: you don't need macros here.
Moral: maybe you do not *deserve* macros.

[Brian Kelley]

Tayss wrote:

Ok, now being sober...
mi*****@ziplip. com wrote:

Why do you need a macro for that? Why don't you just write

def start_window(na me) : # 1
app = wxPySimpleApp() # 2
frame = MainWindow(None , -1, name) # 3
frame.Show(True ) # 4
app.MainLoop() # 5
return (app, frame) # 6

Remember that we lose this game if lines #2-5 are executed out of
order. The system crashes.

<snip> Your example above is sensible, because we don't have the power to do
anything more meaningful. So we're stuck with some trivial function
that does nothing really important. Boa Constructor, the great Python
IDE, pops up three windows of different kinds and names on startup,
but /we/ are stuck with the trivial ability to customize one window's
name.

This isn't really the case I think, we just have a different idiom for
doing something more meaningful. The solutions in the wxPython world
that I have seen do something like this:

class Application:
def __init__(self, name):
app = wxPySimpleApp()
self.name = name
try:
self.createAppl ication()
app.MainLoop()
except Exception:
# report on applicatino failure
# and close down properly
raise

def createApplicati on(self):
"""create your application here"""
# note, the window name is name
raise NotImplementedE rror

So know the usage is

class MyApp(Applicati on):
def createApplicati on(self):
frame = self.frame = wxFrame(None, -1, self.name)
frame.Show()

app = MyApp("test")

So there are non-macro solutions to these issues that are equally
expressive in some cases. This is just more verbose than the
corresponding macro solution, I still think that it is quite readable
though.

app.app = application
app.frame = main window

Brian.

[Anthony Briggs]

At 3:10 AM -0800 27/10/03, Tayss wrote:

mi*****@ziplip .com wrote:

Why do you need a macro for that? Why don't you just write

> def start_window(na me) : # 1
> app = wxPySimpleApp() # 2
> frame = MainWindow(None , -1, name) # 3
frame.Show(True ) # 4
app.MainLoop() # 5
> return (app, frame) # 6

Notice in #1, you used a string ("name") as the parameter. But that's
weird, you'd rather have all of line #3 as the param, not just the
little string part of it. So why can't you do that?

Why don't you do something like this?

def start_window(ap pfunction, framefunction) : # 1
exec("app = "+appfuncti on) # 2
exec("frame = "+framefunction ) # 3
frame.Show(True ) # 4
app.MainLoop() # 5
return (app, frame) # 6

start_window( "wxPySimpleApp( )", "MainWindow(Non e, -1, name)") # 7

Anthony
--
----------------------------------------------------
HyPEraCtiVE? HeY, WhO aRE YoU cALliNg HypERaCtIve?!
aB*****@wEStNeT .cOm.aU
----------------------------------------------------

[Tayss]

Brian Kelley <bk*****@wi.mit .edu> wrote:

This isn't really the case I think, we just have a different idiom for
doing something more meaningful. The solutions in the wxPython world
that I have seen do something like this:

This OOP solution looks like the functional one I mentioned earlier,
freezing code in a subclass's function instead of a plain function.
http://groups.google.com/groups?q=g:...ing.google.com

But since GUIs often lend themselves well to OOP, I can see this as a
resourceful way to solve this special case. Making sure that
superclass.__in it__() is always called and deciding early to structure
the entire App with OOP. I'm not a fan of calling overridden methods
from an old init, but life could hurt worse.

-- Tayssir

[Kenny Tilton]

Kenny Tilton wrote:

Pascal Costanza wrote:

Brian Kelley wrote:

Kenny Tilton wrote:

mi*****@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).
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! :)

And to think someone said I do not know anything about marketing?

An emailer just asked if my objective was to market Lisp or macros. The
answer is macros. The whole thread (even The Fat Five Hundred) has seen
Lispniks speaking up in defense of macros in the abstract. I cannot
speak for others, but my feeling is: it would be a shame for Pythonistas
to miss out on something good for the wrong reasons.

btw, regarding my use of the M word, marketing can be evil (witness Joe
Camel) but in the general case it is just about communicating
effectively by considering the listener.

btw^2, anything a Lispnik says that makes macros happen in Python is bad
for Lisp, because then there is one less (huge) reason to check out
Lisp. we need folks to help develop more libraries and Pythonistas are
good at that. (Lispniks just sit around and moan on NGs.) So...hmmm...

MACROS SUCK!

:)

kenny

--
http://tilton-technology.com

Why Lisp?...

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

[Tayss]

Kenny Tilton <kt*****@nyc.rr .com> wrote in message news:<az******* *************@t wister.nyc.rr.c om>...

btw, regarding my use of the M word, marketing can be evil (witness Joe
Camel) but in the general case it is just about communicating
effectively by considering the listener.

I got an interesting email too, this one with the novel solution (at
least to me) of using "" around Python code like a lisper would use '.
He'd then parse and execute it using the exec statement. To think
that one year ago I might have dismissed such code for vague
reasons... And now it seems like a normal thing to do, except for the
fact it's not a style encouraged by Python with tools, libs and docs.

So there are Python users who naturally think in a Lisp. I was
probably in that situation. So some level of "marketing" is good when
it provides good info for people who are searching for something.

This thread is weird though. My position morphed from "macros would
keep me from making unfortunate tradeoffs" to "macros are the only
solution!!! Bow to lisp!!!" Maybe trolls are very good at telling
you about yourself, and I just need to embrace the inner lisp weenie
or something. Or maybe I'm working with code too much lately and
obsessing over perfection.

[Kenny Tilton]

Tayss wrote:

Kenny Tilton <kt*****@nyc.rr .com> wrote in message news:<az******* *************@t wister.nyc.rr.c om>...

btw, regarding my use of the M word, marketing can be evil (witness Joe
Camel) but in the general case it is just about communicating
effectively by considering the listener.

I got an interesting email too, this one with the novel solution (at
least to me) of using "" around Python code like a lisper would use '.
He'd then parse and execute it using the exec statement. To think
that one year ago I might have dismissed such code for vague
reasons... And now it seems like a normal thing to do, except for the
fact it's not a style encouraged by Python with tools, libs and docs.

So there are Python users who naturally think in a Lisp. I was
probably in that situation. So some level of "marketing" is good when
it provides good info for people who are searching for something.

yep. the interesting thing is that you cannot just leave the information
on the doorstep and assume it will get recognized as cool by the
inhabitants. i know, having ignored MCL ads (big long detailed ones in
APDA catalogs) for weeks during a search which ended up with delirious
delight... at MCL!

This thread is weird though. My position morphed from "macros would
keep me from making unfortunate tradeoffs" to "macros are the only
solution!!! Bow to lisp!!!"
Twist our arms. :)

Maybe trolls are very good at telling you about yourself, and I just need to embrace the inner lisp weenie
or something. Or maybe I'm working with code too much lately and
obsessing over perfection.

If you go here:

http://alu.cliki.net/Kenny's%20RtLS% 20Top-Ten

.... the current #2 favorite story of mine is about a fellow effectively
trying to hack GCC so the source he wrote could include hints to the
compiler as to how best to "write" the assembler output. A GCC guru told
him, "You are looking for Lisp."

I like this story because the fellow honestly was trying very hard to
get something done, /not/ looking for an excuse to do Lisp. It just
turned out that his requirement mapped onto something (compiler macros,
a special kind of macro) Lisp does --not by design-- but as a
consequence of other fortuitous design decisions.

This long "to macro or not to macro" thing has been unfortunate in that
it has been conducted in the abstract, without actual code to point to
that some Pythonista macro advocate argues could be improved only with
macros. Is there a formal proposal on the table with such a thing?

kenny
--
http://tilton-technology.com

Why Lisp?...

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

[Kaz Kylheku]

mi*****@ziplip. com wrote in message news:<AP******* *************** *************** *@ziplip.com>.. .

Tayss wrote:

app = wxPySimpleApp()
frame = MainWindow(None , -1, "A window")
frame.Show(True )
app.MainLoop()

Why do you need a macro for that? Why don't you just write

def start_window(na me) :
app = wxPySimpleApp()
frame = MainWindow(None , -1, name)
frame.Show(True )
app.MainLoop()
return (app, frame)

Macros are used for other things!

In conjunction with wxWindows, macros are indeed useful. The C++
library itself has, for instance, a WX_IMPLEMENT_AP P macro that
implements the application: you just name the root class. It also has
message map macros which bind messages by event and control ID to
class methods.

I started working on Lisp wrappers for wxWindows which provide Lisp
versions of these macros.

The example goes something like this:

(use-package :wx)

(defclass my-app (app) ())
(defclass my-frame (frame) ())

;; save command
(defmethod on-save ((frame my-frame) (event event))
(format t "my-frame::on-save~%"))

;; print command
(defmethod on-print ((frame my-frame) (event event))
(format t "my-frame::on-print~%"))

;; button click
(defmethod on-foo-clicked ((frame my-frame) (event event))
(format t "my-frame::on-foo-clicked~%"))

;; Message map: Lisp macro.

(define-message-map my-frame
(menu-event
(:save on-save)
(:print on-print)
(command-event
(:foo on-foo-clicked))
(close-event on-close))

;; Application macro, just like in a WxWindows C++ program.
;; There has to be an ON-INIT method specialized for the MY-APP
class!

(implement-app my-app)

Note that instead of the integer control ID's used in the C++ realm,
we use keyword symbols! So there is nothing to declare. In ON-INIT,
you create the button with the control identifier :FOO, and that's
what you refer to in your map or elsewhere. Whereas the C++ programmer
has a silly chore of maintaining a header file that defines symbolic
constants for control ID's and things.

Writing the ON-INIT method in the application class is a chore,
because of the function call interface used for constructing the GUI.
This would be another good candidate for macrology. Ideally, there
should be a simplified description language which defines the elements
of the GUI, and is translated into the object constructor calls.

Wait, isn't this what resource files or scripts are in dumb
programming environments? These are just simplified, condensed
languages for defining GUI layouts so you don't have to write them in
the awful language you are using to develop the rest of the program.
;)