Roberto Alsina writes: “Tired of long, carefully crafted tutorials trying to show you the quickest way to write a program? Here I take another approach. I just went and did a program (and the tutorial) while checking the clock.” And so here you have it: the app, the tutorial, and the timeline.
Rapid Application Development using PyQt and Eric3
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Now *this* is rapid application development. C#, eat your heart out. Now, all we need is a good native code compiler like Python for Python, and we’d have one of the premiere development platforms out there.
*> If you don’t get the joke: http://www.cons.org/cmucl
Interesting tutorial.
What i’d like to see, though, is a way to make a delphi-like or access-like front end to a database, with bound data controls, using a grid to show a 1-many relationship. is that possible using PyQT?
i only ask this b/c this is what 90% of the daily work for corporate programmers is. Drag + drop db development with bound controls + very little code. Is it possible with Python and WxWindows? An open source, easy way to do this would be one of the biggest additions to the open source world – and with python, it would be cross-platform, which would be great
This really just proves that it is really easy to rapidly design an app if you are fairly proficient in the language you are using. Go to one of those microsoft .net shows sometime. In 30 minutes, they throw together entire online banking applications and such.
I’d like to see more GUI developers jump on the dynamic language bandwagon. GUIs are naturally dynamic. Heck, the Xerox PARC group that made the first modern GUIs was the same group where Alan Kay invented Smalltalk (the most dynamic of OOP languages). Smalltalk was part of PARC’s revolutionary set of technologies, along with email, networking, and the GUI.
Consider, also, Cocoa, widely regarded as one of the best GUI frameworks. What’s it written in? Object C, which is a cut-down Smalltalk with C syntax. Even Qt’s C++ API is very dynamic, with the signal/slot mechanism abstracting lots of what would potentially be casts.
Now if only more reviews/articles were this good. Nobody cares about authors ability to paraphrase PR material about IDEs
Fabulous work.
I’d rather just program in GTK+/C. I don’t think the abstraction overhead is worth the knowledge I sacrifice from knowing what I’m doing, or being in control.
In proprietary and corporate structures where ‘time is money’, ‘lazy application development’ might make sense. In a situations where you want to develop extremely tight code and resource efficient applications, then I would do it the good old way—painful and structured programming.
It is not really about how fast one can write code. It’s about how well planned and designed the code is. Or at least it should be open source development.
Oh, by the way, I’m I the only one who thinks object oriented programming is exceedingly hyped and unnecessarily complex? I’m beginning to see it implemented in situations where it is needless.
i only ask this b/c this is what 90% of the daily work for corporate programmers is. Drag + drop db development with bound controls + very little code. Is it possible with Python and WxWindows?
Boa Constructor:
http://boa-constructor.sourceforge.net/
No data-bound controls here, but then again, it’s not VB! You can develop your own Python classes that can access the UI you create with Boa Constructor.
Mono is just as wonderful, if not more.
It’s almost frightening how simple and efficient it is. Sometimes it feels like the compiler is parsing my mind instead of the actual sourcecode.
In a situations where you want to develop extremely tight code and resource efficient applications, then I would do it the good old way—painful and structured programming.
Well, you could always go back to coding in machine language if you feel that way. My thinking is that if you wanna be a hardcore, bad-ass ‘do it the hard way’ coder, then either shit or get off the pot.
The only true rad tool for linux is Kylix from Borland.
This thing you show here does not even have a forms designer. You can make the same program in Kylix in about 5 minutes.
You are welcome to do that, but in the time it takes you to make an app in C, I could make at least two or three in Python, and the users usually wouldn’t notice the difference because most of the performance-sensitive parts of the app will be native Qt code. And users will like my app better, because it won’t suffer from security leaks caused by buffer overflows, it won’t leak memory, and it won’t segfault.
For major applications, we need a language that is immensely productive like Python, but native-compiled so they are fast. There are several languages that fit the bill, but unfortunately none of them have really first-class bindings to GNOME and KDE. Given equal amounts of time to do the same project, a program written in a high level compiled language will probably be faster. Why? The time a C programmer spends debugging dangling pointers, integer overflows, fussing with types, rewriting large amounts of code while refactoring, compiling over and over, etc, can instead be used optimizing the algorithms of the program. Who cares if optimal code written in C is 30% faster, when almost no programs contain uniformly optimal code?
Consider: Why can’t Mozilla resize without lagging, even though its written in fairly low-level C++? Its because the core algorithms are not optimized! The algorithms are far more important than the performance of raw generated code, especially for desktop apps. A language that lets you spend more time optimizing those algorithms will lead to faster apps.
If you don’t believe me about the power of Python, read ESR’s essay about it:
http://www.linuxjournal.com/article.php?sid=3882
He thought he was exaggerating too, until I actually tried it. He’s right! I can write working code almost as fast as I can type! And even hastily-written programs are completely readable several months later.
Python OOP isn’t like Java OOP. In Python, OOP is always there (unlike Java OOP). Everything is an object, even integers, floats, and types. Yet, you don’t have to use it if you don’t need to. If you want to write everything in a procedural (or even functional) manner, then great. You can even mix and match styles, using the best one for a given situation.
This is interesting, but as alreayd pointed out, it only shows how fast you are when you know your language
BTW, I would had preferred to see a tutorial about how to get qtruby bindings from kde cvs and use that, pyqt is too easy ;P
Yeah, right. You do it in 5 minutes with Kylix and I get 100 Euro for every minute you’re overdue. I think I’m going to book my holiday in Indonesia now 🙂
BTW, he used QT designer, a form designer.
Basically this is what Python vs C# boils down to. Python is the Linux equivalent of Visual Basic, except that it doesn’t suck. A dynamically typed, easy to use language that’s good for many tasks but for large programs, or programs where the programmer is happy with static typing I’d still go for a language like Java or C#.
I’ve worked with Python a fair bit and it’s great, but I’m not convinced that the gains outweigh the losses of static typing. Maybe I’m just old school, but I like having as much of my code mechanically checked as possible.
chuck said: “it only shows how fast you are when you know your language ”
Chuck: I am a mediocre programmer at best. I am a quick one, though. Further: my knowledge of python is, in a scale of 10, about 5. Hell, I had to *think* to write that tree traverse in the tutorial 🙂
root said: “I’d rather just program in GTK+/C. I don’t think the abstraction overhead is worth the knowledge I sacrifice from knowing what I’m doing, or being in control.
”
Well, it´s all in what you are writing for, not what you are writing in.
If you write in C, do you actually know what a GTK+ call to create a button does? Do you even know more about it than if you do the equivalent python call?
I say no.
And besides, just because a language is nicer, it doesn´t mean you can´t design your application! It´s like saying you prefer keyboards without letters in it, because it´s better to touchtype!
What you express is really the old mentality of “it is harder, so there must be some reason why it´s better”
Sometimes, there is. Sometimes, there isn´t.
Recently I checked out languages like Python and Ruby. Even though Python looks very interesting, I don’t like that OO-add-on. All these calls to “self” look too much of a pain and make the source look not very nice. Same goes for the __xxx__. Ruby has similar syntax issues (in my opintion) plus I am not sure if the bindings for Qt/KDE are up-to-date. Most web sites are out of date (as linked from developer.kde.org).
What I don’t understand is why people have to reinvent the wheel all the time. For me the most beautiful language is still Smalltalk. Unfortunately, in the OSS world it is almost non-existent (except for Squeak). GNU Smalltalk is maintained by one guy and seems to have no bindings for Qt/KDE either. This is really too bad because it offers everything that Python and Ruby have in a much nicer, cleaner syntax.
Romendo: Well, I am using KDE 3.2 beta 2. It doesn´t get more recent that that, and I am using PyQt 😉
There is a slight issue with PyKDE: you can have latest PyKDE and a slightly older PyQt with KDE 3.2 beta 2, but not latest PyQt. At least for a couple more weeks, until PyKDE is made work with latest SIP (yes, it´s a bit tangled).
The __xxx__ calls are because the __xxx__ naming convention basically means: dude, this function is not meant to be called. It´s more or less the moral equivalent of the protected or private keywods in C++.
Usually, the only __ function you ever touch is __init__. The rest is for evil code. And yes, there is some of it in the tutorial 😉
The whole self… well, it prevents shading members of the class, and makes it explicit where stuff belongs. I am not thrilled about it, anyway.
BTW: it doesn´t need to be self. It´s just whatever name you use for the first arg of the method.
Congrats, both coding & writing is nicely done. But I do not understand why you do not use the standard Qt methods for dragging, dropping etc. instead of using your own functions and reassign them. Anyway, I wrote such an application myself (linux.ratsstar.de), and it actually uses XML (an ripoff of OPML, to be precisely), so if you want to know about it, just check it out.
Remarkably that you are here discussing with the readers of the article, too.
Anyway, Python & PyQt need all the publicity they can get because they are a wonderful piece of work.
Doing it this way lets you drag a text clipping from anywhere and drop it as a note.
Even Qt´s docs say dropEvent() probably need to be reimplemented in child classes (but doing acceptAction(), not accept(), my mistake)
But most probably, it´s because I don´t know what I´m doing very well (see “Just a comment” above 😉
This could be pretty useful for small quicks apps that are going to be used internally and not distributed, and little open source apps. I’ve said it once and I’ll say it again, someone needs to buy trolltech and lgpl(or some other non-viral license) it. I don’t know about Python for larger apps though, it’s peformance seems to be wanting unless you write parts of it in C and then you lose a lot of the original benefits of going with python.
Sorry Rayiner, but I’ll stick with C#/Mono/.NET for RAD. The Sharpdevelop port for unix(MonoDevelop) is making huge advances in a short period of time. Too bad that the qt# bindings never got done and that qt has a bad license, because I’m not all that impressed with gtk#. DotGNU is making pretty good headway in their implementation of System.Windows.Forms.
Oh well, you’re never going to be 100% happy with anything.
Well, eric3 is a damn nice IDE and it´s written using PyQt.
Doesn´t seem to have performance problems, either.
After all, the speed-sensitive part *is* written in C++: the toolkit.
Mono is pretty interesting stuff when you shove aside all the politics. MonoDevelop seems to be on the fast track now(they’re using SharpDevelop as it’s base, which is a good thing, instead of Not Invented Here Syndrome. By the way, the dotgnu’s SWF implementation is progessing nicely. That should be even less effort in port if you used pnet SWF with mono(since Dotgnu has XML lackage), but MonoDevelop will be native which will nice and since of the plugin nature of Sharpdevelop/Monodevelop you could easily decide at runtime what assemblies to load on an OS-specific case, so that MonoDevelop can add much more Unix functionality to SharpDevlop without polluting the core code base.
I’m sure many apps are going to run fine with PyQt, but you’re stil not going to get the performance that you can get with .NET/Mono. I looked at eric3 afte reading the article. It looks very sharp. KDevelop 3.x (Gideon) is shaping up very nicely. I’ve got it open right now and can see how the whole re-write was needed badly. this whole new plugin structures is very nice. KDevelop does havfe Python support(probably not as nice as eric3 though).
Ok, you baited me into checking out the CMUCL page;-) I’ll have a look at it. I’m not a complete newbie when it comes to Lisp-based languages….I learned a little scheme when reading “Structure and Interpretation”. I’d be particularly interested in learning more about lambdas/closures and the .NET 2.0 specs that you were talking about the other day.
By the way, when you were replying to Root and talking about RAD with native speeds….Mono will be there soon with SharpDevelop;-).
Oh, and we were talking about wireless under linux the other day. I got my Linksys WC411 running under Slackware 9.1 yesterday. Not too much hassle(it helps when their is a 40 page thread about it at http://www.linuxquestions.org;-). I’m happyily writing this from it and KDE 3.1.4. I think I might compile KDE 3.2 beta later on tonight. I need a heavy compile job to test out cycles on this monster Sager laptop I got last Friday:-)
What Python needs is soft-typing like Lisp/Dylan. It allows you to use optional type declarations on your code. That means you can quickly develop a component, then put in type delcarations in the interface to allow the machine to mechanically check types (and improve performance). And both need some sort of Eiffel’s DBC, while allows for arbitrary mechanical checks.
At the very least, C# needs type inference like ML, to allow you to be statically typed without actually writing type declarations.
KDE probably does need some good C# bindings, if only because it is such a popular language, and has a pretty good implementation. I’m not a big fan of C#, but I have to applaud MS’s compiler team for having the foresight to put powerful features in the language. Sun seems unwilling to go much beyond its very rigid and intentionally unexpressive OOP model for Java.
http://www.kdevelop.org
Also, there’s Oracle Forms Developer and Borland JBuilder. The latter exists also in a “Personal”, free as in fruit juice version.
That said, I think Kylix is amazing. But apparently, not anymore developed.
I seem to recall that Sather had syntax like:
some_variable ::= “foo bar”
Which would be equivalent to something like Eiffel’s
some_variable : STRING is “foo bar”
Except that in that case, if memory serves, some_variable is (at the very least effectively) a constant.
You are welcome to do that, but in the time it takes you to make an app in C, I could make at least two or three in Python, and the users usually wouldn’t notice the difference because most of the performance-sensitive parts of the app will be native Qt code.
Fascinating! For some odd reason, you seem to think the bulk of designing applications is in how fast you can write code. That’s a rather childish and an unpragmatic form of reasoning.
Giving the same experience level, a C coder will write code as fast as Python coder, all things being equal. I spend a lot more time thinking, drawing and designing applications than I spend writing it. In fact, the amount of time I put into researching and reading books just to get the “perfect” and most efficient algorithm, far exceeds the time I spend writing code.
Writing the code is perhaps the easiest part of building an application, at least for me. Planning, designing and researching the components of the application is the painful and resource intensive aspect of application design.
But of course with tools like ‘lazy application development’ who cares, right?
And users will like my app better, because it won’t suffer from security leaks caused by buffer overflows, it won’t leak memory, and it won’t segfault.
You are jumping into conclusions and unfairly generalizing. Your statement will be free from illogical postulations if an “assumption clause” has been agreed upon. The assumption will be that I am a careless, a pathetic and an inexperienced coder who failed to use the tools that prevent common faults in my code.
Users might or might not like your code better. How users feel about your code is independent of which language you use. What users don’t like are applications the seem unresponsive; applications that take a century to load; applications to consume an uncorteous amount of their system resources; and applications that are confusing and complex to use and understand, to mention a few.
For major applications, we need a language that is immensely productive like Python, but native-compiled so they are fast.
There is no scientific evidence that proves the correlelation between programming languages used and a coders productivity. Those are myths and unfounded hype spewed by proponents of managed code and object oriented approach to programming. A coder is productive when he comfortable in his coding environment and when his work is properly planned, designed, managed and efficiently executed. Give a hardcore C++ coder, who has little knowledge of python, a python project to implement and see how productive he will be.
There are several languages that fit the bill, but unfortunately none of them have really first-class bindings to GNOME and KDE. Given equal amounts of time to do the same project, a program written in a high level compiled language will probably be faster. Why? The time a C programmer spends debugging dangling pointers, integer overflows, fussing with types, rewriting large amounts of code while refactoring, compiling over and over, etc, can instead be used optimizing the algorithms of the program.
Absolutely nonsense. See above.
Who cares if optimal code written in C is 30% faster, when almost no programs contain uniformly optimal code?
Who cares? Users care. I care. Lets assume there are two applications that perform the same function. Application A is 30% faster than application B. Which application would you care to use?
Consider: Why can’t Mozilla resize without lagging, even though its written in fairly low-level C++? Its because the core algorithms are not optimized! The algorithms are far more important than the performance of raw generated code, especially for desktop apps.
Are you insinuating that Mozilla wouldn’t have resize issues or will be more responsive if it was written in Python, because then, magically, developers will have more time for tweaking algorithms. I only need to point you to how slow and resource intensive Java applications are to discard your myth. Assuming your theories are correct, then applications coded in higher level languages will be eons faster than those coded in low-level languages. But, of course, that’s not true.
I am willing to bet my finger that Mozilla will be radically slower and significantly less responsive if it was coded in Python than in C++. Have you used an Python applications lately?
If you don’t believe me about the power of Python, read ESR’s essay about it:
http://www.linuxjournal.com/article.php?sid=3882
He thought he was exaggerating too, until I actually tried it. He’s right! I can write working code almost as fast as I can type! And even hastily-written programs are completely readable several months later.
I’m yet to read the link provided. I have nothing against Python as a programming language. I have everything against silly practices and techniques that encourage coders to be lazy and that inspire the next generation of coders to be exponentially dumber. And believe me, we are getting their.
I love programming practices that encourage, control, security consciousness , planning, design, readability, efficiency, resource management courtesy, detailed documentations to mention but a few.
Problems will begin to arise when Joe jumbles together an application written in Python that works okay. However, the application forces other processes to come to halt, the application is ridiculously large, the application is buggy, etc. But Joe has no clue what is wrong or how to debug it, because MR RAD did all the thinking as Joe couldn’t be bothered.
Calm down, man.
Python is a great language and is used to implement things that are used by many people. (Bittorrent for example) I thoroughly believe that python is faster to code, and while most of the time may be spend designing the application, coding time does come into play and perhaps that can be beneficial. This is particularly true with the fact that python is so simple to learn. It can be picked up very quickly. Some of the more complicated mechanisms take a little longer, but most applications either don’t need them or don’t need them implemented immediately.
As for the 30% faster bit. I know this is an overused argument, but for desktop development, it’s largely true. Users are the slow part. An app being written in python does not slow down the start up in any perceivable way. And any functions within the app are mostly slowed by user input. Computers are plenty fast enough to take a 30% performance hit without users noticeing.
The real argument for python comes from the fact that many libraries written for it are very well organized. They use OO techniques as they should be used. This is much less true in C++.
There is really nothing wrong with RAD development. It’s a quick way to get a functional application working. This can be especially important when convincing someone that is dubious about the need of an application to support it. Developing in a low level language later if it is needed. The coding should be quick then anyway, since it’s designed already.
Also, python has first class functions. That’s just plain cool (not to mention useful).