A pair of years ago I tested this programming language called Python, in honor of Monty Python. It's an easy to learn language, in fact the easiness is part of the design, but in this case easy doesn't mean lack of power. Some months ago I developed a little program for a friend, and decided to give Python another go. It didn't let me down.
It's not a compilable language, it's interpreted, but now days, with the amount of power we have under the hood in our computers, this distinction looses sense, at least in most cases. The advantage of a compiled language is it's compact size and it's speed, but in most cases, for programs made for ourselves, that distinction loses it's effect.
Interpreted languages advantages are mostly concentrated in one point: development speed. There are other advantages, but this one is usually the selling point. Of course, it doesn't hurt that they are usually easier to port to other operating systems.
To modify a compiled program, we need to modify the source code, recompile it (complete or partial recompile) and then execute it. If we need to test it step by step, we'll need to recompile it to add the necessary debugger links, which generates a heavier program, and then run the debugger. Once the problem is found, we need to correct the source code and recompile. Even if we notice the problem was in the dataset used for testing, we need to recompile it to get an unbloated executable.
In an interpreted program, the source code is the program, and the interpreting is handled at runtime. If there's some error, we modify the source code and execute again. Debugging is usually done with the same interpreter and the same program, executing the source code step by step. This results in really smaller times between modification and modification, speeding development times a lot.
To this general advantages of interpreted languages Python adds an interactive command interpreter, where we can test commands and see the results instantly, which is really helpful to learn the language. Python can be used to make procedural, functional or object oriented code.A nice perk is that everything in the language is an object, so we get a lot of predefined function like methods with every variable we create.
Python syntax is really clear, and the fact that we have to indent the code for it to use loops and conditions adds even more legibility. Contrary to popular belief, indenting in Python is not burdensome, it comes naturally after as little as half an hour into the learning process.
Lastly, the language itself is open source, meaning that those with the knowledge can modify it, and that you don't need to pay any license to use it. Even more, the programs we develop with it can have any license we want.
With the new Python 3.0 out there, it's a good time to jump on and learn, as a lot of people are doing it right now to see if it suits them so there'll be a lot of people you can ask for guidance.
Showing posts with label Python. Show all posts
Showing posts with label Python. Show all posts
Sunday, December 14, 2008
Saturday, December 6, 2008
Changes in Python 3.0
A new version of Python, 3.0, has been recently released. It has a a lot of changes, and for a lot of people, it has more changes than desirable, so don't rush to instal it, keep on reading and learn before deciding.
Most changes in Pyhton until now have been retrocompatibles. This implied that, unless we had used an obscure quirk of a command that got corrected in later versions, we didn't had much problem while changing versions. Most problems usually had to do with the use of third party libraries that were only compatible with a specific version of Python.
However, while releasing version 2.6 we were informed that it was a transition release, and that they were going to start working on the new version 3.0. We were also told that this new version wasn't retrocompatible, it was going to be a rewriting and general reordering. They even offered in 2.6 some glimpses of things to come in 3.0, that's why they called it a transition release.
Looking through the list of changes in this new release 3.0, you can see that it's really a long list, including changes in command syntax, in command behavior, in data types, in library names and even in command names. This means that before using our old programs in 3.0 we'll have to upgrade them. Luckily, there's an automated toll called 2to3 that does most changes for us, so we'll have to do little else to make most programs work.
An interesting data is that now efforts in development of the language are split between a future 3.1 release for the ones that went through 3.0 and a future 2.7 release for the ones that didn't. 2.7 is supposed to update the language without breaking most of retrocompatiblity.
¿what to do then? That depends in what we have already developed. If it relies heavily in a library that's still not available for 3.0 then don't change, wait for it to release. If it's a big project and even with 2to3 the conversion gets tricky, don't change. If you don't have any of this problems, go to 3.0, it's the road towards a better, cleaner Python.
And as always in this kind of problems, mounting a virtual machine to test changes can save us a lot of headaches.
Most changes in Pyhton until now have been retrocompatibles. This implied that, unless we had used an obscure quirk of a command that got corrected in later versions, we didn't had much problem while changing versions. Most problems usually had to do with the use of third party libraries that were only compatible with a specific version of Python.
However, while releasing version 2.6 we were informed that it was a transition release, and that they were going to start working on the new version 3.0. We were also told that this new version wasn't retrocompatible, it was going to be a rewriting and general reordering. They even offered in 2.6 some glimpses of things to come in 3.0, that's why they called it a transition release.
Looking through the list of changes in this new release 3.0, you can see that it's really a long list, including changes in command syntax, in command behavior, in data types, in library names and even in command names. This means that before using our old programs in 3.0 we'll have to upgrade them. Luckily, there's an automated toll called 2to3 that does most changes for us, so we'll have to do little else to make most programs work.
An interesting data is that now efforts in development of the language are split between a future 3.1 release for the ones that went through 3.0 and a future 2.7 release for the ones that didn't. 2.7 is supposed to update the language without breaking most of retrocompatiblity.
¿what to do then? That depends in what we have already developed. If it relies heavily in a library that's still not available for 3.0 then don't change, wait for it to release. If it's a big project and even with 2to3 the conversion gets tricky, don't change. If you don't have any of this problems, go to 3.0, it's the road towards a better, cleaner Python.
And as always in this kind of problems, mounting a virtual machine to test changes can save us a lot of headaches.
Subscribe to:
Posts (Atom)
