What features of Python 3.0 will change your everyday coding?

Question

Py3k just came out and has gobs of neat new stuff! I'm curious, what are SO pythonistas most excited about? What features are going to affect the way you write code on a daily basis, or have you been looking forward to?

Answer 1

There are a few things I'm quite interested in:

• Text and data instead of unicode and 8 bit
• Extended Iterable Unpacking
• Function annotations
• Binary literals
• New exception catching syntax
• A number of Python 2.6 features, eg: the with statement

Answer 2

Just about all of them as I am taking the release of Python 3 as motivation to learn the language.

Answer 3

Quite frankly, none of it. While I'll probably find myself using some of the new syntax, I mainly use Python for quick and simple scripts and regular expressions.

I think the new features will make a lot of little things a little easier for a lot of people and a few big things easy for a few people. However, I am skeptical of any claims that a lot of people will end up finding massive gains in productivity.

In short, I think these changes will make things a little better overall, but don't expect any miracles.

Answer 4

The print statement. <sniff> I'm starting to miss it already.

Actually, before even going to Python 2.6, we're purging print in favor of logging.debug. This is just to get out of the habit of using print casually for debugging, support and development.

What remains are some programs that actually produce stuff on stdout. For those, we may introduce a 2.6/3.0 compatible "print" function in one of our libraries.

Answer 5

Here's a good article which explains the new features and/or differences with respect to python 2.x verses python 3.

http://www.b-list.org/weblog/2008/dec/05/python-3000/

Answer 6

Despite what they did to achieve smallest possible migration course with interpreted languages, I find the whole release of python3 as ten years of painful path of migration. Therefore I don't find it particularly attracting.

The improvements they did are all good and important. Two different types for strings have been a real source of annoyances everywhere, therefore it's good they got rid from unicode object and introduced bytes object aside now unicode str.

The bignum vs. num -change was from convenience and I think that too was a good choice. In overall they cleaned the language from harmful components they accumulated during the last ten years.

Second worst thing they did was 10% slower implementation, as if speed wouldn't be python's problem already.

I believe the release of python3 pushes down python's reputation rather than improves it. Right now they are back in the start with their language when it comes down to library support.

Answer 7

Dictionary comprehensions aren't necessarily earth-shattering but they're very nice.

While {k: v for k, v in list} is longer than dict(list) it's more flexible and self-explanitory.

Answer 8

Not so much a feature, but I think the library cleanup will be of great help, esp. to new python programmers. On more than one occasion have I wanted to do something in python only to find two included libraries that offer that functionality, with no obvious reason why I should chose one over the other.

Answer 9

Not having to do as much..

• Not having to worry about using unicode() or u"".

• Not having to search though the docs of urllib urllib2 and httplib to find where that functions I need to to encode a file and upload it via a POST request

• Not having to worry about wether except TypeError, something: will catch a TypeError and something, or TypeError into `something..

And conversely, having to look at the docs again! I know python well enough now I can do most stuff without referring to pydoc, but every time that I do, I discover some other useful module or function.

Answer 10

I hope that exception chaining catches on. Losing exception stack traces due to the antipattern presented below had been my pet peeve for a long time:

try:
   doSomething( someObject)
except:
   someCleanup()

   # Thanks for passing the error-causing object,
   # but the original stack trace is lost :-(

   raise MyError("Bad, bad object!", someObject)

I know, I know, adding some context info to the original exception and preserving the original stack trace was possible, but it required a really ugly hack. Now you can (and should!) just:

raise MyError("Bad, bad object!", someObject) from original_exception

and easily get both of the above. So, as a part of my holy mission against lost stack traces:

Folks, don't forget the from clause when reraising exceptions! Thank you.

Answer 11

One of the most underestimated features of Python 3 is the introduction of Abstract Base Classes. This is something that won't revolutionize Python programming straight away, but represents an interesting shift from a loose duck typing approach into the direction of better defined interfaces.

More information can be found in PEP 3119.

Answer 12

Unicode (utf-8) is really important for people living in non-english speaking countries.

I didn't like to specify the encoding at the beginning of the file, because I always forget. Usually my text is compatible with ASCII because I'm using UTF-8, so it is working without the encoding specification. But If I write my name (with an accent) or a € sign, it breaks ... I ended up writing unicode characters with their \uxxxx representation but it is kinda cryptic!