Comments on: WebOb http://blog.ianbicking.org/2007/08/18/webob/ Tue, 07 Oct 2008 01:56:32 +0000 http://wordpress.org/?v=2.2.3 By: Jim http://blog.ianbicking.org/2007/08/18/webob/#comment-1182 Jim Sat, 29 Sep 2007 18:25:47 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-1182 I understand why you did it, but most other Python refers to character encodings properly. For example u"".encode(...), genshi.core.Stream.render(encoding=...), # -\*- encoding: ... -\*-, etc. IMHO it's better to have all the Python consistent and keep the charset an unfortunate artefact of the file format rather than have the Python disagree. Maybe just provide both? I understand why you did it, but most other Python refers to character encodings properly. For example u”".encode(…), genshi.core.Stream.render(encoding=…), # -*- encoding: … -*-, etc. IMHO it’s better to have all the Python consistent and keep the charset an unfortunate artefact of the file format rather than have the Python disagree. Maybe just provide both?

]]> By: Ian Bicking http://blog.ianbicking.org/2007/08/18/webob/#comment-1167 Ian Bicking Fri, 28 Sep 2007 16:11:51 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-1167 Jim: charset is meant to match `text/html; charset=utf8`, where the name is "charset". To me this felt like the most obvious name as a result. If it's something of a misnomer then I'm only copying the misnomer (which I didn't even realize -- I suppose there's really just one charset in Python, unicode, and it treats *everything* as an encoding, so I don't really have a distinction in my head between the two concepts). Jim: charset is meant to match text/html; charset=utf8, where the name is “charset”. To me this felt like the most obvious name as a result. If it’s something of a misnomer then I’m only copying the misnomer (which I didn’t even realize — I suppose there’s really just one charset in Python, unicode, and it treats everything as an encoding, so I don’t really have a distinction in my head between the two concepts).

]]> By: Jim http://blog.ianbicking.org/2007/08/18/webob/#comment-1162 Jim Fri, 28 Sep 2007 00:11:32 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-1162 The charset attribute is a bit of a misnomer. You aren't looking at the character set, you are looking at the character encoding. For example, UTF-8 and UTF-16 are the same charset but a different encoding. Any chance of changing it to be more accurate? The charset attribute is a bit of a misnomer. You aren’t looking at the character set, you are looking at the character encoding. For example, UTF-8 and UTF-16 are the same charset but a different encoding. Any chance of changing it to be more accurate?

]]> By: Simon Willison http://blog.ianbicking.org/2007/08/18/webob/#comment-242 Simon Willison Mon, 20 Aug 2007 13:17:52 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-242 Hey Paul - I hadn't seen WebStack. Is there any chance you could put the readme.txt and docs/ files online so they can be viewed without downloading the archive? Makes it much easier to link to things. Hey Paul - I hadn’t seen WebStack. Is there any chance you could put the readme.txt and docs/ files online so they can be viewed without downloading the archive? Makes it much easier to link to things.

]]> By: Paul Boddie http://blog.ianbicking.org/2007/08/18/webob/#comment-240 Paul Boddie Mon, 20 Aug 2007 10:59:23 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-240 Simon: "I’ve been talking to both Ben Bangert and James Gardner about the possibility of making the Django and Pylons/Paste request/response objects compatible with each other in some way - either through changes to the API or just by ensuring they are similar enough that a very simple bi-directional conversion could be possible." Of course, such things should be possible: WebStack shows that very few request/response object features are so exotic that such objects cannot be manipulated using a common abstraction. Simon: "This would make code written against Django and code written against Paste interchangeable, which would be a massive boost for Web programming on Python in general." This is probably possible already with WebStack in that Django is supported (unless the API is changing a lot in recent snapshots) along with WSGI (but not Paste explicitly). And along with a bunch of other frameworks, of course. Simon: “I’ve been talking to both Ben Bangert and James Gardner about the possibility of making the Django and Pylons/Paste request/response objects compatible with each other in some way - either through changes to the API or just by ensuring they are similar enough that a very simple bi-directional conversion could be possible.”

Of course, such things should be possible: WebStack shows that very few request/response object features are so exotic that such objects cannot be manipulated using a common abstraction.

Simon: “This would make code written against Django and code written against Paste interchangeable, which would be a massive boost for Web programming on Python in general.”

This is probably possible already with WebStack in that Django is supported (unless the API is changing a lot in recent snapshots) along with WSGI (but not Paste explicitly). And along with a bunch of other frameworks, of course.

]]> By: Ian Bicking http://blog.ianbicking.org/2007/08/18/webob/#comment-233 Ian Bicking Mon, 20 Aug 2007 04:32:15 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-233 Multiple values are of course supported (it's a dictionary). Because no clients I know of include the path and domain attributes, I'm not that interested; I find the Cookie objects really lousy, and I don't want to expose them when they don't carry any meaningful information for the majority of user agents. If you are in an environment where there are unusual user agents that send more information you can parse it yourself easily enough (`c = Cookie.SimpleCookie(); c.load(req.headers.get('Cookie', ''))`). Multiple values are of course supported (it’s a dictionary). Because no clients I know of include the path and domain attributes, I’m not that interested; I find the Cookie objects really lousy, and I don’t want to expose them when they don’t carry any meaningful information for the majority of user agents. If you are in an environment where there are unusual user agents that send more information you can parse it yourself easily enough (c = Cookie.SimpleCookie(); c.load(req.headers.get('Cookie', ''))).

]]> By: Jim http://blog.ianbicking.org/2007/08/18/webob/#comment-232 Jim Mon, 20 Aug 2007 04:19:58 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-232 > Do clients send structured cookie information? Yes. At the very least, multiple values are incredibly common (e.g. Cookie: foo=bar;baz=qux). Clients are also supposed to include the path and domain attributes when they are specified by the server (but they often don't). > Do clients send structured cookie information?

Yes. At the very least, multiple values are incredibly common (e.g. Cookie: foo=bar;baz=qux). Clients are also supposed to include the path and domain attributes when they are specified by the server (but they often don’t).

]]> By: Ian Bicking http://blog.ianbicking.org/2007/08/18/webob/#comment-228 Ian Bicking Mon, 20 Aug 2007 02:41:20 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-228 Do clients send structured cookie information? I haven't seen this; outgoing cookies can have comments and whatnot, and I guess theoretically incoming cookies *could* have this, but they don't. If you are in a weird situation where you are getting more information in Cookie headers than what a normal browser sends, you can always parse the cookies yourself using `req.header['Cookie']` Do clients send structured cookie information? I haven’t seen this; outgoing cookies can have comments and whatnot, and I guess theoretically incoming cookies could have this, but they don’t.

If you are in a weird situation where you are getting more information in Cookie headers than what a normal browser sends, you can always parse the cookies yourself using req.header['Cookie']

]]> By: Jim http://blog.ianbicking.org/2007/08/18/webob/#comment-227 Jim Mon, 20 Aug 2007 02:37:25 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-227 I've got something very similar to this, so thank you, you've enabled me to delete code :). One thing I would like to see though, is proper decoding of incoming cookies. They aren't necessarily plain strings, they can have various properties attached to them, like expiry dates and comments. The Cookie module in the stdlib can handle this. I’ve got something very similar to this, so thank you, you’ve enabled me to delete code :).

One thing I would like to see though, is proper decoding of incoming cookies. They aren’t necessarily plain strings, they can have various properties attached to them, like expiry dates and comments. The Cookie module in the stdlib can handle this.

]]> By: Simon Willison http://blog.ianbicking.org/2007/08/18/webob/#comment-224 Simon Willison Mon, 20 Aug 2007 00:56:38 +0000 http://blog.ianbicking.org/2007/08/18/webob/#comment-224 I've been talking to both Ben Bangert and James Gardner about the possibility of making the Django and Pylons/Paste request/response objects compatible with each other in some way - either through changes to the API or just by ensuring they are similar enough that a very simple bi-directional conversion could be possible. This would make code written against Django and code written against Paste interchangeable, which would be a massive boost for Web programming on Python in general. Would you be interested in helping out with this? I should probably start a mailing list dedicated to the effort. I’ve been talking to both Ben Bangert and James Gardner about the possibility of making the Django and Pylons/Paste request/response objects compatible with each other in some way - either through changes to the API or just by ensuring they are similar enough that a very simple bi-directional conversion could be possible. This would make code written against Django and code written against Paste interchangeable, which would be a massive boost for Web programming on Python in general.

Would you be interested in helping out with this? I should probably start a mailing list dedicated to the effort.

]]>