« | » Main « | »

What's in which Python?

Friday 30 September 2011

I'm teaching a class next week, and in their work environment, the students are limited to using Python 2.4. I wanted to be clear about what features of Python they'd have available, and which they wouldn't. The "What's New in Python" docs are very comprehensive, but spread out across many pages and full of distracting details.

So I made this list of the high points, what's in each version of Python 2.x. Items with a star were introduced with a __future__ import.

BTW: there's also a list for the 3.x series: What's in which Python 3?

2.1: April 17th, 2001

  • Nested scopes *
  • "from __future__"
  • Rich comparisons
  • Weak references

Full list of 2.1 changes.

2.2: December 21st, 2001

  • New-style classes
  • Iterators
  • Generators *
  • // integer division
  • Dividing ints can produce floats *

Full list of 2.2 changes.

2.3: July 29th, 2003

  • Set datatype module
  • Boolean datatype
  • Importing from zip files
  • enumerate
  • The logging and csv packages
  • Extended list slicing

Full list of 2.3 changes.

2.4: November 30th, 2004

  • Native set datatype
  • Generator expressions
  • Function decorators
  • string.Template
  • reversed()
  • The subprocess and decimal modules

Full list of 2.4 changes.

2.5: September 19th, 2006

  • The "with" statement *
  • Conditional expressions
  • The functools module
  • Unified try/except/finally
  • Value passed into generators
  • defaultdict
  • any(), all(), min(key=) and max(key=)

Full list of 2.5 changes.

2.6: October 1st, 2008

  • The multiprocessing package
  • str.format()
  • 3.0 compatibility: print function *, byte literals, io library
  • "except" with "as" keyword
  • Abstract base classes
  • Class decorators
  • The fractions module

Full list of 2.6 changes.

2.7: July 3rd, 2010

  • Set literals syntax
  • Dictionary and set comprehensions
  • OrderedDict and Counter classes

Full list of 2.7 changes.

The latest HP circus

Monday 26 September 2011

Last week, Hewlett-Packard did what it seems to do best: thrash in public, fire a CEO, and hire a new one who likely won't work out. The news stories are full of hemming and hawing from the board, and statements about how Meg Whitman is "ideally suited" to "execute on the vision," or some other business gobbledy-gook. Somehow, no one has managed to say what that vision is, other than, "Be huge and make a lot of money."

Leo Apotheker had only 11 months on the job, and when he was hired, was proclaimed as "ideally suited," or "uniquely qualified," or some other synonym for what they've just said about Whitman. I can't follow all the boardroom machinations, but I know that this isn't leadership.

Meg Whitman seems to be a strong personality, but has never run a technology company, and eBay doesn't count: it was a huge consumer of technology, but never shipped products to enterprise customers. If she's a good choice, does that mean that any generic CEO can run HP? Has it really become the modern equivalent of Acme Consolidated?

The whole thing is depressing. As a brand, Hewlett-Packard should mean something beyond, "what's the most profitable business this year?"

And by the way, HP's stock price last week is a perfect illustration of the old Wall St quip, "up on rumor, down on news". Wednesday brought the rumor that Apotheker is out, and Whitman is in, the stock soars 10%, closing up 7%. Friday morning, the news is out, exactly what the rumor had predicted, and the stock falls 5% closing down 2%:

Hewlett-Packard stock last week!

No matter where I look in this story, no one has any idea what they are doing.

Coverage.py v3.5.1

Friday 23 September 2011

Coverage.py v3.5.1 is available. If you haven't tried it before, coverage.py is a code coverage tool for your Python code. Run your tests under it, and it will tell you which parts of your code are not being exercised by your tests.

As I mentioned in the 3.5.1b1 announcement, there's not much new: the one new feature is for people measuring coverage on a number of different machines, then combining the data together for reporting. Now you can specify how differently-named source directories on those machines get combined together. The only improvement since 3.5.1b1 is that this feature now works!

Branch coverage works better on "for-else" structures, and on the "with" statement, so if you've been experimenting with branch coverage, but have been frustrated by false warnings, this release should be much better.

Online Python exercises

Friday 9 September 2011

I've been thinking about online Python learners. There have been some cool examples of online code exercises, like Nathan's Javascript Lessons. These are great because they require absolutely no setup, and can run right on the web page that describes the concepts involved.

But of course, it's easy to run Javascript in a browser. What are the options for doing something similar for Python?

CodingBat provides exercises for Java and Python. Your code is actually run on the server. Generally, this is risky, because Python's dynamic nature makes it notoriously difficult to limit its powers. CodingBat does this aggressively, and manages it only because it limits the code it will run to very simple functions. For example, you cannot import anything.

Another server-side solution is the NCSS Challenge, which uses an elaborate sandboxing technique on the server to run arbitrary Python code. The sandbox is explained in this PyCon AU video by Tim Dawborn. It seems prohibitively complex, but makes it possible to run sophisticated Python code from the browser.

There are other server-side online Python execution pages:

Server-side execution solve the problem of executing Python, but introduces the new problem of keeping the server safe. Can we instead execute Python in the browser? There have been some interesting implementations of this also:

  • Try Python is an in-browser Python implementation using IronPython running in Silverlight. This limits its platform viability, somewhat blunting the benefits of in-browser execution. Also, most of the standard library is missing, and OS services are necessarily limited.
  • Gumby is astounding: Tim Dawborn (again!) and Ben Taylor took CPython, compiled it using llvm, then ran it through an llvm-to-Javascript compiler, to produce a full implementation of CPython that runs natively in the browser. This is one of those dancing bear moments where it isn't that it does it well, it's amazing that it does it at all. The problems are the 790Kb Javascript download, and the limited environmental support.
  • Skulpt implements Python in Javascript, from scratch, so it's really its own Python implementation. Alone among these tools, it experiments with Python access to the browser environment, but still suffers from the in-browser problem of how to provide OS services. Also, because it's implementing from the ground up, it's incomplete.

Reviewing all these possibilities, none are perfect, and some are far from it. And I started to wonder, are online exercises worth all this? After all, the point of learning a language is to eventually write your own code, and that won't happen in a sandbox in a browser. The student will have to install a real Python environment at some point, so why not start with that, and get a better learning environment right off the bat?

Are there other possibilities? Is it important? What about an environment on the student's computer that can communicate result back to the online environment automatically? Or an online environment that can use the student's local resources so the server doesn't need protection?

Software's prime directive

Wednesday 7 September 2011

This morning, a coverage.py user reporting a bug concerning incorrect results said,

seeing things other than 100%, even when I know they're 100% in actuality, somehow manages to drive me up the wall

I know exactly what he means. In fact, the whole reason I started hacking on coverage.py was to keep it from reporting that docstrings weren't executed. That is, I needed to keep it from being stupid. Why wouldn't it drive you up a wall to have a tool report to you something you know isn't true?

As a crude breakdown, software does one of three things: performs some work for you, tells you something, or entertains you. It fails when it doesn't do its job, that is, when it doesn't work, tells you something wrong, or is boring. In the case of coverage.py, it's job is the second kind, it tells you things about your code. The worst thing coverage.py can do is to be wrong.

Writing software involves a huge amount of complexity. We developers need all the help we can get to master the complexity and conquer the problems we face. The last thing we need is to call on an assistant to help, and have it become another source of confusion and uncertainty.

Developer tools that give misleading advice, or warn about non-problems, or put roadblocks in your way, can be worse than no help at all. The prime directive for tools like this is Don't Be Dumber than the Developer. It's why coverage.py has pragmas for overriding its warnings. There's no way a tool is going to always get it right, especially with a dynamic language like Python. The goal is always to make it as smart as possible, but it's bound to have a simplified and limited understanding of the code, especially compared to the developer who can see the big picture. So giving the developer ways to override the savant is crucial: the developer has to remain in charge.

If you use coverage.py, and find yourself shaking your head at how stupid it has been, let me know. I want to make sure that you are in charge, and that it never causes more problems than it solves.

« | » Main « | »