On Fri, Nov 13, 2009 at 2:46 PM, Philip Jenvey <[email protected]>wrote:
> > > On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: > > > > > On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert <[email protected]> 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 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. > The API differences aren't too bad, from what I can tell. I expect to adopt WebOb it would usually be required to create a subclass to alias methods, providing backward compatibility. I'm not sure about the MultiDict implementations, Werkzeug doesn't document the specifics, though I imagine there are differences (WebOb and Django have different interfaces; but it's an internal API that doesn't seem to get much direct thought). -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
