"Thomas Bartkus" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> "rzed" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > <snip> >> 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. > AND > 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. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
