Re: WebOb API
On Nov 16, 2:50 pm, Ben Bangert b...@groovie.org wrote: - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. the 'bad cookie' thing would be great to see happen sooner-than- later. a few years ago, wordpress created malformed cookies ( they didn't conform to the RFC and either used restricted chars , or didn't quote or something, i can't remember ). a project that i had ran wordpress for the blog/news , and mod-perl for an application. the second libapreq ( the cooking parsing apache module ) encountered a malformed cookie... segfault. its a rare thing to have, but incredibly frustrating to deal with if it ever happens. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=.
Re: WebOb API
On Wed, Nov 18, 2009 at 12:11 PM, Jonathan Vanasco jonat...@findmeon.comwrote: On Nov 16, 2:50 pm, Ben Bangert b...@groovie.org wrote: - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. the 'bad cookie' thing would be great to see happen sooner-than- later. a few years ago, wordpress created malformed cookies ( they didn't conform to the RFC and either used restricted chars , or didn't quote or something, i can't remember ). a project that i had ran wordpress for the blog/news , and mod-perl for an application. the second libapreq ( the cooking parsing apache module ) encountered a malformed cookie... segfault. its a rare thing to have, but incredibly frustrating to deal with if it ever happens. If someone wants to work on this, WebOb is in bitbucket now, so you can clone and patch and do a pull request: http://bitbucket.org/ianb/webob -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=.
Re: WebOb API
On Oct 30, 3:26 pm, Ian Bicking i...@colorstudy.com wrote: It's based on the dictionary API. get basically means: ... So it makes sense based on that. It definitely makes sense if you're familiar with the environment , and from a functional perspective. Its just very counter-intuitive for newcomers, as the various projects that use webob don't make the distinction very well / at all in their documentation. Someone from a php/perl/etc web-development background would easily assume that 'get' returns the corresponding form values, whether its a string or a list -- not simply the first item if it a list. Using something like getone implies the singular functionality, and that there is a getall equivalent. i'm assuming that's why the MultiDict and NestedMultiDict objects use that syntax Maybe the params object in MultiDict and NestedMultiDict , or the DictMixin object can have a better docstring that explains that this gets a single value, and that a getall method exists ? btw, i miss how perl handled this... since variables are decorated , one could change the value based on context via the automatically created wantarray variable in subroutines -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=.
Re: WebOb API
On Mon, Nov 16, 2009 at 1:50 PM, Ben Bangert b...@groovie.org wrote: The fixes I was aware of that Armin has worked around in Werkzeug: - Multipart parsing that doesn't suck, better file upload handling - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. I would like to include these fixes or improvements over the standard library, but they don't affect the API so it's not a 1.0 blocker. I think there was one or two other things related to having a cgi.fieldstorage that doesn't suck, and some other header parsing that Werkzeug might handle better. But these are what I'd consider critical fixes for getting into WebOb. Does Werkzeug use cgi.FieldStorage, given that it has its own parser? Getting FieldStorage objects out of req.POST (and into req.FILES with a different API) would be important, and make the transition to another parser primarily an implementation detail. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Fri, Nov 13, 2009 at 2:46 PM, Philip Jenvey pjen...@underboss.orgwrote: On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). There's at least some good arguments for immutability: o Request object becomes much simpler with way less code (see Werkzeug) The code needs to exist somewhere, so eh. And if the two were separated, the result would be more total code. o Becomes easier to cache attributes and avoid property overhead (see Werkzeug) That's not so much of an issue of immutability, as the authoritative nature of the request object or the environ. WebOb treats the environ as authoritative. It could be mutable and safely cache attributes, so long as the expectation is that no one else can change the environ using anything but the request object API. o You can still change environ you just have to do it manually o One step towards Werkzeug possibly adopting WebOb (when the aforementioned goal was being adopted by more frameworks) The drawbacks are we lose that sometimes handy functionality and that WebTest relies on it. How much does WebTest really rely on it though (it doesn't really seem like much)? WebTest primarily uses WebOb, and then adds some stuff for forms, and some APIs that are more backward compatible than essential. The mutability functionality is also useful to middleware. And just to clarify, the Werkzeug wrappers aren't totally immutable, you can still modify their attributes and add your own attributes. Its exposed data structures (like MultiDicts) are immutable and it doesn't write to environ. A middle ground might be what Werkzeug does now but allowing writes to data structures like MultiDicts -- just not propagating the changes to environ. Why not propagate changes? My philosophy with WebOb is if it does something, it should do it right. Not propagating changes is just wrong (AttributeError is more right in that case). If there are other things I'm not aware of them; you'll have to list them more specifically. Werkzeug also has some pieces of functionality separated out via Mixins, this mainly makes the code cleaner. It doesn't actually have a mutability Mixin, that's just a proposal by Armin to find a middle ground with WebOb. If the code exists, and can have a canonical form, I don't really see a reason not to include it. There is some code that is not possible to write in a canonical form. The two biggies are User-Agent parsing (which is eclectic and changes over time) and authentication methods. One big difference is it stores file uploads in a different container than the main request.POST multidict, and more importantly doesn't use cgi.FieldStorage for those file objects or for parsing the form. With that alternative form parser you can also easily limit the size of form posts/file uploads. Yes, this is something I'm interested in including in WebOb. The other API differences are probably mostly
Re: WebOb API
On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). The fixes I was aware of that Armin has worked around in Werkzeug: - Multipart parsing that doesn't suck, better file upload handling - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. I think there was one or two other things related to having a cgi.fieldstorage that doesn't suck, and some other header parsing that Werkzeug might handle better. But these are what I'd consider critical fixes for getting into WebOb. - Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). There's at least some good arguments for immutability: o Request object becomes much simpler with way less code (see Werkzeug) o Becomes easier to cache attributes and avoid property overhead (see Werkzeug) o You can still change environ you just have to do it manually o One step towards Werkzeug possibly adopting WebOb (when the aforementioned goal was being adopted by more frameworks) The drawbacks are we lose that sometimes handy functionality and that WebTest relies on it. How much does WebTest really rely on it though (it doesn't really seem like much)? And just to clarify, the Werkzeug wrappers aren't totally immutable, you can still modify their attributes and add your own attributes. Its exposed data structures (like MultiDicts) are immutable and it doesn't write to environ. A middle ground might be what Werkzeug does now but allowing writes to data structures like MultiDicts -- just not propagating the changes to environ. If there are other things I'm not aware of them; you'll have to list them more specifically. Werkzeug also has some pieces of functionality separated out via Mixins, this mainly makes the code cleaner. It doesn't actually have a mutability Mixin, that's just a proposal by Armin to find a middle ground with WebOb. One big difference is it stores file uploads in a different container than the main request.POST multidict, and more importantly doesn't use cgi.FieldStorage for those file objects or for parsing the form. With that alternative form parser you can also easily limit the size of form posts/file uploads. The other API differences are probably mostly naming of attributes, existence of more or less shortcuts, things we probably don't differ very much on. Armin also claimed WebOb doesn't handle invalid cookies as well as Werkzeug. -- Philip Jenvey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? Cheers, Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). If there are other things I'm not aware of them; you'll have to list them more specifically. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
Are there API changes that would help people consider WebOb for other frameworks? Personally, I don't like the default behavior of how request.params.get/post handles the multidict -- in that it returns ONE by default. that drove me crazy trying to figure out how posted arrays were supported, and I nearly dropped using pylons because the getall behavior was completely hidden in the documentation at that point. i'd honestly like to see get() listed for deprecation, and just have getone and getall. if python had something similar to perl's wantarray, it would be awesome -- as that's how the libapreq library handles stuff for mod_perl. but we don't, and I find the get() behaviour confusing and a huge turnoff, since in practice (i haven't looked at the source) it seems to just be an alias of getone ... and getone() implies there's a getall() , whereas get() does not imply that only handle single values --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Fri, Oct 30, 2009 at 12:32 PM, Jonathan Vanasco jonat...@findmeon.com wrote: Are there API changes that would help people consider WebOb for other frameworks? Personally, I don't like the default behavior of how request.params.get/post handles the multidict -- in that it returns ONE by default. that drove me crazy trying to figure out how posted arrays were supported, and I nearly dropped using pylons because the getall behavior was completely hidden in the documentation at that point. i'd honestly like to see get() listed for deprecation, and just have getone and getall. It's based on the dictionary API. get basically means: def get(self, key, default=None): if key in self: return self[key] else: return default So it makes sense based on that. In some other frameworks I worked with places where you would get a single value or a list depending on how many values were passed in, and I found it generally less productive, so multidict acts like a flat single-value dictionary unless you use something specific (like getall). There's no standard API I really know of for a dict-view over a list. There's an ordered dict in Python now, but it's single-value, so it has no real API over a normal dictionary. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
WebOb API
Hi all. So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. While I haven't tracked ongoing changes to frameworks, I did put together the differences I am aware of in APIs here: http://pythonpaste.org/webob/differences.html Some of them are fairly trivial, and could be managed through subclassing (e.g., req.raw_post_data vs. req.body -- semantically identical, just different names). Are there API changes that would help people consider WebOb for other frameworks? The main ones I can think of is req.FILES, separating out file uploads from other POST fields. Also then there's the issue of what kind of object represents files. The finer details of individual objects are also important, things like the API of req.GET/req.POST (which are views on ordered dictionaries, and are represented somewhat differently in different frameworks). Also I'm planning on introducing a BaseRequest (and *maybe* BaseResponse) class, that removes some functionality. Specifically for Repoze they'd like to remove __getattr__ and __setattr__ (which has some performance implications), and maybe other things are possible (though removing writers is infeasible, IMHO, as read and write access are not easily separated, and it would require too much code duplication). (Incidentally WebOb is now on bitbucket: http://bitbucket.org/ianb/webob/) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
