Re: [Python-Dev] FileCookieJars
On Sun, 10 Mar 2013 22:46:26 -0700, Demian Brecht demianbre...@gmail.com wrote: On 2013-03-10 1:59 PM, R. David Murray wrote: I was hoping that there would be a little more interest (and potentially some further historical context on why the module was implemented as it was) from those in the group. It isn't clear who wrote the original code. It looks like Martin von Löwis checked it in, so he may be the author (or not). It is pretty old code, checked in May 31 18:22:40 2004, according to the repo history. If, that is, you are interested enough to continue to be the point person for this, which probably won't be a short process:) I'm not sure who this was directed to (me or Steven), but I was looking for an area in the stdlib that I could really sink my teeth into and get my hands dirty with and this definitely seems to be just that. I figured that it wouldn't be a short process and the more that I read up on RFC 6265 (and 2965) and compare them to the implementation in cookie and cookiejar, the more I'm thinking that this will be a relatively complex and lengthy process. (Definitely interested in that btw :)). It was directed to you. We love having people pick up maintenance of modules that don't currently have someone specifically interested in them, so it is great that you are interested. If you produce code and proposals and keep asking, people *will* respond, though some patience and persistence may be required. The problem here is getting people interested, apparently:( Since I start my Pycon diversion-from-work next week, maybe I can find some time to take at least a preliminary look. In case you haven't already seen it, I had posted a second patch (that doesn't break the Liskov substitution principle as Terry pointed out after reviewing my overzealous initial patch) here: http://bugs.python.org/issue16901. I think the design is much more sane than what's currently there and aligns with how HTTP cookies are processed in urllib.request. I haven't looked it over yet, but I put it on my todo list. Now having said all that, the more I think about it and the more I read, the more I wonder why there are even specialized implementations (LWP and Mozilla) in the stdlib to begin with. I would assume that the only thing that the stdlib /should/ be covering is the RFC (6265, but still allowing 2965). Because reality. Take a look at http://bugs.python.org/issue2193 (for example), and see if you still want to tackle this topic :) (I hope you do). If there are deviations (and some are eluded to throughout the code), then I would think that those should be handled by packages external to the stdlib. It seems that the Mozilla implementation covers 2965, but LWP is based on the Perl library (which isn't known to be supported by any browser environment). Why is this even there to begin with? To paraphrase the comments that I read in the code: This isn't supported by any browser, but they're easy to parse. In my mind, this shouldn't be reason enough for inclusion in the stdlib. Well, at the time it probably was. And given that it is there, *someone* is probably depending on it. But, we can probably pay less attention to that variant, and perhaps not carry it forward if we do decide to go through a deprecation of some sort (*). The other reality is that our cookie support won't be very useful if it adheres strictly to the RFCs, since the servers and browsers don't. What we need is something practical...which may differ to a greater or lesser degree from what we currently have. I'd also go as far to say that if cookies are implemented as consistently as, say, OAuth 2.0 providers (meaning very little to no consistency), then there really shouldn't be a cookie implementation in the stdlib anyway. But there is, and in fact it *is* useful and used by many people, so IMO it is worth maintaining. So to sum it up, yes I'm very much interested in doing what I can to help the development of the stdlib (more so interested in parts that don't currently have experts listed, such as http and imaplib), but will definitely need to be shown the ropes a bit as my professional life has revolved around closed source games. Excellent. If you aren't already on the core-mentorship mailing list, you might want to sign up. Your approach (adopting modules without current maintainers) is a good one. --David (*) Our deprecation for stuff like this tends to be that we pretty much stop maintaining it, document it as deprecated, but don't delete it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On 2013-03-11 5:44 AM, R. David Murray wrote: though some patience and persistence may be required. I have a wife and kids. This, I've become quite good at ;) Take a look at http://bugs.python.org/issue2193 (for example), and see if you still want to tackle this topic :) (I hope you do). Egad. I knew that cookies were quite the can of worms prior to digging into this as much as I have, but I didn't realize that the RFC had been written /after/ cookie implementations had already surfaced in the wild (I guess I shouldn't have actually been surprised either). Just makes this more challenging and therefore interesting to work on imo :) The other reality is that our cookie support won't be very useful if it adheres strictly to the RFCs, since the servers and browsers don't. What we need is something practical...which may differ to a greater or lesser degree from what we currently have. Yes, I wasn't sure of the general standpoint of Python stdlibs in terms of practicality versus strict adherence. While adhering to Postel's law in cases such as cookies can definitely make an implementation much more tricky, it increases its practical usage (I didn't realize just how deviant servers and browsers were for this particular topic until after reading through issue 2193). But there is, and in fact it *is* useful and used by many people, so IMO it is worth maintaining. I see your point here and agree. It's much different when changes can be dictated in closed source packages (what I'm most accustomed to) than dealing with an open source project at the scale of Python and the stdlib. Excellent. If you aren't already on the core-mentorship mailing list, you might want to sign up. Your approach (adopting modules without current maintainers) is a good one. Thanks, I wasn't aware of the core-mentorship list. I'll be signing up shortly. Good to know my approach is sane :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On Sat, 09 Mar 2013 12:13:54 +1100, Steven D'Aprano st...@pearwood.info wrote: On 02/03/13 02:43, Demian Brecht wrote: Cross-posting from python-ideas due to no response there. Perhaps it's due to a general lack of usage/caring for cookiejar, but figured /someone/'s got to have an opinion about my proposal ;) Apparently not :-( TL;DR: CookieJar FileCookieJar *CookieJar are architecturally broken and this is an attempt to rectify that (and fix a couple bugs along the way). [...] This will obviously break backwards compatibility, so I'm not entirely sure what best practice is around that: leave well enough alone even though it might not make sense, keep the old implementations around and deprecate them to be eventually replaced by the processors, or other ideas? I don't have an opinion on cookiejars per se, but I think that the first thing to do is get an idea of just how major a backward-compatibility breakage this would be. If you change the cookiejar architecture, then run the Python test suite, what happens? The number of failures will give you an idea of how bad it will be. If there are no failures, you could consider just making the change. You probably should make an attempt to find out what third party apps use the cookiejars and see what they do. To be clear, just passing the stdlib tests is *not* sufficient to think that backward compatibility is not likely to be broken. Deciding about the likelihood of breakage is a hard problem, to which we generally employ gut-level heuristics :) (And code search, as Steven suggests). Since you say that it will obviously break backward compatibility, I'd say that if we are going to do anything we'd have to think about how best to introduce a more sane implementation and deprecate the old...and if we are going to do that, we probably ought to spend a bit of time seeing if there are any other open cookiejar issues we can tackle at the same time. If, that is, you are interested enough to continue to be the point person for this, which probably won't be a short process :) The problem here is getting people interested, apparently :( Since I start my Pycon diversion-from-work next week, maybe I can find some time to take at least a preliminary look. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On 3/10/2013 4:59 PM, R. David Murray wrote: To be clear, just passing the stdlib tests is *not* sufficient to think that backward compatibility is not likely to be broken. Deciding about the likelihood of breakage is a hard problem, to which we generally employ gut-level heuristics :) (And code search, as Steven suggests). Since you say that it will obviously break backward compatibility, I'd say that if we are going to do anything we'd have to think about how best to introduce a more sane implementation and deprecate the old...and if we are going to do that, we probably ought to spend a bit of time seeing if there are any other open cookiejar issues we can tackle at the same time. A) For similar reasons, I consider the proposal a first draft, and probably not the exact right thing to do. B) I have had similar thoughts about taking a broader look. Searching open issues for cookie gets 24 hits and I think at least half are about cookie.py or cookiejar.py. If, that is, you are interested enough to continue to be the point person for this, which probably won't be a short process :) The problem here is getting people interested, apparently :( The number of relatively recent problem reports indicates that people are using the two modules, so fixing them is worthwhile in that sense. On the other no, it does not seem that any *current* developers are working with cookies. Messages on http://bugs.python.org/issue17340 suggest that cookie.py should be based on http://tools.ietf.org/html/rfc6265 I added you as nosy to get your opinion. Since I start my Pycon diversion-from-work next week, maybe I can find some time to take at least a preliminary look. I am willing to learn and help, but my only experience with them is as a browser user defending against the onslaught of cookies. (I once sped up IExplorer by deleting a massive cookie cache.) -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On 2013-03-10 1:59 PM, R. David Murray wrote: To be clear, just passing the stdlib tests is*not* sufficient to think that backward compatibility is not likely to be broken. Deciding about the likelihood of breakage is a hard problem, to which we generally employ gut-level heuristics:) (And code search, as Steven suggests). I figured that this would be a hard problem, which is also why I didn't delve into a patch further than a proposed first stab at a more sane implementation, coupled with changes to the unit tests. Since you say that it will obviously break backward compatibility, I'd say that if we are going to do anything we'd have to think about how best to introduce a more sane implementation and deprecate the old...and if we are going to do that, we probably ought to spend a bit of time seeing if there are any other open cookiejar issues we can tackle at the same time. I was hoping that there would be a little more interest (and potentially some further historical context on why the module was implemented as it was) from those in the group. If, that is, you are interested enough to continue to be the point person for this, which probably won't be a short process:) I'm not sure who this was directed to (me or Steven), but I was looking for an area in the stdlib that I could really sink my teeth into and get my hands dirty with and this definitely seems to be just that. I figured that it wouldn't be a short process and the more that I read up on RFC 6265 (and 2965) and compare them to the implementation in cookie and cookiejar, the more I'm thinking that this will be a relatively complex and lengthy process. (Definitely interested in that btw :)). The problem here is getting people interested, apparently:( Since I start my Pycon diversion-from-work next week, maybe I can find some time to take at least a preliminary look. In case you haven't already seen it, I had posted a second patch (that doesn't break the Liskov substitution principle as Terry pointed out after reviewing my overzealous initial patch) here: http://bugs.python.org/issue16901. I think the design is much more sane than what's currently there and aligns with how HTTP cookies are processed in urllib.request. Now having said all that, the more I think about it and the more I read, the more I wonder why there are even specialized implementations (LWP and Mozilla) in the stdlib to begin with. I would assume that the only thing that the stdlib /should/ be covering is the RFC (6265, but still allowing 2965). If there are deviations (and some are eluded to throughout the code), then I would think that those should be handled by packages external to the stdlib. It seems that the Mozilla implementation covers 2965, but LWP is based on the Perl library (which isn't known to be supported by any browser environment). Why is this even there to begin with? To paraphrase the comments that I read in the code: This isn't supported by any browser, but they're easy to parse. In my mind, this shouldn't be reason enough for inclusion in the stdlib. I'd also go as far to say that if cookies are implemented as consistently as, say, OAuth 2.0 providers (meaning very little to no consistency), then there really shouldn't be a cookie implementation in the stdlib anyway. So to sum it up, yes I'm very much interested in doing what I can to help the development of the stdlib (more so interested in parts that don't currently have experts listed, such as http and imaplib), but will definitely need to be shown the ropes a bit as my professional life has revolved around closed source games. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On 2013-03-10 2:36 PM, Terry Reedy wrote: A) For similar reasons, I consider the proposal a first draft, and probably not the exact right thing to do. That is correct. The more I think about it, the more I'm convincing myself that even though the proposal is more sane than what's there right now, it's definitely not the exact correct thing to do. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FileCookieJars
On 02/03/13 02:43, Demian Brecht wrote: Cross-posting from python-ideas due to no response there. Perhaps it's due to a general lack of usage/caring for cookiejar, but figured /someone/'s got to have an opinion about my proposal ;) Apparently not :-( TL;DR: CookieJar FileCookieJar *CookieJar are architecturally broken and this is an attempt to rectify that (and fix a couple bugs along the way). [...] This will obviously break backwards compatibility, so I'm not entirely sure what best practice is around that: leave well enough alone even though it might not make sense, keep the old implementations around and deprecate them to be eventually replaced by the processors, or other ideas? I don't have an opinion on cookiejars per se, but I think that the first thing to do is get an idea of just how major a backward-compatibility breakage this would be. If you change the cookiejar architecture, then run the Python test suite, what happens? The number of failures will give you an idea of how bad it will be. If there are no failures, you could consider just making the change. You probably should make an attempt to find out what third party apps use the cookiejars and see what they do. If there are failures, then you need to add a second cookiejar implementation, and deprecate the old one. Oh, and please don't call the new cookier jar anything like NewCookieJar. Because in a few years, it won't be. Actually, I lied, I do have an opinion on cookiejars. I agree with Terry that it is a bit weird to have an ABC inherit from a concrete class. Not just weird, but a violation of the Liskov Substitution Principle that an instance of a subclass should be usable anywhere an instance of the parent class is. If you can't even instantiate the subclass, that's a pretty major violation for no apparent benefit :-) -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
