anygui,anydb, any opinions?
jello at comics.com
Wed Jun 1 23:52:08 CEST 2005
"Thomas Bartkus" <tom at dtsam.com> wrote in
news:5uGdnfiX3aSnRADfRVn-1Q at telcove.net:
> "rzed" <jello at comics.com> wrote in message
> news:Xns9667883C1D343jreeder at 220.127.116.11...
>> So what do you think? What's wrong with the picture? Why isn't
>> there a greater priority to work in this direction?
> > What's wrong with the picture?
> Just one teeny little item.
> The Python world lacks the phenomenally successful development
> models enjoyed by the now ancient Turbo Pascal, Delphi and
> <gasp> Visual Basic.
> If the likes of Visual Basic can have it, then it becomes
> really, *really* hard to convince the world that Python is a
> serious, professional system.
> At some point, one has to break out of theory and produce!
> Or challenge the theory with some hard questions.
I'm not thinking only of a Drag & Drop graphical development
interface (and in fact there are several available now, all of
which work with some degree of similarity to VB). It might be nice
to have, but I've used a lot of systems that could crank out
tolerable windows with a relatively small amount of text entry.
Those who have used Cognos' Powerhouse, for instance, or Magic, or
even dBase (maybe that's a stretch) can testify to that, I think.
But there is a common need for production of systems where data-
entry and data views are required. Typically, the back end is a
database, though it need not be. It's not that hard to build such a
system using any one of the packages, particularly once you acquire
expertise with that package.
But should you want to switch to another package, you find that a
*lot* has to change in your applications, no matter how hard you've
tried to separate the presentation from the logic, just because the
requirements of the various systems differ so much. It might be
that you have to reorder parameter lists, or subtract parameters,
or insert some. Almost never can you simply use a different import
statement alone to change the underlying windows handler. If you
need to add new parameters, almost never can you simply append them
to an existing parameter list and expect the thing to work.
And if you do change to the new system, your code can no longer
work using the old system. A lot of this is just because of the way
interfaces are specified; for some call on system A you need, let's
say: (a)a label, (b)a size (which must be a tuple, not a list), (c)
a boolean value. Now you switch to system B, which does not name
the equivalent call the same, nor does it pass in the same
parameters, or not in the same sequence. Multiply this by all the
api calls you have, and you may as well start over with each
package as try to make it all work.
It seems to me that Python (the language, not the package) is
intended in part to make tasks like that easier. It would be better
if the call for a given function were named the same (in your
application code), and if you could simply append some new
parameters to make the new system function (knowing that its
interface would simply ignore the old parameters it did not
understand), well, that's not too hard, and it doesn't break the
old system. So you add what you need to (if you need to add
anything), and now you have a system that runs on two packages. All
you have to do is to import the one you have, or want to use.
It means the package writer has to create an API bridge, one that
maps the underlying package's api to the Python standard api. The
application writer doesn't or shouldn't have to worry about that
mapping. And it probably means that dictionaries (or something
similar) are used to pass most parameters.
This sounds chaotic, as though interfaces would suddenly be
impossible to document, but it need not be so. If a package has a
feature that cannot be mapped reasonably to the Python api, then
add to the Python api, or (as part of the Python api) allow a
system pass-through the package's api can interpret. If the package
doesn't get the information it needs, it will complain, just as it
does now. Its requirements will be documented just as they are now.
It's not that all applications would run on all systems without
change, but that essentially all *basic* applications would run on
any system that supported the same basic operations without change.
There are many widgets, and as windowing packages become slicker,
there are more options; eventually, as the options become universal
(or at least common) they would be added to the Python api.
Whether or not a D&D GDI would make this better would still be up
to the individual programmer, I'd think. It would be a heck of a
lot easier to *write* a GUI if you weren't overly concerned with
the underlying graphics package.
More information about the Python-list