[FRPythoneers] Re: VB/Python article....
jafo at tummy.com
Mon Jun 4 19:05:23 MDT 2001
[I'm copying this to the FRPythoneers list, becase some of it's slightly
relavent to discussions we had there on Friday. -- SMR]
On Thu, May 31, 2001 at 01:51:52AM -0000, editor at pythonjournal.com wrote:
>>I am really pleased that someone is writing about the need to have a more
>>GUI oriented IDE for Python. I like Python a great deal. It is a super
I presume from the subject of this message, that you are talking about my
article "Python Like Visual Basic?" I'm curious though because the
contents of that have very little to do with "a more GUI-oriented IDE for
Python". The first paragraph mentions using VB as an example of how
approachable it is.
The real point of it was Python's strength for quickly building a
prototype, and then actually optimizing your REAL WORLD hot-spots, instead
of guessing at what they might be during the development.
>>simple notion of integrating the form building environment with the code
Python isn't a domain-specific language for building form-based
applications. So, for the general Python programmer at least, I don't see
that the integration you mention above would be beneficial. Maybe 1 out of
20 programs that I write use any sort of form-based interface, and then
I usually do it all web-based.
VB is targeted towards a very specific audience -- Windows users.
Unfortunately, Windows doesn't really do much from an OS standpoint to
allow the combining of applications. You can't just write a program that
is going to generate a bunch of output and let the user dictate that it
goes into a pager or editor. In fact, if you generate a bunch of output
to stdout, you can't even scroll back to see the last few lines of output.
So, the environment puts the burden on the application developer -- if I'm
going to generate a bunch of output, I'd better code in a way for the user
to view it, and possibly save it, better make it so they can print it as
well... Not suprising that a program that does a few hundred lines of
actual *WORK* pretty soon becomes megabytes of source code when using
Windows Wizards -- every application has all these things built into it as
a way of accounting for the lack of a general-purpose way of paging the
output of a program...
>> It's also about making intellisense like in-editor
>>object-drill-down work for us. This simple feature increases productivity
>>by an order of magnitude. You don't have to remember every single class or
>>object interface, and the exact spelling of properties and methods. Just
>>type a "dot" and there's the list.
I'd question wether you could justify even a two-fold increase in
productivity attributed to such things, let alone a ten-fold. Speaking as
a programmer, I don't spend anywhere NEAR 90% of my time (the minimum
required for a 10x improvement) trying to remember what methods are
available or how they are spelled.
In fact, I'd argue that there are very few situations where simply popping
up a list of the methods of an object are very helpful unless you already
know basically what you are looking for... I'm not really going to need to
use it for joining two strings (string.join), and it's not really going to
help me with encoding a string with '%' sequences (urllib.urlencode).
There are a variety of IDEs available for Python, and just last week Evelyn
was showing me one that did exactly what you mentioned. Personally, I
found it distracting, and that combined with being tied to the IDE's editor
instead of being able to use my own I figured would lead to an overall
decrease in productivity, my gut feeling was maybe as much as a half...
>>Just this alone is worth a fortune in programmer time.
To quote Brooks again, "There is no silver bullet". To the programmer who
is inexperienced with Python and it's libraries, yeah, it probably will
help. However, Brooks suggests that the average programmer is an order of
magnitude more productive than the inexperienced programmer. The
experienced programmer has a similar gain over the average programmer.
I feel fairly confident in saying that the such an IDE won't significantly
close either of the gaps above.
>>The fact that VB has a set GUI "library" works in that IDE's favor - but
>>against it's cross platform portability. Not having a GUI builder works
>>against Python, as well, as nobody can seem to decide what the best GUI
Why do you believe that Komodo, PythonWin, WingIDE, and IDLE (to name just
a few) are not sufficient in this regard?
>this library have besides the builtin tkinter of Python 1.6ff.? Something
>like Pmw megawidgets? Or pyGTK widgets? Or pyQt interfaces? Is the wx
I believe he's saying that it needs more GUI builders... As I said, I
don't really do much in the way of GUIs, so I don't really have any
experience with it. glade seems to be a good GUI builder for GTK, but I
don't use it often enough to really get proficient at it, let alone compare
and contrast to the dozens of other contenders out there...
>>I gotta give Microsoft credit where it is due. The VB IDE is not just
>>good, it's a GREAT IDE. Anyone who says otherwise does not know what they
>>are talking about. All the Python IDE's seem to focus on Colorizing Code
>>and debugging. That's it. Some progress seems to be being made on the
>>GUI front, but not much.
What exactly is it beyond debugging and syntax highlighting that you feel
is important? Certainly not a GUI for GUIs sake... A form designer/GUI
builder? Since that seems to largely be a Windows issue, why isn't it
Windows fault that they don't have a good cross-language GUI builder, for
>> work in both compiled and server side ASP
>>deployed applications (VB7 or .net or whatever they wind up calling
>>it). That gives them a "cross platform" (via browser) story. Where is
I didn't get the full quote here, but would suggest the following may be
relavent technologies (to name a few):
SOAP/XML-RPC (well-supported by Python, and the technology they're using
for .net, correct)
PyASP -- Python ASP.
In addition, you may wish to pursue the Active State presentations at
the March 2001 Python 9 conference where they discussed a lot of issues
related to providing services similar to and interoperating with .net.
In the Python community there's a lot of interest in .net because
apparently it will allow the complete replacement of VB on Windows
platforms. I'm not really close to that discussion though.
>mod_python 2.7.3 , www.modpython.org], and isn't there a python AOL Server
>under construction? How do these compare with the MS VB and ASP stuff --
There is a version of AOL Server which includes the ability to run Python
servelets in a very heavy-volume environment. I believe it was called
"WXPython" or "WXServer" (a name collision, it would seem with the
>>So, I say, just
>>pick a damn GUI library, and get on with it. Tkinter would be fine. Just
>>pick one. Finish a real, GUI building IDE and kick some MS butt! If the
>>Python community doesn't do it, then I don't know who will.
I presume you're just new to Python... You didn't mention any of the half
dozen (or more) VisualStudio-like environments avaiable for Python. Why so
many? They scratch different itches -- a good thing in my opinion...
So, why don't YOU pick an IDE, and describe in detail it's shortcomings...
>>I am really pleased that someone is writing about the need to have a more
>>GUI oriented IDE for Python. I like Python a great
>>deal. It is a super language. I am also an expert VB
>>developer / architect. So, I can speak to this issue.
>>Here is my opinion, for what it's worth.<br>
>>It's not just about prototyping. It's not just about RAD.
>>It's about the simple notion of integrating the form building environment
>>with the code editing environment. It's also about making
>>intellisense like in-editor object-drill-down work for us.
>>This simple feature increases productivity by an order of
>>magnitude. You don't have to remember every single class or object
>>interface, and the exact spelling of properties and methods. Just
>>type a "dot" and there's the list. Just this alone
>>is worth a fortune in programmer time.<br>
>>The fact that VB has a set GUI "library" works in that IDE's
>>favor - but against it's cross platform portability. Not having a
>>GUI builder works against Python, as well, as nobody can seem to decide
>>what the best GUI library is. My personal opinion is that
>>Tkinter and wx are the front runners for cross platform and
>>acceptability. Tk seems easier to deploy - a good reason to use it
>>if you want to actually distribute applications to a wider
>>I gotta give Microsoft credit where it is due. The VB IDE is not
>>just good, it's a GREAT IDE. Anyone who says otherwise does not
>>know what they are talking about. All the Python IDE's seem to
>>focus on Colorizing Code and debugging. That's it. Some
>>progress seems to be being made on the GUI front, but not much.<br>
>>It is really clear that Microsoft knows the value of what they
>>have. Now they are going to make VB forms work in both compiled and
>>server side ASP deployed applications (VB7 or .net or whatever they wind
>>up calling it). That gives them a "cross platform" (via
>>browser) story. Where is Python's?<br>
>>If Python had this kind of really productive IDE, it would give VB (.NET)
>>and the Visual Studio IDE a run for Microsoft's money.
>>So, I say, just pick a damn GUI library, and get on with it.
>>Tkinter would be fine. Just pick one. Finish a real,
>>GUI building IDE and kick some MS butt! If the Python community
>>doesn't do it, then I don't know who will.<br>
>>Thanks for listening. Good luck with your publication.<br>
>>PS. The opinions expressed above do not reflect those of Metagenix,
>>Inc. They are mine alone.<br>
>><tt>Robert Geiger, VP Product
> </x-tab>rgeiger at metagenix.com<br>
>>Inc<x-tab> </x-tab><x-tab> &n
>bsp; </x-tab><x-tab> </x
>nbsp; </x-tab><x-tab> &n
>>1800 W. Martin Luther King
>nbsp; </x-tab><x-tab> &n
>>Durham, NC. 27707<br>
>><font face="Lucida Calligraphy"> Working with a few
>>good programmers who don't know <br>
>> what can't be done to Decipher your Data
>><font face="Lucida Console" size=1>If one synchronized swimmer drowns, do
>>the rest have to drown too? <br>
What no spouse of a programmer can ever understand is that a programmer is
working when he's staring out the window.
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
More information about the FRPythoneers