[Pythonmac-SIG] Python RAD tools

[Kevin Altis]

I think you are missing the point I and some others are trying to make about
developing apps. What language, toolkits, etc. you as a developer use to
program your solution is independent of what the users of your program will
see and use. You say you want to create a frontend for databases with
scripting capabilities using Python as the scripting language and you want
it to be easy for non-programmers to use. Correct?

You could build that solution with C and embed Python. You could use tkinter
(maybe), you could use raw wxPython or PythonCard, you could probably even
create it with AppleScript Studio. The user won't know or care. What you
should care about is the time and effort involved in creating and
maintaining your solution and whether one language or toolkit simplifies
getting the behavior you're looking for better than others. I know that you
can dynamically add components, functions and methods and event handlers at
runtime using PythonCard and you should be able to do the same with tkinter
or some of the other Mac solutions MacPython developers already use. That
takes care of what could otherwise be a tough dynamic UI design problem,
since that sounds like one of your issues. If it isn't then the runtime
capabilities of your development solution are not as important.

We definitely have several people in the PythonCard group that are
specifically interested in apps doing almost exactly what you've described,
there is even a dbBrowser sample for viewing MySQL and Oracle databases that
will grow in capabilities, maybe like those you've described.

In general, you don't need to be concerned with runtime speed of the UI when
programming with Python, especially if native widgets are used. I can echo
the sentiments on using Python even for drawing operations. PythonCard has a
few samples that I was surprised to find run faster than the same algorithm
that I did as a Java applet. You won't be able to tell the difference
between C and Python for things like menus, dialog boxes, buttons, fields,
etc. and if there is a particular function that is slow for some reason like
a long drawing routine, then optimize that later and wrap it with Python.
This is common practice.

If you want a Mac-only solution, IB with Python bindings might in fact be
the best choice, I don't know. Obviously, if you want the potential of a
cross-platform solution, IB is out of the picture.

If what you really want is to program your own solution for fun or a sense
of accomplishment, whatever, that's also fine. The point I want to make is
that Python can do what you want. Your project does overlap others already
in progress, so if you want to contribute instead of going it alone that is
also good.

ka

> From: Adam Eijdenberg
>
> >> That looks a fine module, but it is approaching the problem from the
> >> opposite end of where I'm coming from. I don't want a Python program
> >> with native tie-ins, I want a native program that happens to use
> >> Python as a scripting language. Probably only just a philosophical
> >> difference, but hopefully it will become clearer as I progress a bit
> >> further.
> >
> > I understand what you are saying. However, I don't really think it's
> > all that different from what you are trying to achieve. The advantages
> > of using the Python interpreter as the application's main binary and
> > performing all OS-level API access using wrapped Python modules are
> > many. You don't have to deal with memory management, and you can write
> > your application in a much more dynamic fashion. The speed you gain by
> > going with a straight-c application which calls out to Python
> > occasionally is negligible.
>
> I'm not going for speed, I'm trying to target a lower-end user. You and
> I and probably most people on this list are developers. We can write
> programs from scratch in Python/C/Java/whatever takes our fancy.
> Although what I've done so far doesn't make the context clear, I want an
> environment where programming isn't the main emphasis. To reiterate, my
> eventual goal is to make a frontend for databases. Look at the scripting
> in FileMaker if you have it. Non programmers can write scripts in this.
> Programmers are frustrated by it. I want Python to achieve the middle
> ground within my application. If I manage to provide similar
> functionality in my final app (with preset "wizards" (in MS terminology)
> for common actions like in Access) then I feel I achieved something.
>
> Perhaps I chose an inappropriate title for this thread. For "real"
> programmers you probably are better off starting from scratch using
> modules such as your own or PythonCard. For a gentler introduction to
> programming, I think it would be nice not to have code as the central
> emphasis.
>
> Adam