'Intellisense' possible for Python?

[Cameron Laird]

In article <3e012e56$0$1404$272ea4a1 at news.execpc.com>,
Greg Brunet <gbrunet at nospamsempersoft.com> wrote:
>"Cameron Laird" <claird at lairds.com> wrote in message
>news:v01uhsnhke025d at corp.supernews.com...
>> Let me offer what I regard as a more affirmative way to
>> express this:  "Intellisense" is more valuable for VB
>> *because* VB embodies so much redundancy.  Yes, certain
>> solecisms manifest earlier in VB than they do in Python,
>> and, all things being equal, that would be an advantage
>> for VB.
>
>.. err - could you put that in English for me - remember, I'm just a
>simple VB programmer. <g>
>
>> All things better not be equal, though; good
>> style in Python emphasizes concision and abundant unit
>> testing.  If you're working in Python, and think, "ah,
>> if only Intellisense were here to autocomplete some
>> stuff", that's a clue that there's probably a more
>> elegant and Pythonic way to express your solution, one
>> that builds in what Intellisense only guesses.
>
>I wouldn't argue against being concise or extensive unit testing, but I
>don't see where those really relate to a feature like Intellisense.
>What I'm looking for are ways that the IDE can help me out - simple
>stuff, like:
>- When I can't remember the exact names of all of the methods or
>properties of a class, it's nice if they pop up when I type "object." so
>I can scan through them to find the one I'm looking for.
>- I haven't memorized all the parameters to a method, or their order, so
>I'd like to see the method 'declaration/interface/etc.' so I know what
>goes where.  Additionally, since it knows the types of the arguments,
>when I'm trying to do something like fill in the MsgBoxStyle argument
>for the type of messagebox I want to use, it can display the list of
>enumerations of MsgBoxStyle.  Now I can always enter a variable name
>there instead, but if I want a specific setting, I don't have to go
>search for it.
>
>While I'm likely not thinking very Pythonic-ly yet, I don't see this as
>something that goes against that.  Rather, it's simply an aid to
>learning and documenting the functions, classes, etc. and making it
>easier to look them up than to jump over to separate documentation files
>(which also have the disadvantage of getting out of sync with the actual
>code!).
			.
			.
			.
I was excessively elliptic.  I'm glad you had the
sense to ask for elaboration.

The fragment about solecisms expands this way:  you
are right.  When a coder makes many common errors--
mispellings and such--VB and many other languages
catch those at compile time, while Python and many
languages like Python catch them only during exe-
cution.  Earlier is better.  The inescapable
conclusion is that Python is worse.

EXCEPT that there's a larger context which renders
this comparison of only secondary importance.  I
can't afford the time this week to make my position 
clear.  I'll summarize it:  working in Python is
sufficiently different from working in VB that the
kinds of errors caught at compile time become a
peripheral matter.

Also, I'll invite Alex Martelli, who has written
quite carefully and comprehensively about Pythonic
coding practices and the role of unit testing, to
recommend one of his explanations.  Alex?

Your other points and questions are also apt.  I
was far too abbreviated.  Intellisense in fact
bundles several different aspects, and they
deserve individual attention.  For now, I'll just
recommend <URL: http://
www.ibm.com/developerworks/library/l-pyint.html >
and the references that appear in <URL: http://
phaseit.net/claird/comp.lang.python/doctest.html >.

You deserve more details.  It might take a while
to supply them.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html