Submitted by Python 2.6 has been released on October 1st. The major theme of this release is preparing the migration path to Python 3.0, a major redesign of the language. Whenever possible, Python 2.6 incorporates new features and syntax from 3.0 while remaining compatible with existing code by not removing older features or syntax. See the what’s new docs for more details.
This makes me quite happy. Python is an amazing language … if you don’t know it yet do yourself a favour and take the 20 minutes it takes to learn it … when you have a problem and solve it elegantly with a small amount of Python code you’ll thank yourself!
agreed, though i would say to anyone who plans on starting in at this point, wait for 3.0. there are some major changes to the architecute and syntax, not to mention the removal of old and unused bits. 2.6 is a stepping stone for the transition, and 3.0 is shaping up rather nicely.
And will be out next week or so, IIRC. I haven’t RTFA’d, and it may cover that. But no one should be left thinking that 3.0 is 6 months away or anything. 😉
3.0 fixes some niggling design issues. After 17 years, Guido and the other devs have swatted a few flies. There is no reason not to start learning with 2.6, 2.5, or 2.4. One might want to upgrade from < 2.4 before starting.
I don’t think 3.0 will be adopted for a long time. So if you wish to distribute your applications, or if you do web applications (e.g. Django, Turbogears) and serve on a hosted platform, even 2.6 will be too new target.
Many distributions still only have Python 2.4.
For personal projects, sure, go ahead and use Python 3.0, it needs testing.
It is a nice language, even often used to teach programming in general. Some links of interest:
How to Think Like a Computer Scientist
http://openbookproject.net/thinkCSpy/index.xhtml
A Byte of Python – Python eBook
http://www.swaroopch.com/notes/Python
Introducing mod_python
http://www.onlamp.com/pub/a/python/2003/10/02/mod_python.html
Mod_python Manual
http://www.modpython.org/live/current/doc-html/
Some Mod_python Examples
http://www.modpython.org/examples/
Enjoy yourself!
why would OSNews post something so late? how long ago was Python 2.6 released
Edited 2008-10-09 22:56 UTC
Um, that would be last Wednesday, October 1st, 2008:
http://www.python.org/download/releases/2.6/
You could have submitted this as news if you already had this extremely urgent and life changing info
Edited 2008-10-10 18:16 UTC
My biggest peeve with python is the use of spaces to delimit blocks of statements. Does somebody have something against punctuation or what?
I thought that would bug me when I first started using Python back in the 1.x days, and it did. However, it really stops being an issue after just a short while.
While I’m a die-hard fan of parenthesis and curly braces, I think Python’s syntax forces good code formatting and makes your code very easy to read. Also, when a problem comes my way, the first language I reach for to solve it is Python, so I think the Python team must be doing something right; at least from my point of view.
Seconded. Plus, there’s a tool for those who want to program in python and still use curly brackets, IIRC.
The main difficulties caused by the significant indentation thing are:
a) Immediate yuck-reaction from former C programmers and those scarred by non-free-form FORTRAN.
b) Copying and pasting from forums gets harder. Whether or not this is bad is up to debate.
c) Mixing of tabs and spaces, especially in projects with more than one developer. If you can’t get a bunch of people to follow the same coding style OR use a tool that changes the code accordingly, Python is probably the least of your problems, as in case b).
I’ve only used Python recently because it’s just so much easier to remember/relearn than e.g. C++, especially if you just program in your spare time, for fun.
Except that if you want to keep your code width limited to, say, 80 columns, then in many cases you are forced to use backslashes at the end of a line to inform python that you intend to continue it in the next. I personally prefer braces or “end” keywords over having to do this manual dance, which sometimes makes me feel I’m writing for the C preprocessor.
Example:
$ cd /usr/share/blender/scripts && grep ‘\\$’ *.py | wc -l
938
Edited 2008-10-10 09:02 UTC
Limiting code to 80 columns in this day and age is just ridiculous. There’s nobody out there still programming at the console (an 80×25 console at least), and everybody else just uses more than 80 columns with no problems.
You may say long lines make code more difficult to read, but if you limit yourself to lines with at most 80 characters (excluding leading whitespace), you won’t that that big of a need to break statements into multiple lines.
But forgetting that, most statements that can become longish can also be broken in multiple lines without backslashes (argument lists, conditional statements, …). Every statement that requires something more can have that something more on another line without using backslashes.
Actually right now I can’t see anything that can’t be broken, other than strings… (eg: print “some” \ “string”)
You would actually be surprised just how many people are still doing this. I’m surrounded by them. And, yeah, I think it’s borderline ridiculous.
I’m not talking about “xterms” here… Do your really mean there are people still using the text-mode 80×25 console for anything more than fixing stuck servers?
I’ve programmed a decent amount of python and I still agree. I do appreciate that it forces sane indentation and so helps readability, but the problem is that you get a source of bugs that is just about invisible. By missing an indent (space), you can end up with an if statement where the last statement you believe to be in scope is actually outside, and thus executed regardless of the if condition. This does not actually happen often. But when it does, it’s a bitch to find.
My point? Syntax elements should be visible. Other than that, love python.
Try: python -tt file.py
And enable visible tabs in your editor to detect incompatibilities in the source.
Well, this is everybody’s big pet peeve with Python. The first time I thought about switching from Perl to Python, I saw the whitespace thing and decided to ignore it for the next 3 years. Boy, big mistake. Now that I use Python for practically everything and love it to death, I don’t notice the whitespace issues one bit.
I sometimes think Guido (Python’s creator) takes a perverse delight in turning away all of us shallow-minded programmers. He thinks to himself, “Oh gosh, there goes another fool passing up the greatest programming language ever, with no idea of what he/she is missing.” Well, I’m proud to have become a true believer
I totally agree with you. I used Perl for about seven years, pretty heavily, before getting into Python.
I tried to learn Python a couple of times, but like others have said, the whitespace thing through me off totally. In mid-2005, I took a contract with IBM, and the group I worked with was heavily into Python, so I bought “Learning Python” and the rest is history. Like parent said, I do not even notice the whitespace thing any longer, and find the readability of Python to be head and shoulders above Perl (and most other languages as well).
Advice to those who still scoff at Python because of enforced whitespace rules: Just try it. Grab a copy of “A Byte of Python” or perhaps “Dive into Python” and just do it, you really won’t be sorry.
I don’t know man. I mean, I think Python’s string formatting features are pretty bad. Look at the way Groovy handles strings and interpolation… so much more elegant.
In fact, look at the way Groovy does closures. It’s actually unbelievable how much you can accomplish in Groovy in just a few lines of code… and it is readable too.
Now, I’m not saying Groovy is the best programming language ever, but I’m just making a point.
I liked that in the beginning, actually, since I’m formatting and indenting my code anyway, and I liked it to be forced to do that.
But now, I also see the disadvantages: Whenever you copy & paste code, or you move some code block to somewhere else, it’s just not as convenient, because you always have to look that you’re doing it correctly, even if you’re just testing something quickly.
And also, it’s a problem when you want to comment out an if- or while-line so that the condition is gone and the code is definitely executed. Because if you do that, you have to de-indent the code block, and things might get very messy that way.
So those are the drawbacks for me, but of course it’s also got some nice advantages.
That is true to some degree. You usually notice that problem the most when you cut and paste code from one editor to the other. Editors with good Python support usually fix any tab width inconsistencies or tabs vs. spaces for you though.
No, just replace the condition to True and you’re done.
Yes, that’s also a solution, but a green commented-out line is quicker to spot than a “raped” condition. Also, it’s quicker to turn on and off, because it’s just a # in front of the line.
Wenn you comment out the previous conditions, it is as easy to spot. Of course, you have to type True or 1, but this shouldn’t be a real problem.
That depends greatly on coding style. If you write something like
if (x < y) {
// do something
}
it’s not just placing a # in front. I don’t believe either that just the possibility to just place a # in front of a line for debugging purposes is so a great time saver in view of all the curly braces you have to type and keep track of.
So, it’s more a matter of taste or habit. For me the Python way is the way I like it to have.
Well in C-style languages I usually do the following style:
if (condition)
….blablabla();
or:
if (condition)
{
….blablabla();
}
So in that case, it’s also just a // in front of the line to get temporarily rid of the condition. And it would be nice if it would be that easy in Python as well. But to be honest, I never used a “real” Python IDE, maybe they handle it correctly.
That seems to be everybody’s pet peeve… everybody that hasn’t programmed more than an hello world in Python, that is…
I’ve been there, so I’m speaking from experience. But once you start using Python instead of just reading about it, you realise that the whitespace rules are mostly invisible… I don’t remember the last time I had some problem related to whitespace indentation. Actually, I don’t remember _ever_ having such a problem…
But you end up noticing something… in other languages. I now find myself looking at C, java, etc. and thinking that they look messy (the same thing I always thought about perl). The absense of most delimiters in Python makes code look clean and concise (and easier to read).
Don’t use a simple editor, use something that is made for python.
Here are some examples:
eric4 http://die-offenbachs.de/eric/index.html
Pyscripter: http://pyscripter.googlepages.com/
(if you are running on windows this one rocks, has a few
issues, but can debug in threads and has excellent code completion and help integration)
Eclipse and Pydev are not bad either:
http://pydev.sourceforge.net/
and if you want a commercial IDE Komodo from active state is very good.
I’ll second Eric 4 and PyDev as good, free editors. I like PyDev extensions better, but it costs a bit of money. If you’re looking for the best Python editor out there and have a couple hundred dollars to spend, WingIDE is it.
Komodo Edit is free though and I personally think it is the best scripting editor. Eclipse is very flexible and sometimes great but most of the time I want something that just works.
I’ve had some problems earlier with Linux running Komodo because of it using Mozilla. Basically the operating system couldn’t see the difference between different Mozilla applications so I could only have one open at a time. That was however distro specific and hopefully solved by now.
About the Eric IDE. I’m sure it is very capable and smart in every way. But the default UI. Do. Not. Want.
Personally, I like Python…but it has a serious shortcoming when it lack private class members. If they would just drop the ___member___ syntax for “privates” and add REAL privates I would be happy. They could even just make the variables private by default!
Agreed. The fact that you can change any attribute of any class makes some things confusing. Lack of documentation makes it hard to tell how to use classes in some cases. This is one place where Java is nice. Getters and Setters are explicit. You know that calling obj.setFoo(bar) will do everything you need. In python, you may or may not have to call obj.foo = bar and then call obj.recalc() depending on if the author of the class is looking for it in __setattr__(self)
Access control is seriously overrated…
I agree that the “__member__” and “__member” conventions are not that visually elegant, but programming in Python isn’t just about learning a new syntax, it is also about learning a different way of organizing your code.
All those defensive measures in other languages exist because you must protect your interfaces at all costs. The dynamic nature of Python means you can more easily change those interfaces without breaking code that relies on them. Now, Im not saying that access control is unnecessary, but I can say that in, for instance, Java, it mostly forces you to write more code often for very little gain.
I think one thing that really illustrates the difference between Python and other languages in this matter are properties. In other languages properties exist so you can write less (foo.x instead of foo.getX()), but in Python properties exist so you can instantly turn a direct attribute access into a method without breaking your interface or having to refactor code.
And one thing makes me wonder… If Python lacks access control that much, then why are people writing robust applications in Python, and why are people writing flaky applications in other languages… The brain is a finite resource and maybe not having to obsess about protecting your interfaces from all kinds of abuse frees you to write better interfaces and better code.
I’d just like to say that I have coded in C, C++, Java, C#, Pascal, Perl, Ruby, Python, and a few other languages and Python is by far my favorite one to work with. Sure, it doesn’t do threading as well as other languages and it may not be as scalable, but I have never hit any of those barriers in my use of it and it has served me extremely well for many years. My gratitude goes out to all those who work on and make Python available.
> Sure, it doesn’t do threading as well as other languages and it may not be as scalable
there’s new multiprocessing module in 2.6 check it out.
and it could scale really well in the right hands
the syntax is just #{ and #} instead of { and }, here, look, this is valid python code (i’m indenting with dots because osnews won’t let me use <pre>)
if (a == 5): #{
….print “foo”;
}#
else: #{
….print “bar”;
#}
ugh. when will you people realize that it’s just syntax? and the less syntax you have, the better — less visual noise, less typos, less things to learn, less special cases, one-obvious-way-to-do-it, etc. etc.
do you know how many hours i’ve spent debugging where i forgot to place a semicolon in C?
every time i program in C, i realize how much its syntax is redundant and overcomplicated. just forget to place a semicolon at the end of a struct in an include file, and you’ll realize that too.
0? The lack of a semi colon makes the statement invalid and thus it will be caught by your compiler. If your compiler doesn’t catch it, turn on all warnings. If that still doesn’t work, your compiler is horribly broken and you should get a new one.
Useless programmers complain about indentation in Python. Those same programmers complain about semicolons in C.
Though a code that lacks a semicolon somewhere probably won’t compile, (so debugging might be the wrong word) the compiler can sometimes give very long, and very unhelpful error messages when forgetting a semicolon. This is worse in C++.
When I was an undergraduate one of the modules I did required me to write a Java compiler. To make things “easier”, I logged the error messages as numeric codes. While it appeared to be a good idea at the time, it soon became obvious why this approach sucked.
If you had used my compiler to compile your Java code and received an incomprehensible error message, is it Java’s fault or is it my compiler’s fault?
I like the C and C++ syntax allot, I did not mean do blame the fault on them. But because both languages have a rather liberal syntax, it can sometimes be impossible for a compiler to guess what the user meant to do. That is just an inevitable side effect of a liberal syntax, Pyhtons syntax prevents this side effect, with the down side that I ca’n’t, in my opinion intend code properly.
I’m disappointed that the new division model isn’t in this release.
In my opinion, the way that division will be handled in python 3000 is the way that every language should handle it.
The result of a division operation is always a real number. This is the way it is in real life. If you were reading a math formula in a text book, economics book, or anything, division results in real numbers. If you wanted integral division, it would be marked explicitly. With Python 3000, that’s the way it is. You want integer division… do int(12/5) or 12 // 5.
It just makes so much sense. Integer division is the exception, not the rule.
How is real numbers managed in Python then? Because in most other languages the float/double is broken by design, and relying too much on the inaccuracies in its implementation can backfire bigtime. If that is the case in python as well, then I disagree that this should be the default behavior.
Fractions in Python 2.6 are a nice addition but leave much to be desired.
The good stuff…
>>> from fractions import Fraction
>>> f1 = Fraction(1,3)
>>> f2 = Fraction(5,8)
>>> f1
Fraction(1, 3)
>>> f2
Fraction(5, 8)
>>> f1 * f2
Fraction(5, 24)
>>> f1 / f2
Fraction(8, 15)
>>> f1 + f2
Fraction(23, 24)
>>> f1 – f2
Fraction(-7, 24)
The okay stuff…
You can’t have reals as numerators or denominators so you can’t have pi/2
But you can turn a real into a fraction…
>>> import math
>>> (math.pi).as_integer_ratio()
(884279719003555, 281474976710656)
>>> mypi = Fraction(*(math.pi).as_integer_ratio())
>>> mypi
Fraction(884279719003555, 281474976710656)
>>> float(mypi)
3.1415926535897931
>>> mypi / 2
Fraction(884279719003555, 562949953421312)
The bad stuff….
This should be handled but it isn’t….
>>> a = Fraction(1,2)
>>> b = Fraction(2,3)
>>> Fraction(a,b)
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
File “/tmp/python/lib/python2.6/fractions.py”, line 99, in __new__
numerator = operator.index(numerator)
TypeError: ‘Fraction’ object cannot be interpreted as an index
Maybe it will improve.