Oakwinter.com :: Code

New new new new: context_tools 0.2. Shiny stuff in this release:

• Support for Python 2.4. context_tools now supports Python 2.4, 2.5 and 3.0.

• test_with() now supports multiple context managers (by request).

• Bug fix: yield_with() now plays better with other decorators.

Download the latest release.

Just pushed out to PyPI…

The contextlib module that ships with Python 2.5 and newer is pretty neat; for example, it includes a tool to transform a generator into a context manager. Not a bad trick, but not enough.

context_tools aims to pick up where contextlib leaves off. It includes tools for turning context managers into setUp() and tearDown() methods for unittest- and test_harness-based tests and into decorators for functions and generators.

Interested? Grab the latest version. Both source and eggs for Python 2.5 are available, and just as soon as PyPI adds support for Python 3, a tarball for that will go up as well.

On Monday, Google announced that they were effectively end-of-lifing their SOAP API, back-dated to 5. December. “Announce” isn’t quite the right word, but English doesn’t have a verb for “posted a notice on the API’s site without any heads-up to developers”.

Since several of our applications at work depend on that SOAP API, this threw a bit of a wrench into our day. As a work-around, I spent yesterday coding up a SOAP server that allows applications that use the Google API to continue working. The tool acts as a gateway, translating SOAP calls into requests to Google’s web interface, scraping the result pages and packaging the search results back up into SOAP. It supports all doGetCachedPage(), doSpellingSuggestion() and doGoogleSearch() calls, though search results lack some of the data that the SOAP API provided. I used Net::Google for testing the gateway, and as far as I can tell everything works fine.

Most of my development time was spent wrestling first with SOAP::Lite, trying to figure out exactly what incantations I needed to get a bare-bones SOAP server working, then with the perl regexes needed to scrape the result pages (grrr…special cases…grrr). In the end, we had a releasable product within 24 hours of reading about the discontinuation of the API, so I’m pretty happy with myself, especially since I’d never done server-side SOAP stuff before.

We’ve released the current 0.1 version of code, with plans for a faster 0.2 soon.

functional 0.7.0 has been released to PyPI and to the project’s own website. Included in this release:

• Several reference counting-related bugs were squashed.

• The C implementation now supports Python 2.3, in addition to 2.4 and 2.5.

• The test suite has been enhanced with fine-grained checking for reference counting bugs to try to keep the C version correct.

• Two new functions were added, map() and filter(), which function much like the Python built-ins of the same name — but without some of the built-ins’ weird behaviour.

Lastly, I know I said before that functional would include a functional.bwcompat submodule that contained exact copies of some Python builtins, the aim being to ease the transition to Python 3.0 for larger projects (when map() and filter() will no longer ship). I changed my mind for two reasons: 1) converting map() and filter() calls to list comprehensions will be part of a larger Python 2.x -> Python 3.x conversion, and 2) the more I waded in, the more I realised that Python’s built-ins have some really twisted semantics. So, instead of duplicating the builtins, I opted to write sane versions of these functions, which can be found at functional.map() and functional.filter().

Python Eggs of both versions, for Python 2.3 - 2.5, as well as tarballs, are available from PyPI.

Version 06. of the functional package has been pushed out to PyPI and the project’s own website. This release features:

• functional.flip will now reverse all non-keyword arguments, as opposed to simply reversing the first two as it did in version 0.5.

• functional.compose now comes with an optional unpack parameter to make up for some of the differences between Python and Haskell (which inspired most of the functional package), namely that Haskell functions are fully curried and Python functions usually aren’t.

  The unpack parameter means that you can now do something like this with compose:

  f(*g(*arg,**kw))

  i.e., automatically unpacking g’s return value and passing the result to f.

  To get this functionality, you’d write something like

  compose(f, g, unpack=True)(*args, **kwargs)

• Add weakref support to flip and compose objects in the C version.

• Sundry performance improvements for the C implementation.

So, there was originally supposed to be a Perl version of svnmock included in this release. I spent a day or two working on it before remembering how much I hate Perl. svk rm branches/perl felt somehow purifying.

On the upside, recoding the package from scratch gave me some good ideas about how to improve some things in the Python version. The main change in the 0.3 release is that you no longer have to explicity declare and directly manipulate a MockSession object; svnmock.mock takes care of creating the inital MockSession for you, then provides convenience add_command, add_error, etc, module-level functions to manipulate it. This turns out to be a big win in practice.

In other good news, svnmock’s internals will be serving as the model for the rewrite of DBD::Mock that I’m working on. DBD::Mock’s guts are currently…well…not something you’d bring home for dinner at your parents’. Again, this will be a big win, both in terms of code maintainability and in functionality.

The functional project has seen a lot of work since its inception (which predates its announcement). Version 0.1 was released on 19 January, and now less than two weeks later, version 0.5 is making its way to PyPI.

This latest release sees the project split into two branches. One is written, as before, in pure Python, targeting readability and portability. The second is coded in C, aiming for raw performance. Both support the same functionality and pass the same test suite.

Speaking of functionality…I was digging around the itertools module the other day and what should I discover but pre-existing implementations of most of functional’s members. All the duplicates have been stripped out for the 0.5 release. I’m hoping to add more useful higher-order tools to replace them.

Well, released a few days ago, but still.

The big news for 0.2 is the addition of tracing support and a rearrangement of the internals to support it. svnmock.trace allows you to keep a running log of which API functions have been called, with what arguments and what it returned (it logs raised exceptions, too!). You can then pretty-print the log and examine it to make sure things are going as planned.

Why would you want to do this? It’s great for quick debugging work when you don’t want to spend quality time with svnmock.mock, scripting up an entire session. That session may involve thousands of API calls, whereas svnmock.trace can skip directly to the area you’re concerned about.

On the horizon for 0.3:

• A tool to turn the output captured by svnmock.trace into a MockSession object.

• A perl port. svnmock -> SVN::Mock.

After spending this past week madly writing documentation for svnmock, I’ve finally finished the last bit of the reference manual. Version 0.1, the initial public release, is currently making its way to SourceForge, the Python Package Index and the project’s own site.

Version 0.2 should be out fairly soon (if not later today). It will include support for tracing API calls, as opposed to making assertions about them.