robertodealmeida/pydap — pull request #9 by jameshiebert (2014-05-22 23:07:25+00:00)
Title: Develop

### Summary

This PR ports the remainder of the Pydap code to run on Python version 2.6, 2.7 and 3.3. It closes #7 and fixes #8.

Much of this exercise was straightforward, but there were a few points issues on which feedback from others would be valued.

### OPeNDAP, Python3, bytes, Unicode and ASCII

In Python 3, [one needs to be very specific](http://www.slideshare.net/dabeaz/mastering-python-3-io-version-2) about whether one is using raw bytes vs. text in encoded with unicode vs. text encoded with some other encoding, etc. These are different base types in different Python versions, so I've used the `six` module's `text_type` where appropriate.

The problems is that a careful reading of the [DAP 2.0 spec](http://www.opendap.org/pdf/ESE-RFC-004v1.1.pdf) provides little clarity about what the text encoding of a DAP response is *supposed* to be. Actually, section 3.2.3 does specify that the String Type is limited to 7-bin ASCII characters and section 5 places further restrictions on the character sets of variable names.

Because of this, I have changed numerous places in the code--particularly in the DAS and DDS handlers/responses--setting the output encoding to ASCII rather than UTF-8. I don't actually like this... it's limiting the internationalization support and also a wide variety of scientific symbols that would be used in DAP attributes. However, it's true to the DAP spec by my reading. Feedback on this is welcome.

### Conflicting HTTP Request Frameworks

Most of the Pydap client/server code uses `webob`'s `Request` and `Response` objects. However, most (all?) of the testing code uses the `requests` package and the associated API. Both of these packages are fantastic in their own right, but they have slightly different API's.

The test suite [*does* pass](https://travis-ci.org/pacificclimate/pydap/builds/25826934) under all three version of Python, however, I'm nervous that the testing code isn't actually testing the production code (particularly w.r.t. content iteration). In this context, I would just as soon use `webob` across the board.

### Monkeypatching sys.stdin is a bad idea

I [removed one problematic test](https://github.com/pacificclimate/pydap/commit/afab06949e0a54cc38146e3f5e0fa4498612b192) because it was failing, and the setup function monkeypatched sys.stdin, which made it particularly heinous to debug (this makes `nosetests --pdb` disfunctional).

That test just tested a function that dumps to stdout, so I just marked it with a no cover pragma. If there's a better solution, I'm open to it.