Oakwinter.com :: Code

I’ve recently set out to check off a number of the “remove x, y and z” items from PEP 3100, which details “miscellaneous Python 3.0 plans”. My latest of these was removing reduce(), map() and filter() from the built-in namespace.

The biggest hurdle wasn’t removing them a the C level; that took about 45 seconds. The main issue — which ended up taking 4 or 5 hours — was rewriting every single usage of map(), filter() and reduce() in the standard library. map() and filter() were pretty easy: you just change them to list comprehensions. reduce(), on the other hand, was a something else.

See, reduce() isn’t used that often in the stdlib, but when it is, it’s generally used in some hideous combination with map() and filter() that makes it extremely time consuming to rewrite. What makes this even better is that these chunks of code are usually in places without test coverage, meaning there’s no easy way to verify that what I’ve done is right.

To make life easier for large projects that make heavy use of map() and friends, I’m adding a functional.bwcompat submodule to functional. This will contain map(), reduce(), filter() and any other functional programming-related tools that will get kicked out of mainline Python come the 3.0 release. All you’ll need to do to make your code work is a simple

from functional.bwcompat import map, reduce, filter

and everything will work as before.

functional.bwcompat will make its debut in functional’s 0.7 release.

As promised, a word on the newest typecheck derivative, type_algebra.

type_algebra is being spun off to hold things like Xor(), Not(), Any(), i.e., things that are more neat than they are useful. It also serves as a good, easy example of how to extend typecheck for one’s own ends.

With this in mind, a few other things are going in: first up, a Nothing() class to complement Any() — where as Any() approves everything, Nothing() approves, well, nothing.

I’m probably going to add smarter versions of And() and Or() classes with beefed up intelligence as to how to simplify certain types of type expressions. Again, things that are cooler/interesting than they are useful/practical.

While tarballs aren’t yet available (type_algebra will ship with typecheck 0.4.0), you can follow along at home via the WebSVN viewer.

typecheck has kinda been on the back burner for…oh…the last few months, let’s say. In my defense, I’ve been a bit busy, primarily with the “travelling around Europe” thing. However, I’ve also been hard at work at a PEP to add function annotations to Python 3.0 — a project I hope to have more news on shortly.

Today, however, typecheck took a good-size surge forward. The main thrust of the 40+ commits were to bring typecheck more into line with the style of function annotations that Python 3.0 will have. To this end:

• In past releases of typecheck, it’s been required that every parameter have a type annotation. In 0.4, this will change; type annotations, now done exclusively through keyword arguments, will be completely optional. To wit, with typecheck < 0.4, this:

  @accepts(Number, Number)
  def foo(a, b):
      ...

  becomes

  @accepts(a=Number, b=Number)
  def foo(a, b):
      ...

• Since types are now optional, there’s no need for things like Self(), which will go away

• The dual spellings of types for *vargs and **kwargs are going bye-bye. Whereas in typecheck < 0.4 these were equivalent

  @accepts(vargs=Number)
  def sum(*vargs):
      ....
  
  @accepts(vargs=[Number])
  def sum(*vargs):
      ....

  In typecheck 0.4, the latter signature will expect that each argument to sum is a list of Numbers.

In addition, the Xor(), Not() and Any() annotation classes are going away; they’re being spun off into a separate type_algebra package that will be shipped in typecheck’s contrib directory. More on that later, too.