Python vs .Net

[Kevin Altis]

"Greg Brunet" <gbrunet at nospamsempersoft.com> wrote in message
news:v1otjvkdoinp77 at corp.supernews.com...
> "Peter Hansen" <peter at engcorp.com> wrote in message
> news:3E1C34D0.ECFBC7BF at engcorp.com...
> > > Static
> > > typing is just another tool to help the development process, and
> even if
> > > proper testing reduces the advantages of static typing by 50 or 75%,
> > > I'll still take whatever extra advantages I can get when I write
> code.
> >
> > Not to beat a dead horse, but what if the advantages were reduced by,
> > say, 98%.  Given the loss in productivity involved with all those
> extra
> > keystrokes for the static typing information for the compiler, you
> > might reach a point where it is *less* effective overall to have the
> > static typing in place.  :-)
>
> If things were that drastic - I would agree with you. The interesting
> thing is, even though I type in a few more keystrokes to define the
> variable types, I believe that I gain enormous benefits when I use the
> variables, or invoke functions & methods.  I tried to point this out in
> the Intellisense thread.  While I get some of this with Python, it's not
> nearly to the degree that is present with VB.  I get a function argument
> list, just like in most Python editors, but I also get all of an
> object's properties & methods in VB, which Python doesn't know.  Also,
> as soon as I enter something like [MsgBox "Some text",] I get a list of
> valid MessageBox flags.  No need to search help for them, make sure I
> spelled them correctly, etc.  To me, all these things make the extra
> keystrokes worth entering above & beyond the compile time code
> validation advantages.

I have to agree with this. PythonWin and Wing IDE (I think) and perhaps
other IDEs provide some auto-completion in the editor. All the good Python
shells such as PyCrust do because there you are already dealing with runtime
objects. The way this is accomplished is through introspection of the
compiled code object or the actual objects in the case of the shells. This
makes coding dramatically simpler for a newbie or even an experienced coder
unfamiliar with the API of a given class, function, method, or module. This
is especially true when using COM components or Java beans where good
auto-completion and calltips make the usage basically a matter of "fill in
the blanks".

Since PythonWin uses the Scintilla engine (wxStyledTextCtrl in wxPython
terms) I hope to add the same capabilities to the codeEditor in PythonCard
using Mark Hammond's PythonWin code. While this will be helpful, it still
won't match what editors for VB or C# or Java can do where all variables
have pre-defined types. In particular, you can't get auto-completion or
calltips on function or method args inside the function or method.

s = "hello"

We now know that s is a string, so when the user types s followed by a
period we can pop-up a list of string methods. But inside a function.

def f(s):
    print s

We don't know what s is until runtime, so we can't popup a list for s in
that case. Experienced Python programmers typically have at least one Python
interpreter shell running while they write code and the ability to try
things out interactively somewhat negates the inability to get
auto-completion and calltips in the editor.

So ironically, even though Python is designed to be approachable to
beginners, the lack of pre-defined types makes it less approachable in some
ways since an editor can't show the user calltips for function and method
arguments and functions and methods is what Python programmers spend most of
their time on.

ka