from __future__ import *

[chadwhitacre]

Once AspenWeb/pando.py#228 lands in a release we should upgrade Aspen and add this to the top of all files:

from __future__ import absolute_import, division, print_function, unicode_literals

This is good hygiene and preps us to migrate to Python 3 in the future.

was: use unicode_literals

from future import unicode_literals

@mjallday has it in his test suite, should use generally.

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

I still want this. I also want print_function and division. Queues us up for Python 3.

[chadwhitacre]

Here's the docs on the __future__ module. As mentioned, the reason to do this is to queue us up for Python 3. Best to form those habits now. We are running 2.7 right now, so in addition to the above three we also want absolute_import.

So the action item here is to add the following to the top of all Python files and simplates:

from __future__ import absolute_import, division, print_function, unicode_literals

I recall doing this in configure-aspen.py and having it blow up, so this isn't necessarily trivial.

[zbynekwinkler]

I'll try to give it some time over the weekend.

[chadwhitacre]

@zwn Cool, thanks. :-)

[zbynekwinkler]

I'll update this as I go.

• absolute_import this one is obvious and almost done
• division
• print_function
• unicode_literals

The option -Q warn is giving us some further depreciation warnings. While preparing for 3.x compatibility we might fix those as well.

[zbynekwinkler]

The biggest bummer so far has been that aspen expects Response body to be a bytestring. That kind of surprised me because where else would be a good idea to support unicode than in Response body?

[zbynekwinkler]

I've found this when testing elsewhere/github.py (unittest failed). That's how I have noticed that that get_user_info in bitbucket.py is not covered by any test.

[zbynekwinkler]

response.headers.cookie does not like unicode keys.

[chadwhitacre]

Per IRC, we've got an Aspen ticket underway where we'll address body and cookie as unicode instead of bytestring.

[zbynekwinkler]

locale.setlocale also does not like unicode for the locale name. The rest seems to be working. I'll put it on a branch once the aspen side is done.

[zbynekwinkler]

I see that the default encoding for unicode body of response is ascii.
https://github.com/gittip/aspen-python/compare/issue225#L19R112
Can we make that utf-8? Since default charset is utf-8, it makes sense.
https://github.com/gittip/aspen-python/blob/4708b450160a0f0eaf313dcdd7188ed93117fabb/aspen/http/response.py#L54

[chadwhitacre]

We've landed the Aspen side of this, though there are probably regressions to shake out yet.

[chadwhitacre]

@zwn This is ready again now that #1520 has landed.

Yes, Aspen Response bodies are expected to be bytestrings. They need to be bytestrings on the wire, of course. It's rare with Aspen that you're instantiating your own Responses, and especially setting a body programmatically. Therefore we expect you to encode the body yourself rather than relying on a content-type sniffing algorithm.

[chadwhitacre]

Per IRC, we've got an Aspen ticket underway where we'll address body and cookie as unicode instead of bytestring.

Apparently I lied. The Aspen ticket I was referring to was AspenWeb/pando.py#225, and there we added __future__ imports but we didn't address body and cookie as unicode instead of bytestring. I've reticketed those as AspenWeb/pando.py#254 and AspenWeb/pando.py#255 respectively. Do you want to block this ticket on those?

[zbynekwinkler]

Yes, Aspen Response bodies are expected to be bytestrings. They need to be bytestrings on the wire, of course. It's rare with Aspen that you're instantiating your own Responses, and especially setting a body programmatically. Therefore we expect you to encode the body yourself rather than relying on a content-type sniffing algorithm.

I don't follow. Did you look at https://github.com/gittip/aspen-python/blob/4708b450160a0f0eaf313dcdd7188ed93117fabb/aspen/http/response.py#L54 ? It allows body to be unicode. What is the principle of least surprise? Given a function, that takes two params - data and encoding - where data can be unicode and encoding defaults to utf-8, what would you expect to happen when at the end all you need is a bytestring? Is encoding as hardcoded ascii the answer first on your mind? My answer is encoding with encoding.

Yes, I'd like to block this. Or rather I don't feel like working around these in gittip is worth the time and effort.

[chadwhitacre]

I don't follow.

Right, my second comment basically nullifies my first, sorry. Agreed, let's wait for AspenWeb/pando.py#254.

[chadwhitacre]

Closing in light of our decision to shut down Gratipay.

Thank you all for a great run, and I'm sorry it didn't work out! 😞 💃