Linked by Thom Holwerda on Thu 9th Oct 2008 21:04 UTC, submitted by ganges master
General Development 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.
Order by: Score:
Woohoo!
by ashcrow on Thu 9th Oct 2008 22:17 UTC
ashcrow
Member since:
2008-02-02

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!

Reply Score: 3

RE: Woohoo!
by poundsmack on Thu 9th Oct 2008 22:20 UTC in reply to "Woohoo!"
poundsmack Member since:
2005-07-13

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.

Reply Score: 2

RE[2]: Woohoo!
by sbergman27 on Thu 9th Oct 2008 23:22 UTC in reply to "RE: Woohoo!"
sbergman27 Member since:
2005-07-24

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.

Reply Score: 2

RE[2]: Woohoo!
by Kaali on Fri 10th Oct 2008 05:23 UTC in reply to "RE: Woohoo!"
Kaali Member since:
2005-12-22

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.

Reply Score: 1

RE: Woohoo!
by Liquidator on Fri 10th Oct 2008 06:25 UTC in reply to "Woohoo!"
Liquidator Member since:
2007-03-04

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! ;)

Reply Score: 5

v Late News
by Sabz on Thu 9th Oct 2008 22:56 UTC
RE: Late News
by DoctorPepper on Thu 9th Oct 2008 23:09 UTC in reply to "Late News"
DoctorPepper Member since:
2005-07-12

Um, that would be last Wednesday, October 1st, 2008:

http://www.python.org/download/releases/2.6/

Reply Score: 2

RE: Late News
by aaronb on Fri 10th Oct 2008 18:11 UTC in reply to "Late News"
aaronb Member since:
2005-07-06

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

Reply Score: 2

Yeah, greate
by StychoKiller on Fri 10th Oct 2008 01:13 UTC
StychoKiller
Member since:
2005-09-20

My biggest peeve with python is the use of spaces to delimit blocks of statements. Does somebody have something against punctuation or what?

Reply Score: 3

RE: Yeah, greate
by Clinton on Fri 10th Oct 2008 01:37 UTC in reply to "Yeah, greate"
Clinton Member since:
2005-07-05

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.

Reply Score: 2

RE[2]: Yeah, greate
by RandomGuy on Fri 10th Oct 2008 02:14 UTC in reply to "RE: Yeah, greate"
RandomGuy Member since:
2006-07-30

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.

Reply Score: 3

RE[2]: Yeah, greate
by unavowed on Fri 10th Oct 2008 08:59 UTC in reply to "RE: Yeah, greate"
unavowed Member since:
2006-03-23

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

Reply Score: 2

RE[3]: Yeah, greate
by CrLf on Fri 10th Oct 2008 18:44 UTC in reply to "RE[2]: Yeah, greate"
CrLf Member since:
2006-01-03

Limiting code to 80 columns in this day and age is just ridiculous. There's nobody out there still programming at the console (an 80x25 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")

Reply Score: 3

RE[4]: Yeah, greate
by alopecoid on Sat 11th Oct 2008 05:07 UTC in reply to "RE[3]: Yeah, greate"
alopecoid Member since:
2005-07-07

Limiting code to 80 columns in this day and age is just ridiculous. There's nobody out there still programming at the console (an 80x25 console at least), and everybody else just uses more than 80 columns with no problems.


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.

Reply Score: 1

RE[5]: Yeah, greate
by CrLf on Sat 11th Oct 2008 16:48 UTC in reply to "RE[4]: Yeah, greate"
CrLf Member since:
2006-01-03

I'm not talking about "xterms" here... Do your really mean there are people still using the text-mode 80x25 console for anything more than fixing stuck servers?

Reply Score: 2

RE: Yeah, greate
by jwwf on Fri 10th Oct 2008 02:31 UTC in reply to "Yeah, greate"
jwwf Member since:
2006-01-19

My biggest peeve with python is the use of spaces to delimit blocks of statements. Does somebody have something against punctuation or what?


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.

Reply Score: 3

RE[2]: Yeah, greate
by Kaali on Fri 10th Oct 2008 05:20 UTC in reply to "RE: Yeah, greate"
Kaali Member since:
2005-12-22

Try: python -tt file.py

And enable visible tabs in your editor to detect incompatibilities in the source.

Reply Score: 1

RE: Yeah, greate
by moxfyre on Fri 10th Oct 2008 03:57 UTC in reply to "Yeah, greate"
moxfyre Member since:
2007-10-18

My biggest peeve with python is the use of spaces to delimit blocks of statements. Does somebody have something against punctuation or what?

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 ;)

Reply Score: 2

RE[2]: Yeah, greate
by DoctorPepper on Fri 10th Oct 2008 16:41 UTC in reply to "RE: Yeah, greate"
DoctorPepper Member since:
2005-07-12

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.

Reply Score: 2

RE[2]: Yeah, greate
by alopecoid on Sat 11th Oct 2008 05:05 UTC in reply to "RE: Yeah, greate"
alopecoid Member since:
2005-07-07

...the greatest programming language ever...


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.

Reply Score: 1

RE: Yeah, greate
by Glynser on Fri 10th Oct 2008 07:16 UTC in reply to "Yeah, greate"
Glynser Member since:
2007-11-29

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.

Reply Score: 1

RE[2]: Yeah, greate
by Clinton on Fri 10th Oct 2008 07:49 UTC in reply to "RE: Yeah, greate"
Clinton Member since:
2005-07-05

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.

Reply Score: 2

RE[2]: Yeah, greate
by helduel on Fri 10th Oct 2008 10:13 UTC in reply to "RE: Yeah, greate"
helduel Member since:
2006-07-17

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.


No, just replace the condition to True and you're done.

Reply Score: 1

RE[3]: Yeah, greate
by Glynser on Fri 10th Oct 2008 10:48 UTC in reply to "RE[2]: Yeah, greate"
Glynser Member since:
2007-11-29

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.

Reply Score: 1

RE[4]: Yeah, greate
by helduel on Fri 10th Oct 2008 11:32 UTC in reply to "RE[3]: Yeah, greate"
helduel Member since:
2006-07-17

Yes, that's also a solution, but a green commented-out line is quicker to spot than a "raped" condition.


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.

Also, it's quicker to turn on and off, because it's just a # in front of the line.


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.

Reply Score: 2

RE[5]: Yeah, greate
by Glynser on Mon 13th Oct 2008 08:29 UTC in reply to "RE[4]: Yeah, greate"
Glynser Member since:
2007-11-29

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.

Reply Score: 1

RE: Yeah, greate
by CrLf on Fri 10th Oct 2008 18:51 UTC in reply to "Yeah, greate"
CrLf Member since:
2006-01-03

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).

Reply Score: 4

Solution for indenting blocks of text
by snorkel on Fri 10th Oct 2008 04:22 UTC
snorkel
Member since:
2006-03-16

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.

Reply Score: 2

Clinton Member since:
2005-07-05

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.

Reply Score: 2

Bending Unit Member since:
2005-07-06

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.

Reply Score: 3

Bending Unit Member since:
2005-07-06

About the Eric IDE. I'm sure it is very capable and smart in every way. But the default UI. Do. Not. Want.

Reply Score: 2

Privates
by J.R. on Fri 10th Oct 2008 07:52 UTC
J.R.
Member since:
2007-07-25

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!

Reply Score: 3

RE: Privates
by FunkyELF on Fri 10th Oct 2008 17:09 UTC in reply to "Privates"
FunkyELF Member since:
2006-07-26

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)

Reply Score: 2

RE: Privates
by CrLf on Fri 10th Oct 2008 19:10 UTC in reply to "Privates"
CrLf Member since:
2006-01-03

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.

Reply Score: 2

Python
by Clinton on Fri 10th Oct 2008 07:56 UTC
Clinton
Member since:
2005-07-05

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.

Reply Score: 2

RE: Python
by pawnhearts on Sun 12th Oct 2008 11:38 UTC in reply to "Python"
pawnhearts Member since:
2008-07-04

> 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

Reply Score: 1

python does support curly braces
by ganges master on Fri 10th Oct 2008 08:10 UTC
ganges master
Member since:
2006-05-29

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.

Reply Score: 1

evangs Member since:
2005-07-07


do you know how many hours i've spent debugging where i forgot to place a semicolon in C?


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.

Reply Score: 2

righard Member since:
2007-12-26

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++.

Reply Score: 2

evangs Member since:
2005-07-07

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?

Reply Score: 3

righard Member since:
2007-12-26

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.

Reply Score: 1

from __future__ import division
by FunkyELF on Fri 10th Oct 2008 17:15 UTC
FunkyELF
Member since:
2006-07-26

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.

Reply Score: 2

RE: from __future__ import division
by J.R. on Sun 12th Oct 2008 11:57 UTC in reply to "from __future__ import division"
J.R. Member since:
2007-07-25

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.

Reply Score: 2

Fractions...
by FunkyELF on Fri 10th Oct 2008 18:19 UTC
FunkyELF
Member since:
2006-07-26

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.

Reply Score: 2