Let's start with what I really don't like: Invisible syntax sucks. Big time.
When your application complains about some spaces in your indentation, you know that you've done something wrong. So you load the source back in the editor, but you don't get it. It looks perfect. But it's not. This is because tabs are different from spaces, and spaces and tabs are a very very very different thing. So Python says.
There is nothing cool about this particular feature, except the enforcing of 'good looking code', and I find it very very confusing.
On the plus side, throwing together pieces of code that would simply be run is quite cool, not to mention the ease with which you get to do certain operations when compared with C/C++. On the other hand, the ease of use is actually reflected in the run times and probably beginner users like me will always make sluggish applications.
Another thing that I don't like so much is the fact that you don't have error checking on the run trails that you don't get to touch. So for example if you write a function and you have somewhere a misspelling, the error might pop up to you only in the rare case you might hit that line/trail. This is where a compilation stage becomes really really helpful, in my opinion, because quite some time is wasted on getting your code tested for the basic requirements (like not mistaking setGeometry for setgeometry).
The second part of my explorations with PyQt is the Qt4 framework(s), quite different conceptually from what I used to know from the Qt3 that I used so much some time ago. Better? Arguable, but my instincts were trained to use the Qt3 way of thinking, so I am not drawing any conclusions.
In the mean time I am really happy to say that it's pretty fun to use so far. If performance is not necessarily your goal, Python might be the language of choice.
Well, a good .vimrc helps with indentation. This is why I consider vim to be a sane editor unlike others :)
ReplyDeleteAs for errors, I come to like the way Haskell reports them. If you have no errors at least you know that your code will not segfault because of type mismatch. But I don't want to highjack this into another Haskell ramble.
I have no problem with editing - in Windows, Notepad++ does a great job, in Linux kate is a very good editor too; even vim would do, or any other one.
ReplyDeleteThe problem is when you don't see the spaces. You don't see that you have four spaces or eight instead of one tab. This is why copy-paste will be a dangerous thing to use in python, simply because what you see is not exactly what you might get.
The side effect, that the code looks nice, is a good thing, but really, it was a bad design choice.
Yeah, you can set up Vim to show the tabs. This is what I have in my .vimrc:
ReplyDeleteset listchars=precedes:<,extends:>,tab:»-,trail:·
You can probably have something like that in other editors too.
As for the unused run trails: they should ALL be used. They should be used by your automated tests (they give your better error checking than any compiler would).
Of course, I can only agree - tests should cover all the cases. but not always you cover all the cases - mostly because you don't always want to write in a TDD fashion - some things are just fast-written programs that do something.
ReplyDeleteMy work in python was simply to watch some logs and do some stuff with it - after weeks of working, the python code crashed - because it received garbage. Of course I haven't checked all the exceptions, mainly because I am not accustomed to them nor did they seem important - but the things I wrote in python are not mission critical, and there's always a fall back if something is broken.
Not all code is written for perfection... That's my point. :)
Of course, you have to strike a balance.
ReplyDeleteIf you write a small application that does something not very important, probably 100% code coverage is not a must. For small apps you can probably test the new features by hand, as you write them.
On the other hand, for large-ish apps that actually do something worthwhile, a good testing harness is probably a good idea. Writing an application in a TDD-manner not only gives you a bit of peace of mind (of course, you have to remember that tests are not perfect), it usually leads to better code as well.