Python Development Environments?

baxissimo asks: "I've played around with Python a bit, and as a scripting language I quite like it. So I sat down the other day to see if I could use it to make a modest OpenGL/GUI application on Windows. The short story is I gave up. I couldn't get the Python IDE I had to run--but that didn't stop me. At first I just shrugged my shoulders and said to myself 'Ah, who needs it? I've got emacs,' and then proceeded to waste a few hours trying to cobble together an app that would run before it dawned on me that Python without a decent IDE is definitely not easier to use than C++ with an IDE. So is anyone out there actually using Python to make serious apps? What tools are you using?" "I've heard the wxPython bindings are nice for the GUI bits, so I downloaded those, and pyOpenGL, and numPy, and PIL, etc. The only recommendation I really saw anywhere for an IDE was for boaConstructor, so I got that. Unfortunately it only spit out a useless error messages on startup and died. What I'd really like to start doing is creating C++/Python hybrids, but given that I was unable to successfully debug a pure Python app, I'm wondering what it's going to be like when my bugs might be in either language. How do people deal with this? What tools help you get the job done? If there's nothing free that works, are there any commercial IDE's worth the money?"

Comments

Re:On Windows?

[Anonymous Coward]

You've been moderated Troll, but I think you're pretty insightful. With all of the corporations trying to close up Windows, and the possibility that only signed apps might run in future versions of Windows, the message is clear: Don't make your own programs, you'll eat what we shove down your throat.

Options

[Fished]

There are several options out there that you may not have tried:

• Eric3
• Kimodo
• IDLE (included with Python).
• Black Adder ($$)
• Wing IDE ($$)

Not all of these provide any tools for graphical development, so you'll need to look to see which meets your needs. One other option might be to use Jython and swing/awt/swt.

Re:Options

[UberChuckie]

There is also a Python plugin for Eclipse, a popular Java IDE.

Re:Options

[Antity-H]

I agree abour Eric3, it's very good, except for one thing : it depends on qt3 which is not available in a free license for win32 platforms.

If you are on a *nix platform, it's definitely worth a try though.

Re:Options

[Anonymous Coward]

There is a more up-to-date python plugin called PyDev.

Nitpick

[Otter]

What you're asking about is an RAD tool for GUI construction, not simply an IDE right? At least in my vocabulary, an IDE integrates multiple development tools (editor, debugger, browser) but doesn't necessarily have the GUI constructor you want.

I can't blame the Boa Constructor guys -- if I'd come up with that name, I'd have put together the website first and worried about functionality later, too.

Coding with IDLE

[thesp]

Our department standardises on Python for scientific code prototyping. We write physics simulation and analysis code in Python, and those of us with Windows machines happily use the IDLE development environment. It is there, out of the box, and suits us fine!

I use Eclipse and Scintilla...

[stienman]

I use Eclipse and Scintilla, but neither of them for Python, and I don't realy use them all that much for regular development anyway.

But it's about as useful a recommendation as you'll get from other slashdot readers for your particular question anyway, so I thought I'd throw it at you.

Good luck, let us know how you make out. I've been wanting to get into Python for awhile, but have no real need to fulfill with it, and no time to dabble.

What I really want is an end to end programming solution which includes being able to program in a high level language which is not portable, but (to re-define portable) actually runs without change on many platforms keeping the local look and feel. End to end means I need to be able to develop the GUI/interface (with custom widgets) easily, the code behind it needs to be built and tested easily, and an installer that will install on any platform without change, or at minimum a single install configuration which will build installers for many platforms.

But Linux is not stable enough to be a good target (many distros, kernel changes, kde/gnome/etc, multiple platforms), and even the BSDs have many of the issues that Linux has. One of the banes of open source programming (release early, release often) is the fact that it changes significantly and frequently.

I believe that's one reason why interpreted languages are so popular among the OS advocates. All you have to target is the features available in the language, but those features must necessarily be limited. Only Java includes the language with built in GUI tools, and look at the mess it's become. The others require a seperate toolkit (QT, TK, etc) which means you have to target at least two different languages with two different versions.

Bleah.

Fantastic flexibility with constant maintenance, or little to no maintenance with limited flexibility? You decide...

-Adam

wxGlade

[hbr]

It's worth checking out wxGlade. As it says on the tin, it's not a complete IDE, just a GUI designer and you have to write the rest of the code in your favorite editor, but it works for me (and that sounds better than the sum total of all your python experience to date!).

I have to admit here that I'm not really an IDE person - I usually prefer vi and the command-line.

I've also had some experience at debugging python/c++ hybrids, but mostly on linux. On linux if you have a problem in the c++ bit you can use gdb/ddd (remember the executable is /usr/bin/python, and when you're in the python interpreter code, nothing will work unless you've compiled python with -g, but I've never found this necessary).

OSA Foundation

[amerinese]

I'd query the OSA foundation (http://www.osafoundation.org) since they're using python to make a pretty hefty GUI PIM. Dang, what they're doing sounds like such a good idea; I hope they finish soon.

wxDesigner works well

[t482]

I wrote a short faq :
http://xminc.com/linux/wxpython.html
faq.

wxDesigner:
one of the most complete but is closed source commercialware
Somewhat focused on C++ development
I don't like having to use their editor
outputs xml, python, c++, or perl code
Good, cheap, and stable - developed by one of the wxWindows developers.

http://www.roebling.de/

wxGlade:
nice - under development - copies the best features of glade. Easy to use and extend.
Not a full rad - more of a screen drawer.
outputs xml, c++ or python code
nice tutorial
Actively developed

PythonCard:
Nice if you want to make simple quick app.
I find this kind of tool can cause people to put the business logic in the gui though.
Speeds development by simplifying the event model.
Outputs python code
No option for xml output - but this may be coming soon
Actively Developed

XRC:
Simple xml widget editor

PyQT

[arcanumas]

As far as integrated GUI building , i only know of BOA constructor (which uses WxWidgets).
However, if easy GUI building is what you are looking for, then i may suggest PyQT. This is the Python binding for the QT toolkit. You can use 'designer' to build your GUI (the XML file) and then the PyQT tools to create Python code.
Easy, fast, clean.
You can find documentation here
Then use the editor of your choice for the rest.
You could always try Kdevelop which has support for Python (and QT Python apps).

Re:PyQT

[EnglishTim]

Unfortunately there is no free version of Qt for Windows, otherwise I would have thought Qt would be a natural choice.

Re:PyQT

[Anonymous Coward]

However, if easy GUI building is what you are looking for, then i may suggest PyQT. This is the Python binding for the QT toolkit. You can use 'designer' to build your GUI (the XML file) and then the PyQT tools to create Python code.

Did you even read the question? He's trying to build his GUI in Windows. I doubt he really wants to shell out $3000-odd for a Qt license when there are free tools that'll do the job...

Visual Studio

[bwalling]

If you like Visual Studio, then why not use it?

Re:Visual Studio

[Anonymous Coward]

Because ActiveState Python is "not fast enough for more than demos"

Re:Visual Studio

[k8to]

Sorry charley.

The link you post says that ActiveState Python for .NET is not fast enough for more than demos. Traditional CPython is default for ActiveState Python and what most people would use.

Python

[Cthefuture]

The thing is, Python is not really any easier than C++. The only things it gives you are more run-time flexibility and a garbage collector (which is trivial to add to C++; although not as integrated).

Otherwise it's just as verbose and irksome as C++. However, C++ is way faster. I find Python to be rather annoying as far as scripting languages go.

For easy GUI development I like FLTK and its Fluid tool, Qt Designer, or just plain Visual Studio (C++, VB, or C#).

Re:Python

[Anonymous Coward]

You are obviously not a python coder. The real advantage of python is coding in 5 lines what would take 50 lines of C++. When you get use to the python way of doing things it just feels so slow going back to something like C++, Java or the kind ...

G

Re:Python

[E_elven]

The Python language is tiresome to me -it is verbose, the syntax doesn't really offer anything new. I much prefer Ruby for this reason.

And, as I mention every time when a scripting language (or Java) is discussed, you can usually do the same thing in 5 lines of C++ as Python/whatever. You just have to find and download the right library (of which you have a choice unlike with these standard libraries).

Re:Python

[Anonymous Coward]

And, as I mention every time when a scripting language (or Java) is discussed, you can usually do the same thing in 5 lines of C++ as Python/whatever. You just have to find and download the right library (of which you have a choice unlike with these standard libraries).

Please demonstrate: I'd like to see a 5-line quicksort in C++, please.

Re:Python

[Dan Ost]

The thing is, Python is not really any easier than C++.

I don't see how you can make this claim with a straight face. In my experience,
writing Python and writing my C/C++ pseudo-code takes about as much effort.
With Python, that's it--I'm done.
With C/C++, I have to turn the pseudo-code into actual code.

If I need the performance of C/C++, I will still sometimes write it in
Python first to have pseudo-code that I can test before commiting the time
and effort into the C/C++ implementation (assuming I can't get the performance
I need just by using psyco or by writing C modules for the bottleneck sections).

So what is the general concensus? Do people really find Python to be as
time-consuming as C/C++? I don't see how that's possible, but it can't
hurt to ask.

Re:Python

[JudasBlue]

I have no idea what the orginal parent is talking about, and I have to assume he is trolling. That, or he has a LOT of experience in C++ and just a little in python.

I have found just the opposite, as I think almost everyone with a reasonable amount of work in both languages has. The original parent discounts garbage collection and built-in libraries, which is on crack, as both of those aid development speed tremendously. He is blowing off the fact that you have to hunt and find the libs you need to speed up C++ dev, and you get them with the language in Py (same can be said for Java) and while you can go out and get others if you want, 99% of the time I find the built-ins do what I need in a given instance.

More importantly, the dynamic nature of the language itself makes things much, much faster to code over C++ for me. Using lambda for dispatch, list comprehensions, built-in regular expressions, dynamic typing...bah, the more I think about this, the more I think this was just a troll.

Dan, you are right on.

Re:Python

[elflord]

If I need the performance of C/C++, I will still sometimes write it in Python first to have pseudo-code that I can test before commiting the time and effort into the C/C++ implementation (assuming I can't get the performance I need just by using psyco or by writing C modules for the bottleneck sections

The "writing C modules for the bottleneck sections" is in practice rarely adequate, because in an object oriented world (e.g. python), we may have entire classes that deserve a low level implementation (matrices for example). One can of course still implement the class as a module.

I don't think it's accurate to say that python is "as time consuming as C/C++". The question itself is bogus, because (1) there is no such thing as "C/C++", and (2) without some context, the question does not mean anything. However, there are a number of tasks for which python is considerably simpler than either C or C++ (or java or any static language)

Re:Python

[elflord]

The thing is, Python is not really any easier than C++. The only things it gives you are more run-time flexibility and a garbage collector (which is trivial to add to C++; although not as integrated). Otherwise it's just as verbose and irksome as C++.

You're trying really hard to be wrong, aren't you ?

(1) more runtime flexibility is potentially a huge advantage. Try doing something like eval in C++. Or try typing code directly into the compiler.
(2) python doesn't use gc by default, it uses reference counts. This is again a substantial advantage over manual memory management, because it makes polymorphism simpler. In C++, you have subtle gotchas like "slicing" (when you assign a derived class reference to a base class object). You need to work with explicit pointers all the time to get polymorphic behaviour (that's why you always use explicit pointers in toolkits like Qt for example) In a language that automatically manages memory, there's no need for this.

In addition, there are a lot of operations that become simpler because you don't have to declare types all the time. You can write something like
[x+2 for X in L]
without having to write a bunch of template gobbledygook.

std::list<int> L2;
std::transform(L.begin(), L.end(), std::back_inserter<int> (L2, std::bind2nd(std::plus<int>(), 2) );

Don't get me wrong, I like templates, they are quite useful. But sometimes, one likes to be able to work without the baggage that strong static typing brings to the table.

Re:Python

[Gilk180]

#include

void quicksort(int *a, int len){
std::sort(a,a+len);
}

Re:Python

[Gilk180]

sorry first line should be
#include <algorithm>

Re:Python

[Anonymous Coward]

For general programming, yes Python is somewhat more efficient (it is actually a very verbose language, on purpose, so the 5 vs. 50 lines comment doesn't really mean much).

But for GUI programming, you are just arranging calls into whatever GUI toolkit you're using, and Python vs. C++ doesn't really make that much difference.

If Python had honest-to-goodness anonymous functions and got rid of the arbitrary expression/function dichotomy that lambda has, I might give it a bit of an edge, since that's handy for callbacks.

It's funny that a terse language like C, which used to be the poster child for short unreadable programs, has bloated into C++ which is now the poster child for big unweildy programs....

Re:Python

[Rob Riggs]

The thing is, Python is not really any easier than C++... it's just as verbose and irksome as C++

Ha! No one who has done any CORBA work with both of them can say that with a straight face. Python's CORBA bindings are far simpler than those for C++. And that is all due to the nature of those two languages. That same nature is reflected in many other programming domains.

I think that Bruce Eckel's commentaries on programming efficiency with C++, Java and Python are right on the money.

This is not to say that Python is the perfect language for all applications. I still rely on C++ for many chores. But to write an entire application in pure C++ these days seems pure folly in most cases.

Re:Python

[Anonymous Coward]

std::sort is a merge-sort, not quicksort. Quicksort is in the C library, so calling that would of been acceptable.

Re:Python

[noselasd]

Some people seems to disagree with you on the easiness of Python.

Re:Python

[Anonymous Coward]

None of std::sort, std::qsort, or std::stable_sort are guaranteed to be quicksort, and in practice usually they are not. However, the naive implementation would have std::sort and std::qsort as quicksort implementations and std::stable_sort as mergesort. These were the choices made by the original STL implementation.

Re:Python

[kclittle]

I've been coding in C for 20 years, in C++ for 10, in Python for about 6 months.

There's no way in heck I can write debugged, full-feature code in C or C++ as fast as I can in Python. Now, if you want it to run really, really fast, well, that's another story...

Re:Python

[spRed]

Wow, I call troll.

I did C++ for years before I switched to Python, and writing the same thing in python takes a third of the lines and is much more readable. If you do hardcore bit banging and pointer arithmatic python takes ten times fewer lines (at the sacrifice of speed). When speed matters I still do that part of the program in C or C++ which is called from python, but I only do it when I have to (premature optimisation is the root of all evil, etc etc).

CPU hours are cheap, developers hours aren't. I personally prefer python over perl/ruby but either one is better than their lower level friends (C, C++, Java). Perl loses here because the C & C++ interface is terrible, python and ruby are sane (and again, I prefer python). There is even a python interpreter that compiles to native java byte code [jython] if you want it (I don't, I'm fine with writing hotspot functions in C or tiny objects in C++).

Re:Python

[Gilk180]

It is not specified what type of sort is used for the c++ algorithm.

I didn't bother making the point because it isn't specified in the Python language what algorithm is used either.

Re:Python

[E_elven]

#include "lib-x/algorithm"
...
algo::qsort_in_place(orig_ list);

Re:Python

[kraut]

Actually, that's only partially true: The main problem with C++ CORBA bindings is that they predate modern, standard C++. If you re-did them using 2004 C++, instead of 199X C++, they would be a lot easier to use. E.g. use namespaces, std::string, std:: etc all would make life a lot easier.

Re:Python

[Anonymous Coward]

calling that would of been acceptable

"would have been".

Re:Python

[Nevyn]

So what is the general concensus? Do people really find Python to be as time-consuming as C/C++? I don't see how that's possible, but it can't hurt to ask.

One of the big problems I've seen is when most of the code you are using is in a C python module. For instance gtk. What happens then is that the C interface is much better documented, and often better designed (going from gtk1.2 to gtk2.0 in python was a much bigger change than for C code).

And on top of all that, if you screw anything up the C code will go wrong in the exact same way (but it's a much bigger pain to debug the python interpreter SEGVing than if you had written your code directly in C).

And then you have a dep. on a bunch of python stuff which makes distributing it much harder ... I used liferea for a long time over straw because I just couldn't satisfy the deps. for straw (and pertinently straw was buggier).

Sure, you get some benifits ... syntax for creating arrays/dicts is very compact which can make certain interfaces easier ... and you don't have to care about the lifetime of some of the objects. After having done both, I might use python again for simple GUI apps. ... but it's not as clear cut as you want to suggest.

Re:Python

[HuguesT]

This is not what he is asking, he is asking for a quicksort *IMPLEMENTATION* in 5 lines of C++. Calling a library doesn't count.

Here's one in 4 lines in Python:

def qsort(L):
if len(L) <= 1: return L
return qsort( [ lt for lt in L[1:] if lt < L[0] ] ) + \
[ L[0] ] + qsort( [ ge for ge in L[1:] if ge >= L[0] ] )

Let's see the corresponding C++ code.

I didn't write this, look up the Python cookbook

Excluding bugs that is

[madmaxx]

So C++ is easier than Python without an IDE?

I think you might be missing out on some of the most important features of Python (or any decent scripting language these days): it's a high level lanugage, intended to be easier to use than lower-level languages like C/C++. Whining about a lack of GUIs is besides the point.

Once you know Python, and understand some of the GUI toolkits, it's far more productive than C/C++ with similar toolkits. So is Perl, Java, or C# for that matter. It sounds like you don't know Python and related GUI toolkits very well yet, though, which is one place where an IDE can be used to limp along for a while.

In case you haven't noticed, an IDE is really a simple set of tools, which exist for nearly every language already -- though not always packaged together. Get over it: your best toolkits won't come in one package, ever. Any good craftsman will learn to piece together a master's toolkit for any problem set, and use those tools when/where appropriate. IDEs, in general, are the Walmart AllInOne toolkit. Okay if you don't know any better, and the problems are small, but not often suited for anything of scale. Think I'm being a twit? How many IDEs are used in production build environments? (Hint: none)

So back to your baseless productivity point: Python is more productive, in general, than C/C++. This includes GUI work without an IDE, and a lot of server problems that are usually mashed into using C/C++. Why? The language (and libraries) focus on ease of use ... and are not encumbered by aspects of the underlying hardware leaking through the abstractions. Things like direct memory access, pointers, and references have their place, but are the root of a large amount of debugging time. GUIs in the lower-level languages waste a lot of time with low-level bugs (though there is a chance that performance will be better).

GUI work without a GUI builder you say? If it's too tedious for you, then automate it (Python happens to be really handy for that). Most GUIs are built around schemas or specifications anyways -- using a GUI builder only speeds up the tedium (it doesn't solve it). And you'll want to know the GUI toolkit well enough to automate with it anyway (using it in ignorance with a GUI builder is buggy in itself). Don't get me wrong, there are some great GUI builders for Python, but don't rely on it to save you from learning something.

One of the best IDEs I've found (and I've used a lot of IDEs) is the OS, and tangent language tools themselves. For Perl, I use Vi, Gedit, or Textpad for my editor, GladeXML or perl scripts to generate UIs, bash/MakeMaker for my build system, and the other Unix tools to fill in the gaps. I've used some of the Perl IDEs in production environments, and they're all limited somewhere. Don't settle for one tool, as your tools contribute to the quality/quantity of what you produce. You can be in control.

Re:Excluding bugs that is

[cavemanf16]

Think I'm being a twit? How many IDEs are used in production build environments? (Hint: none)

Yes you are, and no, there are many.

Why is it so many job postings these days require a programmer to be proficient with Visual Studio, .NET, or any other host of IDE tools? Those just must be the "I have a huge budget and need to waste the money somewhere" types of jobs, right?

Not to mention that the submitter of this Ask Slashdot may merely be a student wishing to learn more and waste less time typing redundant code like GUI app controls on vi or notepad.

Believe it or not, some of us have moved past the early 90's and like to use our powerful computers to be lazier and not worry about moving the bits around via assembly language all the time. Of course, I find assembly language intriguing and a great learning method to programming, but c'mon, it's pointless for you to claim we should all continue to use vi, emacs, or notepad to edit our code. Creating a GUI app is hard enough with the IDE's help, let alone doing it all by hand. What a great way to introduce some really strange logic bug! Great thinking there, buddy.

Are you sure you're not Amish? I mean, they decry the evil evil use of *gasp* electricity, or buttons, but have no problem using fire for lighting and hooks to close up clothing. All four things I described are inventions for ease of use, so where's the sense in stating that the prior two inventions (harnessing electricity and buttons) is worse than using fire and hooks?

Re:Excluding bugs that is

[Brandybuck]

Once you know Python, and understand some of the GUI toolkits, it's far more productive than C/C++ with similar toolkits.

The only accurate generalization about programming is that all generalizations are wrong. Python may be more productive than C/C++ for some kinds of application, but certainly not for all of them. C/C++ is not as "forgiving" as Python, but for some applications, that's EXACTLY what you want!

Re:Excluding bugs that is

[madmaxx]

Yes, I know they exist ... and yes, I use IDEs. IDEs are just tools, and they're not the only tools out there. Limiting your toolkit to one large hammer is just plain nuts, as the more you know, the more useful you can be. There's a whole world of tools out there that people are ignoring, because they think they need an IDE.

You seriously think production shops use Visual Studio as their production build system? Most shops use it as their editor, and their GUI builder, but production builds usually go through something like Visual Build. Why? The build tools in Visual Studio are suited to a smaller set of problems. That's not a bad thing.

The point is that THERE ARE OTHER TOOLS. Remember that every tool is integrated into the operating system, so why limit yourself to tools integrated with your editor/RAD environment? When you realize your OS can be your IDE, then you'll find there are more tools you can pick from to do your work for you.

Re:Excluding bugs that is

[elflord]

Limiting your toolkit to one large hammer is just plain nuts, as the more you know, the more useful you can be.

Then it's odd that you were just a moment ago woofing mindlessly about how python is "more productive" than "C/C++". There is a reason that both C and C++ (which are not the same language) have been wildly successful -- indeed, the python interpreter you are so enthusiastic about, and many modules written for it are written in C.

It's true that it's easy to throw together a few lines of python code that do something useful in very little time, but that's a far cry from making python "more productive", though it does make it very useful for a number of tasks.

I happen to use and be quite proficient with both python and C++ and frankly I find the woofing of the advocates of both of these to be quite embarrassing at times.

Re:Excluding bugs that is

[madmaxx]

Scripting languages, like Python, *are* generally more productive than C, C++, or Assembly code. But productivity isn't always the most important axis of a project, and when it's not, there is likely a language to fit your needs. And some things are a terrible fit for a scripting language. In the case of the parent topic, GUI applications of nearly any size fit Python reasonably, and there are several good examples out there (Straw off the top of my head).

To tie this to the topic: "...that Python without a decent IDE is definitely not easier to use than C++ with an IDE.", the premise that the IDE is somehow a precurser to productivity is a narrow view. I'm trying to encourage the poster to widen their view, as there is a lot of productivity to be found in many tools, and many languages -- as they fit the problem.

I bash on the IDE mindset because it's so blindly followed. IDEs are not bad, but believing that they are somehow new, wonderful, or magical is misled. Emacs is a powerful IDE, just as Gnu/Linux is, or Windows with the MSDN. The key is that we need to keep our eyes open, as there is a lot of neat shit out there if you're looking.

Python, in particular, doesn't really need a kick-ass IDE to be a productive for building serious apps. Python, bash, Glade, and your text editor of choice is a very productive set of tools (an IDE if you use your immagination), as good as the Visual Studio (for VB or C#).

Re:Excluding bugs that is

[p3d0]

I think you missed the point. He's saying he finds Python without an IDE to be harder than C++ with an IDE. (Not that I agree.) Your arguments don't address that point.

A few options

[The Bungi]

Komodo
Wing IDE

Now, you mention you had trouble with boa. You're going to want to get it working unless you want to spend some money, because for $0.00 that's as good as it's going to get. Otherwise the two above are good investments. IIRC Komodo has a free version, but I'm not sure. PythonWorks had great potential but it's not being developed any more. It only supported Tkinter anyway.

That's as far as GUI designer support. If you're not having any luck you might want to try wxWorkshop. I've heard some people have luck embedding their dialogs in C++ libraries and binding them to Python programs. YMMV.

If all you want is a good Python editor with debugger support there are a bunch of them out there:

http://drpython.sourceforge.net
http://pype.sourceforge.net/ (more mature)

Personally the best Python-specialized editor I've used is IDLE, though it has no GUI capabilities. IDLE ships with the full Python distribution for Linux and Windows, and it behaves essentially the same in both platforms.

You might also want to check this article out. And of course, the clearing house.

Re:A few options

[NNland]

Goodness, you cited my editor (PyPE). I don't know if I would call it mature, but "works well enough" and "pretty much bug free" are two ways that I would describe it. Oh, that and "I've been using it daily since it was 6 hours old" is another.

Ahh, such is the power of Python development. You can have a usable application (source code editor) in a weekend.

Thank you for pimping it.

Re:A few options

[The Bungi]

My pleasure. It's a fine editor. I used it for quite a while and for one reason or another went back to vim and IDLE, but I wouldn't hesitate to recommend it to Python folks.

Cheers.

Re:Are you kidding me?

[demian031]

i second vim.

you'll likely be programming in a handful of different languages. pick one editor (vim || emacs), become a guru in it and you will be able to sling code efficiently in any environment with any language.

Boa and wxPython

[techsplicer]

I had a similar experience with Boa and the latest release of wxPython 2.5x. Last i heard, Boa Constructor required wxPython 2.4x and that currently wxPython 2.5x was unsupported. Have you considered down-grading?

Bull

[ujube]

That's a total crock. My thesis project is thousands of lines of Python code, including GUI code, and it hasn't been through an IDE of any sort. Emacs is most assuredly sufficient. It is all a matter of what you are comfortable with.

Well....

[Randolpho]

There isn't really a full *IDE* for python that I've ever found. Most are just editors.

The best python editor that I've found, IMO, is PythonWin IDE (not to be confused with PythonWin, which is a python GUI library for windows). PythonWin IDE comes with Active State Python. Great for editing your python with good syntax coloring, auto-indent, and code completion. Very stable, good performance.

Oh, I should mention: It's Windows only. Sorry if that locks you out, or anything. I've never tried to run it with WINE, but I don't see why it wouldn't work.

Re:Well....

[Anonymous Coward]

I have had huge problems when debugging a wxpython GUI in this program. When the program i was debugging crashed pythonWin went down real hard and had I kept having to kill the process. IDLE didnot have the same level of problems.

boaConstructor Rocks

[Coventry]

But for most day-to-day stuff I use SciTE for my Python/Jython development.

That said, the wx toolkit and boaConstructor are _very_ powerful. Have you sent your 'meaningless error message' to anyone on the boaConstructor lists to get feedback? I'm pretty sure the error means something to someone - heck, even _I_ might know what the problem is.

Honestly, and I'm not trying to be a troll here, how do you get anything done as a developer if you give up every time you get an error message? I'm not saying that you should have to debug everyone else's code as a part of day-to-day work, but if you just give up on something (boaConstructor) without Googling for an answer or consulting others or just digging in, then that doesn't bode well for what you'll do when you encounter a bug of your own creation. boaConstructor is used by a lot of people, and is under active development - if everyone got the 'meaningless error message' you got when they installed it, then either no one would use it, or it would already of been fixed. The most likely causes for your problem are:

A) You checked out a bad build from CVS (Get another)
B) You don't have the prerequisites installed correctly, or you installed boaConstructor incorrectly
C) Your Path is messed up (this will affect any/all dev projects - if a library or file cant be found, errors will happen)
D) Invalid permissions
E) Version conflicts (You could be on an old redhat box with Python 1.5.2, and boaConstructor needs a newer version, for example).

Instead of bothering slashdot with this issue, why didn't you post to the python list and/or the boaConstructor list? I'm sure that with the proper info people will be able to solve your problem.

Did you RTFM?

[silvercloak]

I've heard the wxPython bindings are nice for the GUI bits, so I downloaded those,

Did you install wxPython before BoaConstructor? I have installed BoaConstructor successfully. BoaConstructor has prerequisites that don't come in the install package. Look at the install docs agains and figure it out. Once you figure it out write an installer helper program for BoaConstructor in Python and open source it.

Re:Did you RTFM?

[ebbe11]

I tried to get BoaConstructor running and... Did you install wxPython before BoaConstructor?

Yup. I have installed BoaConstructor successfully. BoaConstructor has prerequisites that don't come in the install package.

Yup. Specifically:

C:\Python23\Lib\site-packages\wxPython\tools\boa
boa.py
Starting Boa Constructor v0.2.3
importing wxPython
reading user preferences
running main...
Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\wxPython\tools\boa\ boa.py", line 603, in ?

main()
File "C:\Python23\Lib\site-packages\wxPython\tools\boa\ boa.py", line 585, in main
app = BoaApp()
File "C:\Python23\Lib\site-packages\wxPython\tools\boa\ boa.py", line 408, in __init__
wxApp.__init__(self, false)
File "C:\Python23\Lib\site-packages\wx\core.py", line 5042, in __init__
self._BootstrapApp()
File "C:\Python23\Lib\site-packages\wx\core.py", line 4791, in _BootstrapApp
return _core.PyApp__BootstrapApp(*args, **kwargs)
File "C:\Python23\Lib\site-packages\wxPython\tools\boa\ boa.py", line 417, in OnInit
conf = Utils.createAndReadConfig('Explorer')
File "C:\Python23\Lib\site-packages\wxPython\tools\boa\ Utils.py", line 295, in createAndReadConfig
confFile = os.path.join(Preferences.rcPath, '%s%s.cfg' % (name,
NameError: global name 'wx' is not defined

Look at the install docs agains and figure it out.

It would help a lot if the install docs mentioned the global name 'wx' not to mention its meaning...

Re:Did you RTFM?

[Fruny]

Look at the install docs agains and figure it out.

It would help a lot if the install docs mentioned the global name 'wx' not to mention its meaning... wxPython changed its architecture in version 2.5, dropping the wx prefix. Check the migration guide. Boa Constructor apparently relies on an older version, install it.

Re:Did you RTFM?

[ebbe11]

wxPython changed its architecture in version 2.5, dropping the wx prefix. Check the migration guide. Boa Constructor apparently relies on an older version

Seems that the Boa Constructor team hasn't discovered that the world has moved on...

install it

I'll try that. Thanks for clueing me in :-)

Komodo

[EnglishTim]

If you're not doing commercial work, you could try Komodo, which doesn't cost too much ($29.95) for the noncommercial license. You can try it for free for 21 days first to see if you like it.

So, if you think you could afford it, it's definitely worth a look. It doesn't have any GUI designing tools, but it does have project management and an integrated debugger.

Re:Are you kidding me?

[rogabean]

I vote emacs. sorry, I know I'm going against slashdot status quo... but once you get to know emacs :)

the parent above me makes a very valid point however. It is far easier to become well versed in a text editor to code in so you can drop code into any IDE/compiler/etc and just go with it.

In the long run you'll be better off for it :)

Hahahahahahahaha ...

[Chromodromic]

Cool. C++, with a link to Visual Studio, is easier than Python.

Unless you're using some subscription release of Visual Studio, VS doesn't even support visual GUI widgets via C++ yet. You've got to use VB, or C#, or J# or some other freakin' sharp to get that.

I think one of the primay points of using a scripting language, bud, is to *get away* from IDE's. IDE's are there because certain large languages and frameworks, or certain requirements for memory management or debugging, are so complicated that using an IDE is a productivity booster. But with Perl or Python, an IDE frequently gets in the way.

Also, if you are building a "modest OpenGL/GUI" app on Windows, well ... why? If you're building something that uses extensive GUI on Windows, why not use Windows Forms or, hell, win32? Try using GLUT for Win32 to complement that.

Or, sit down and learn wxPython, which has OpenGL support and, dude, is as easy to learn as a GUI toolkit gets. I mean, I'm sorry, but if you have a hard time getting around wxPython, then maybe GUI development just isn't for you. Or maybe you need to be a bit more patient and get out of that Visual Basic mind-mode.

Anyway, it might not be a bad idea to get away from IDE a little. Cutting a little code without IntelliSense, or whatever the hell it's called, might put your mind to thinking about *why and how* things are working the way they are, instead of satisfying the requirements of the pop-up window telling you that you need to supply some widget reference.

Re:Hahahahahahahaha ...

[Anonymous Coward]

No, "bud," having Intellisense lets you focus your mind on the why and how, instead of trying to remember what all the little methods are called. It's not just a Studio thing, you'll find it in Netbeans and Eclipse, too. It's a lot quicker and less disruptive than looking things up in the help.

Though, dude, given how dynamic Python is, I don't see why Intellisense would be relevant at all.

In general, maybe you should get off your high horse.

For GUIs

[sashang]

For the GUI I use xrced. When making a GUI it's better to use sizers to layout the GUI and avoid absolute positions. This ensures that the app will look good and widgets won't overlap on any platform. For coding I currently use vim. I've used boa before and found it fine for writing python code. It didn't support sizers at the time though.

Close

[Anonymous Coward]

But definitely:

std::transform(L.begin(), L.end(), std::back_inserter(L2), std::bind2nd(std::plus(), 2) );

Re:Close

[elflord]

Doh! But you appear to have it wrong too -- you need std::plus. You're right about back_inserter though, its template param is actually list<int*gt; , but it can implicitly deduce this.

Define IDE

[anonymous cowherd (m]

I'm assuming you mean IDE as in "Integrated Development Environment." This begs the question, then, what do you want integrated?

I'm a big fan of IDLE, myself. It's by no means the slickest IDE out there or even the best tool for some jobs. However, it does (I)ntegrate a syntax-highlighting, auto-indenting editor; a debugger, class browser, and an interactive python shell. The interactive shell is really the most powerful. From the shell, you can inspect your whole program at any point in its execution. What that means is that you don't *need* an IDE to write pure python code at all. A decent editor and the interactive shell are enough.

K.I.S.S.

[Malevolyn]

I simply use Notepad. I've been using it for as long as I can remember and quickly became accustomed to it.

Re:K.I.S.S.

[Doppler00]

Features like autocompletion, syntax highlighting, debug environment are essential for saving developers time.

Going without these features is just folly.

GUI Development with Python

[stormcoder]

I use Visual SlickEdit combined with wxGlade. Works very well. If your doing GUI development in Python, you want to be using wxPython.

Problem: Python is a weakly typed language

[Anm]

Python can never have serious IDE in the same way C, C++, Java, and C# can. There are several Python editors that do pretty syntax highlighting, and maybe some visual GUI editors that generate Python code. Some editors even support parameter or documentation tooltips, but the gap remains when you want attribute completion that allows a level of unobtrusive API exploration while programming.

The problem is that any object can have any other number of properties appended onto it anywhere in the code. Even if you attempt to make a class in Python, the only definition of what properties it has is the properties set in __init__. This leaves runtime evaluation as the only way for the IDE (or any other piece of code) to discover the code structure.

IMNHO, it is a horrible way to write a robust piece of software.

Re:Problem: Python is a weakly typed language

[alex_tibbles]

This leaves runtime evaluation as the only way for the IDE (or any other piece of code) to discover the code structure.

What's wrong with that? It's a dynamic language, the IDE can do load and interpret the code as you write it, meaning that the full run-time environment (as much as you've written) is avavilable to the IDE. If you want to write a bit that depends on previous execution of other code, get the interpreter to interpret that bit, then write your code.
Eg.
f() creates a class and returns the class-name.
g() creates an instance of the class whose name is returned by f(), and executes method calls on it, depending on some other values.
Run g(), setting a break point, and continue writing after the call to f().

One of the best things about VB6 (from way back) IMHO was the 'immediate' window, which was basically an limited interpreter. With Python you get the whole system from an interpreter.

IMNHO, it is a horrible way to write a robust piece of software.

It depends. If you really need to do something like this, you'll do it, be it in C, C++, Java or whatever, and you'll make a horrible hack job of allowing dynamic class definition in those languages. Far better for the language to allow for it. (Eg. p249 More Effective C++ by Scott Meyers: 'Implementing Multiple Dispatch' vs. CLOS). All of these advanced features need to be used wisely, and I'd agree that injudicious use will create a mess, but would it be any worse than the hack-around in the static language?

At the risk of answering my own question, I suspect that a lot of the unpleasant idioms you get used to (in any language) will give ideas for what a better language should do automatically. No matter how used to the unpleasant idoms I get, I can still screw up one implemenation of them...

Re:Problem: Python is a weakly typed language

[Anm]

It's a dynamic language, the IDE can do load and interpret the code as you write it, meaning that the full run-time environment (as much as you've written) is avavilable to the IDE. If you want to write a bit that depends on previous execution of other code, get the interpreter to interpret that bit, then write your code.

That only works if you are there is a route to the function you intend to edit. Any branch can change the list of available properties. Or worse (for the IDE trying to list an object's properies), the given function may be called from more than one location.

It is really an intractable problem you're suggesting the IDE should solve.

Anm

Re:Problem: Python is a weakly typed language

[jovlinger]

yes.

many things I like about python, but dynamically declared variables and lack of proper lexical scoping are gigantic detractions.

Re:Are you kidding me?

[black mariah]

I'm going for anything that isn't a bloated piece of shit or a confusing mass of hotkeys and cryptic commands.

Usually, I used nedit.

Are you a serious coder?

[Viol8]

I'd be the first person to admit that IDEs are useful. But not having one should only make coding a bit harder , not impossible! If you can't code a program just from command line tools then theres something seriously lacking in your abilities as a coder. I've written Xlib programs in C using just vi and the command line cc compiler and I don't rate myself as a guru. If I can do it any half decent coder should be able to.

pythoncard

[Anonymous Coward]

PythonCard.
Taken from their site: PythonCard is a GUI construction kit for building cross-platform desktop applications on Windows, Mac OS X, and Linux, using the Python language.

PrimalScript

[Anonymous Coward]

If you are using Windows, check out Sapien's PrimalScript. It rocks.

Leo anyone?

[Anonymous Coward]

I prefer to use glade ( http://glade.gnome.org/ ) and leo ( http://webpages.charter.net/edreamleo/front.html ) for my little GUI-Tools.

Fix for Boa Constructor

[/^Neil/]

You need to use wxPython 2.4.2 as the latest wxPython won't work because of the name change from wxWindows to wxWidgets. Thanks to MS. This bug will be fixed someday.

Neil

Python is not weakly typed.

[anonymous cowherd (m]

This is a common misconception. In fact, python is a strongly typed language. Every object in python has a definite type at any given time, and there are no implicit conversions between types.

What python is is dynamically typed. That is, a name can be rebound to a different object whose type may differ from the original value.

See http://kahakai.sourceforge.net/wiki/index.php/Weak lyTyped for perhaps a more clear explaination of the difference.

Re:Python is not weakly typed.

[Anonymous Coward]

Like Smalltalk, Python has classes but not types. A type is a set of values which certain operations will accept as arguments. However, there's no way to find out whether a Python method will accept a value as an argument other than calling it, because types are neither declared nor inferred as part of the design contract of methods.

Re:Python is not weakly typed.

[Anm]

You're right. My bad. More info here.

As the AC pointed out, this still leaves the IDE clueless with respect to completion and correction of method arguments.

Anm