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 -~----------~----~----~----~------~----~------~--~---
