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
