Re: [Python-Dev] FileCookieJars
On Sun, 10 Mar 2013 22:46:26 -0700, Demian Brecht 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): #16004: Add `make touch`.
On Mon, Mar 11, 2013 at 9:22 AM, Brett Cannon wrote: > Should this also touch Python/importlib.h? > > nm, noticed this was added on 2.7 and not default. > > On Mon, Mar 11, 2013 at 3:14 AM, ezio.melotti > wrote: > >> http://hg.python.org/cpython/rev/da3f4774b939 >> changeset: 82600:da3f4774b939 >> branch: 2.7 >> parent: 82593:3e14aafeca04 >> user:Ezio Melotti >> date:Mon Mar 11 09:14:09 2013 +0200 >> summary: >> #16004: Add `make touch`. >> >> files: >> Makefile.pre.in | 6 +- >> Misc/NEWS | 2 ++ >> 2 files changed, 7 insertions(+), 1 deletions(-) >> >> >> diff --git a/Makefile.pre.in b/Makefile.pre.in >> --- a/Makefile.pre.in >> +++ b/Makefile.pre.in >> @@ -1250,6 +1250,10 @@ >> etags Include/*.h; \ >> for i in $(SRCDIRS); do etags -a $$i/*.[ch]; done >> >> +# Touch generated files >> +touch: >> + touch Include/Python-ast.h Python/Python-ast.c >> + >> # Sanitation targets -- clean leaves libraries, executables and tags >> # files, which clobber removes as well >> pycremoval: >> @@ -1339,7 +1343,7 @@ >> .PHONY: frameworkinstall frameworkinstallframework >> frameworkinstallstructure >> .PHONY: frameworkinstallmaclib frameworkinstallapps >> frameworkinstallunixtools >> .PHONY: frameworkaltinstallunixtools recheck autoconf clean clobber >> distclean >> -.PHONY: smelly funny patchcheck altmaninstall >> +.PHONY: smelly funny patchcheck touch altmaninstall >> .PHONY: gdbhooks >> >> # IF YOU PUT ANYTHING HERE IT WILL GO AWAY >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -874,6 +874,8 @@ >> Build >> - >> >> +- Issue #16004: Add `make touch`. >> + >> - Issue #5033: Fix building of the sqlite3 extension module when the >>SQLite library version has "beta" in it. Patch by Andreas Pelme. >> >> >> -- >> Repository URL: http://hg.python.org/cpython >> >> ___ >> Python-checkins mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-checkins >> >> > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): #16004: Add `make touch`.
Should this also touch Python/importlib.h? On Mon, Mar 11, 2013 at 3:14 AM, ezio.melotti wrote: > http://hg.python.org/cpython/rev/da3f4774b939 > changeset: 82600:da3f4774b939 > branch: 2.7 > parent: 82593:3e14aafeca04 > user:Ezio Melotti > date:Mon Mar 11 09:14:09 2013 +0200 > summary: > #16004: Add `make touch`. > > files: > Makefile.pre.in | 6 +- > Misc/NEWS | 2 ++ > 2 files changed, 7 insertions(+), 1 deletions(-) > > > diff --git a/Makefile.pre.in b/Makefile.pre.in > --- a/Makefile.pre.in > +++ b/Makefile.pre.in > @@ -1250,6 +1250,10 @@ > etags Include/*.h; \ > for i in $(SRCDIRS); do etags -a $$i/*.[ch]; done > > +# Touch generated files > +touch: > + touch Include/Python-ast.h Python/Python-ast.c > + > # Sanitation targets -- clean leaves libraries, executables and tags > # files, which clobber removes as well > pycremoval: > @@ -1339,7 +1343,7 @@ > .PHONY: frameworkinstall frameworkinstallframework > frameworkinstallstructure > .PHONY: frameworkinstallmaclib frameworkinstallapps > frameworkinstallunixtools > .PHONY: frameworkaltinstallunixtools recheck autoconf clean clobber > distclean > -.PHONY: smelly funny patchcheck altmaninstall > +.PHONY: smelly funny patchcheck touch altmaninstall > .PHONY: gdbhooks > > # IF YOU PUT ANYTHING HERE IT WILL GO AWAY > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -874,6 +874,8 @@ > Build > - > > +- Issue #16004: Add `make touch`. > + > - Issue #5033: Fix building of the sqlite3 extension module when the >SQLite library version has "beta" in it. Patch by Andreas Pelme. > > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): #16004: Add `make touch`.
On Mon, 11 Mar 2013 08:14:24 +0100 (CET) ezio.melotti wrote: > http://hg.python.org/cpython/rev/da3f4774b939 > changeset: 82600:da3f4774b939 > branch: 2.7 > parent: 82593:3e14aafeca04 > user:Ezio Melotti > date:Mon Mar 11 09:14:09 2013 +0200 > summary: > #16004: Add `make touch`. Shouldn't that be mentioned / explained / documented somewhere? It doesn't look obvious in which circumstances it could be useful. Regards Antoine. ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): #16004: Add `make touch`.
Hi, On Mon, Mar 11, 2013 at 3:28 PM, Antoine Pitrou wrote: > On Mon, 11 Mar 2013 08:14:24 +0100 (CET) > ezio.melotti wrote: >> http://hg.python.org/cpython/rev/da3f4774b939 >> changeset: 82600:da3f4774b939 >> branch: 2.7 >> parent: 82593:3e14aafeca04 >> user:Ezio Melotti >> date:Mon Mar 11 09:14:09 2013 +0200 >> summary: >> #16004: Add `make touch`. > > Shouldn't that be mentioned / explained / documented somewhere? > It doesn't look obvious in which circumstances it could be useful. > It will be documented in http://bugs.python.org/issue15964 (SyntaxError in asdl when building 2.7 with system Python 3). Best Regards, Ezio Melotti > Regards > > Antoine. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] CANNOT Patch 3.x NEWS [was cpython (2.7): Issue #14707: add news entry\
Hi, On Tue, Mar 12, 2013 at 8:14 AM, Terry Reedy wrote: > On 3/12/2013 1:50 AM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/c162e2ff15bd >> changeset: 82624:c162e2ff15bd >> branch: 2.7 >> parent: 82617:cd0191a9b5c9 >> user:Terry Jan Reedy >> date:Tue Mar 12 01:26:28 2013 -0400 >> summary: >>Issue #14707: add news entry >> >> files: >>Misc/NEWS | 3 +++ >>1 files changed, 3 insertions(+), 0 deletions(-) >> >> >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -944,6 +944,9 @@ >> Documentation >> - >> >> +- Issue #14707: remove doubled words in docs and docstrings >> + reported by Serhiy Storchaka and Matthew Barnett. >> + >> - Issue #16406: combine the pages for uploading and registering to PyPI. >> >> - Issue #16403: Document how distutils uses the maintainer field in > > > The above was easy. When I tried to transplant this patch to 3.2, export and > import, or directly edit 3.2 NEWS with Notepad++ or IDLE, hg makes a 319kb > patch that deletes and add the entire file in chunks. I did not think I > should commit and push that. > What are the exact commands you used? Are your clones up to date (i.e. did you do "hg pull" and "hg up" before "hg graft")? If not, you should pull/update. Does "hg heads ." show you more than one head? If so you should do "hg merge". Is your clone "clean" (i.e. does "hg status" show anything as 'M')? If not, you should do "hg revert -ar 3.2" or "hg up -C 3.2". Once your clone is clean you can just edit Misc/NEWS manually since it's easier than trying to graft the 2 changesets you made on 2.7 to add and edit the Misc/NEWS entry. You can also check with "hg in" and "hg out" if there's something you haven't pulled/pushed yet, but that shouldn't be a problem. > The failure of transplant and import are perhaps understandable because 3.2 > has a gratuitous case difference with /combine/Combine/. > > - Issue #16406: Combine the pages for uploading and registering to PyPI. > > But the inability to make a proper diff from direct edit is something else. > If I add just a single blank line, even that generates a mega patch. Same > with 3.3 NEWS. I also tried deleting the file to make hg regenerate from the > repository database. > > Anyone have any idea what the problem is? Has anything changed with hg, > windows, line endings and this text file in the last few months? I just > pushed patches for about 20 scattered files in Docs, Lib, Modules, and Tools > earlier today, so the problem seems to be specific to NEWS. > Not sure about this, but in the meanwhile you could try what I suggested above -- if that doesn't work we can find some other solution. (If you prefer you can come on #python-dev too.) Best Regards, Ezio Melotti > tjr > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
