Weblogs Forum - Python IDEs

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Python IDEs

68 replies on 5 pages. Most recent reply: Mar 9, 2006 12:32 PM by Bruce Eckel

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 68 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Ed Blake

Posts: 1
Nickname: kitsu
Registered: Feb, 2006

Re: Python IDEs

Posted: Feb 17, 2006 10:08 AM

This is another stupid 'I recommend the IDE I use...' post, but first I'll try to add a useful comment.

I agree that in Python the IDE is mostly unimportant. I've tried virtually every IDE written in/with/for Python and I still use IDLE for every day coding. Some editors looked nicer, some had neat features, but none of them provided a facility that I actually needed or wanted to have all the time*. It seems to me that the most important features of a Python IDE are:


	syntax colorizer (duh)
	nice tab handling ('def spam:\n' gives you a new indent level)
	find/replace/goto
	run (preferable with support for things like Tkinter mainloop)

Notice debugging is not on there! I've used debuggers in other languages, but in Python I've just never felt the need for one. The combination of Python's meaningful tracebacks, a goto function, and a tiny amount of experience are enough to solve 99% of my errors.

* Okay, advertisement time *
There is one 'editor' I've used which substantially enhances how I read/write code: LEO the literate editor outliner. Leo lets me break code into sensible chunks (called nodes) and lets me to rearrange, clone, delete, etc. nodes as needed. It also lets you arrange nodes into whatever hierarchy you find useful. I usually have a node for tests/examples, one for old versions, and one for each file/module in a given project.
Anyway the thing that makes Leo useful is how it allows you to see, arrange, and refactor your code. Its like folding, but with real power and flexibility. It does have some problems, and a ton of features I don't use, but its basic functionality is a real productivity aid.

leouser leouser

Posts: 9
Nickname: leouser
Registered: Dec, 2005

Re: Python IDEs

Posted: Feb 17, 2006 11:46 AM

When I wrote the autocompleter plugin for Leo I took a different take on autocompletion, I based it off of convention. Leo starts up, the autocompleter scans the work in the file and builds an database to complete against that. So if you followed your naming conventions you could get the autocompleter payoff, and man have I been glad its there. For the JythonShell autocompleter I just do some reflective scans of the objects(if I remember right). Anyway, for me it doesn't matter what language I use: I LIKE AUTOCOMPLETERS! jyleo has multiple forms of completion and I like them all. Autocompleter is just one form. The other I like is tab completion. So if Im in java and type:
dou(TAB), it should complete to double.

Ive been doing work in Java/Emacs of late and for some reason I don't seem to miss the feature. I do miss Leo's wonderous structuring capabilities though...

leouser

Paul Boddie

Posts: 26
Nickname: pboddie
Registered: Jan, 2006

Re: Python IDEs

Posted: Feb 17, 2006 4:26 PM

Kay Schluehr wrote:
> Indeed? What can I do with following expression:
>
> >>> import compiler
> >>> expr = compiler.parse("1+2")
> >>> expr
> Module(None, Stmt([Discard(Add((Const(1), Const(2))))]))
>
> Which library function accepts a compiler.ast.Module
> object and generates bytecodes from it?

They don't make it easy. ;-)

compiler.misc.set_filename("test", expr)
g = compiler.pycodegen.ModuleCodeGenerator(expr)
code_object = g.getCode()

Actually generating bytecode files is slightly more involved, but there's a tool called libxml2macro in libxml2dom which has the magic incantations. Right now, I can't remember where I looked to find all this out.

> The PyChecker code is pretty opaque but I checked out the
> bytecode inspector version only.

I think a lot of code analysis approaches which limited themselves to bytecode took the easy route and consequently yielded relatively disappointing results. Examining the AST is harder (because you obviously have to provide support for various mechanisms that are implicit in generated bytecodes - stuff like the scope of a variable), but you get better information about what's really going on in a program.

Christopher Hunter

Posts: 4
Nickname: chunter
Registered: Nov, 2005

Re: Python IDEs

Posted: Feb 17, 2006 5:49 PM

When I need to remember something out of a standard library, I google it. It's all extremely well-documented and not complex, so I don't see what the trouble is.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Python IDEs

Posted: Feb 17, 2006 10:22 PM

> > Which library function accepts a compiler.ast.Module
> > object and generates bytecodes from it?
>
> They don't make it easy. ;-)
>
> compiler.misc.set_filename("test", expr)
> g = compiler.pycodegen.ModuleCodeGenerator(expr)
> code_object = g.getCode()

Great! Looks very pythonic ;)

Maybe I would have changed my approach when I've found this before but I would have failed using it at other places.

> Actually generating bytecode files is slightly more
> involved, but there's a tool called libxml2macro in
> libxml2dom which has the magic incantations. Right now, I
> can't remember where I looked to find all this out.

Bytecode file generation is handled by the Module class of pycodegen.py.

>
> > The PyChecker code is pretty opaque but I checked out
> the
> > bytecode inspector version only.
>
> I think a lot of code analysis approaches which limited
> themselves to bytecode took the easy route and
> consequently yielded relatively disappointing results.
> Examining the AST is harder (because you obviously have to
> provide support for various mechanisms that are implicit
> in generated bytecodes - stuff like the scope of a
> variable), but you get better information about what's
> really going on in a program.

I have not even a consistent idea yet what to look for in statical analysis. If the PyPy code base would be more accessible ( at least to me ) I would have looked there for code inspection and inference strategies. Other topics raised in this IDE discussion such like refactoring rule implementation is also in a sorry state with bicyclerepairman. Too much hacking and too few deliberation for my own taste - it is very well tested after all.

I'm currently moving into another direction away from statical analysis. I've written a code coverage module that generates additional Python code. It does not use the trace mechanism of the debugger but generates objects I have called "sensors" that are generated into Python statements. In the end it draws an image of the activation sequence of sensors that represents an abstract data flow. Those might collect additional information about their environment ( for coverage purposes it is sufficient to register their activation ). The strategy is therefore not conservative. A Python program gets enriched by information at compile time that makes it easier to analyze its runtime behaviour.

Kay

Christian Sell

Posts: 2
Nickname: chsell
Registered: Aug, 2005

Modern IDEs

Posted: Feb 18, 2006 11:17 AM

I am always amazed about people stating that they consider IDEs of little use. And what I really reject is the notion of "being cool" if you do so.

I have gotten used to the capabilities of a moden IDE since the days of Smalltalk - a non-typed language - and since then I would not want to spend time in a large code base without the possibility to conveniently issue queries like "tell me all places where this method is invoked", "tell me all places where this method is overridden", "show me all uses of this symbol" and the like.

Christian

Bartek Jarocki

Posts: 2
Nickname: bartek
Registered: Feb, 2006

Re: Python IDEs

Posted: Feb 19, 2006 4:42 PM

Just my 2 cents. Indeed IDE doesnt seem to be a critical issue with Python programming, but I think it doesnt hurt to have a good one - and there is a lot of them, some with all possible bells and whistles like code-completion, debugging (also remote), profiling, static code checking, GUI modelling etc..

I used some: idle, komodo, boa, slickedit, eric, SPE, now eclipse+PyDev. Eric(QT) and SPE(wxWindows) seemed most feature rich and these two I used until recently (with a little preference for SPE - more intuitive UI), but at the moment I am using PyDev plugin for Eclipse (it has a breath taking license!..:]). PyDev is handy now because I use Eclipse for non-python code and source control at the same time.

Despite obvious ease of Python debugging it is sometimes useful to have a good debugger too - lately I had to debug interactively a script running in a process pipeline (no stdout/stderr/stdin available) and I found a remote (socket) debugger winpdb very very helpful (I imagine it may be also useful for remote web apps debugging)

There must be yet some other IDEs you might try, but remember Python is delightful in vi too ;-)

Bartek

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Modern IDEs

Posted: Feb 20, 2006 3:18 AM

I am always amazed about people stating that they consider IDEs of little use. And what I really reject is the notion of "being cool" if you do so.

Yes, there is a little bit of some demented notion that if they us VI then they are somewhat hardcore or what. Of course IDEs in dynamic languages won't have all the wizbang features of a Java IDE, but WingIDE looks pretty nice.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Shit or chocolate?

Posted: Feb 20, 2006 12:02 PM

"The point is that Java is more verbose and it really is necessary to have an IDE. But in Python, you can typically figure out what a class does just by using dir(), and you usually have to look up the docs anyway to know what a method does rather than just using it. The compulsion to use an autocompletion IDE is much lower, in my experience, and it seems true for the people that I know, as well."

If I had ever been tempted to switch to Python, comments like that would be sufficient to dissuade me. The irony is that Bruce is trying to sell this sorry state of affairs as an advantage, rather than a disadvantage! Sure, it's much easier to use dir(), then look up the docs and then type everything by hand, and then hope that it will work in runtime, than to let the IDE provide a drop-down list of all methods that I can legally call on an object, along with the expected parameter types, then select the method I want, and then let the built-in type-checker tell me if I'm passing incorrect parameters. IDEs are for wimps!

Could it be that some measure of masochism is a necessary condition for preferring dynamic languages? I admit to being lazy, to letting machines do my work whenever possible. I'm not "hand-crafting every line of code", and if I were, I certainly wouldn't be proud of it. Call me a Java wimp if you like ;-)

"What Java programmers use IDE's for is the ability to explore their libraries without having to page through API documentation. That's assuming there *is* any API documentation. When using a new library in Eclipse I can jump around in its source, control-clicking on methods, classes, instance variables which is an amazing boon... This sort of commentary is especially puzzling when it comes from you, Bruce... Very likely you're a smarter man than I, but every bit of my experience as a developer goes against this sort of argument." (Matthew Phillips)

At least, not all Pythonists are trying to sell shit as chocolate: "That's all very nice but you don't have all of the Python standard libraries memorized, do you? And what about refactoring? If there were a really good IDE for Python we'd all be using it by now." Thanks Brian Slesinsky for being honest.

Ramzi Ben Yahia

Posts: 23
Nickname: miccheck
Registered: Jul, 2002

Re: Python IDEs

Posted: Feb 20, 2006 1:17 PM

I don't know how it could apply to python, but I found that SLIME (a Lisp IDE written in Emacs) is both a powerful and well-thought environment for the typical development style that's common to languages such lisp, python, ruby ...

Jack Trainor

Posts: 1
Nickname: hgwells
Registered: Feb, 2006

Re: Python IDEs

Posted: Feb 20, 2006 2:15 PM

I've always found the "I don't use an IDE" claim curious and suspect. If an IDE is available for one's language, platform and pocketbook, why not?

I've used IDEs since I started programming professionally in 1986. For me the winning and essential feature of IDEs has always been step-through debugging. To be able to examine any variable or field with a few clicks and without writing special debug code gives me the feeling of being in touch with my code that I would find hard to live without. Of course, newer features like auto-completion are nice too.

With Python I've used PythonWin for years. Lately I've started using Eclipse/PyDev which is reasonably fast and adequate. It does want a fast machine. It's useable at 1.0Ghz, but much more pleasant at 1.8Ghz+.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Python IDEs

Posted: Feb 20, 2006 11:54 PM

> With Python I've used PythonWin for years. Lately I've
> started using Eclipse/PyDev which is reasonably fast and
> adequate. It does want a fast machine. It's useable at
> 1.0Ghz, but much more pleasant at 1.8Ghz+.

It must say something about the modern state of computing, that it takes a 1.8Ghz machine to run what is basically a glorified text editor 'pleasantly'.

Paul Boddie

Posts: 26
Nickname: pboddie
Registered: Jan, 2006

Re: Shit or chocolate?

Posted: Feb 21, 2006 12:21 AM

[Bruce on dir()]

> If I had ever been tempted to switch to Python, comments
> like that would be sufficient to dissuade me. The irony
> is that Bruce is trying to sell this sorry state of
> affairs as an advantage, rather than a disadvantage!
> Sure, it's much easier to use dir(), then look up the
> docs

Or you could just type help(the_object) instead.

> and then type everything by hand, and then hope that it
> will work in runtime,

Or you could just actually try it out, given that you're at the interactive prompt.

> than to let the IDE provide a drop-down list
> of all methods that I can legally call on an object,

That's that dir(the_object) or dir(the_class) thing...

> along with the expected parameter types,

Well, I guess this probably needs decent docs in Python, at least, but anyway...

> then select the method
> I want, and then let the built-in type-checker tell me if
> I'm passing incorrect parameters.

Or just try it out! Yes, there are sometimes cases when you don't want to try it out, but then you wouldn't be running tests in such cases either. That would be a fairly specialised field of software development, I would imagine.

> IDEs are for wimps!

Well, I wouldn't necessarily disagree with that, given some people's way of using them (type two characters, slap Ctrl-Space, press F2 or whatever over and over again), but I can see that for languages like C++ you really need your IDE to remind you of the specification for some parameterised class, and then when you're calling the next_element method, you need reminding again about the parameter types ("What am I iterating over again? Oh, it's element<xzgr_spec_type<PQS_n, gqb_itype>>, of course!").

Yes, Python could be nicer even with some non-evaluating introspection mechanisms, and some IDEs even provide that, but you seem to be talking about the topic like some hypothetical exercise rather than what the experience of developing in Python is actually like. Shit or chocolate? A cheap shot indeed!

Ramzi Ben Yahia

Posts: 23
Nickname: miccheck
Registered: Jul, 2002

Re: Shit or chocolate?

Posted: Feb 21, 2006 1:14 AM

------------

If I had ever been tempted to switch to Python, comments like that would be sufficient to dissuade me. The irony is that Bruce is trying to sell this sorry state of affairs as an advantage, rather than a disadvantage! Sure, it's much easier to use dir(), then look up the docs and then type everything by hand, and then hope that it will work in runtime, than to let the IDE provide a drop-down list of all methods that I can legally call on an object, along with the expected parameter types, then select the method I want, and then let the built-in type-checker tell me if I'm passing incorrect parameters. IDEs are for wimps!

Could it be that some measure of masochism is a necessary condition for preferring dynamic languages? I admit to being lazy, to letting machines do my work whenever possible. I'm not "hand-crafting every line of code", and if I were, I certainly wouldn't be proud of it. Call me a Java wimp if you like ;-)

-----
You're right, if you want to switch to a dynamic language, you will be loosing all the convenience of your writing assistant IDE.
You're surely not "hand-crafting every line of code" in java, but if you hand-craft only 10 lines and let your IDE produce the 40 left, in the end you'll have 50 lines of code to "read".
In Python (or Ruby or Smalltalk or Lisp) you have to write also 10 full lines of code to get the same job done, so you just don't need the remaining 40 lines of noise.

There are features in IDEs like Eclipse or Intellij that I cannot live without when I write in java, but I don't even notice the absence of these same features when I write in dynamic languages.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Shit or chocolate?

Posted: Feb 21, 2006 7:48 AM

"Shit or chocolate? A cheap shot indeed!"

Maybe, but I was provoked! Claiming that the absence of a good, powerful IDE is a proof of the virtue of Python as a language is a bit thick, don't you think?

You're surely not "hand-crafting every line of code" in java, but if you hand-craft only 10 lines and let your IDE produce the 40 left, in the end you'll have 50 lines of code to "read".

I have already written about the "Java is sooo verbose" myth in the Ruby thread (http://www.artima.com/forums/flat.jsp?forum=106&thread=141312&start=210&msRange=100). My experience is that ugly Java code is due to ugly, sloppy, clueless programming, not to any inherent language ugliness or verbosity. When I have to work on legacy Java code, I usually find that by introducing appropriate abstractions and tidying up the code (sometimes with valuable help from the IDE), I end up with significantly shorter classes doing a better job. Let's face it, there are more "Java programmers" than there are good programmers. This, alas, is a natuural consequence of Java's success.

In the first place, I am "hand-crafting" not code but abstractions. Clean abstractions are best reflected in clean, terse code but terseness of the code is not a goal in itself. Maybe this helps explain why I don't regard type declarations as "verbose" - I find that they are necessary to reflect my abstractions. And no, I don't have Eclipse generate 80% of my code. I have Eclipse assist me with certain boring coding tasks, like generating getters and setters. More important is the power of the IDE for refactoring - when I find that one of my abstractions isn't right, its name is misleading or its signature needs to be changed. In those situations, "hand-crafting" is not only boring but also extremely hazardous, and boasting "I don't need an IDE for that, I do it by hand" appears simply ridiculous to me.

Flat View: This topic has 68 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic