Re: [Python-Dev] hg verify warnings
> ... > $ hg verify > repository uses revlog format 1 > checking changesets > checking manifests > crosschecking files in changesets and manifests > checking files > warning: copy source of 'Modules/_threadmodule.c' not in parents of > 60ad83716733 > warning: copy source of 'Objects/bytesobject.c' not in parents of 64bb1d258322 > warning: copy source of 'Objects/stringobject.c' not in parents of > 357e268e7c5f > 9799 files, 79660 changesets, 176851 total revisions > 3 warnings encountered! > > > $ hg --version > Mercurial Distributed SCM (version 2.3.2) > (see http://mercurial.selenic.com for more information) FYI, I found this kind of warning in my own (non-Python) repository, created from scratch just a few weeks ago, so it's NOT necessarily the case that this has something to do with using ancient hg releases. I was teaching myself hg at the time, and suspect I did something hg didn't expect <0.5 wink>. Here's a tiny repository that displays the same kind of thing: Make a new repository (this is on Windows - does it matter? doubt it): C:\>hg init HHH C:\>cd HHH Hg is up to date (2.7): C:\HHH>hg version Mercurial Distributed SCM (version 2.7) (see http://mercurial.selenic.com for more information) ... Make a subdirectory and add a file: C:\HHH>mkdir sub C:\HHH>cd sub C:\HHH\sub>echo a > a.txt C:\HHH\sub>hg add adding a.txt C:\HHH\sub>hg ci -m initial Move the file up a level: C:\HHH\sub>hg move a.txt .. Now here's the funky part! Unsure about what was going on in my own repository, so doing as little as possible per step, I committed the move in _2_ steps (do a plain "hg ci" at this point and nothing goes wrong). So first I recorded that the subdirectory a.txt is gone: C:\HHH\sub>hg ci a.txt -m moving Then up to the parent directory, and commit the new location of a.txt: C:\HHH\sub>cd .. C:\HHH>hg st A a.txt C:\HHH>hg ci -m moving Now verify -v complains: C:\HHH>hg verify -v repository uses revlog format 1 checking changesets checking manifests crosschecking files in changesets and manifests checking files warning: copy source of 'a.txt' not in parents of 9c2205c187bf 2 files, 3 changesets, 2 total revisions 1 warnings encountered! What the warning says seems to me to be true: C:\HHH>hg log changeset: 2:9c2205c187bf tag: tip user:Tim Peters date:Mon Aug 19 12:24:43 2013 -0500 summary: moving changeset: 1:60fffa9b0194 user:Tim Peters date:Mon Aug 19 12:24:26 2013 -0500 summary: moving changeset: 0:0193842498ab user:Tim Peters date:Mon Aug 19 12:24:05 2013 -0500 summary: initial The parent of 2 (9c2205c187bf) is 1 (60fffa9b0194), and indeed the copy _source_ (HHH\sub\a.txt) was removed by changeset 1. Why that could be "bad" escapes me, though. Regardless, I suspect Python's warnings came from similarly overly elaborate learning-curve workflow, and are harmless. ___ 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: Use a known unique object for the dummy entry.
> The most reasonable thing to do would probably be to share the same > dummy object between setobject.c and dictobject.c, then. > Raymond, it would be nice if you could take a look! Thanks, I will look at it shortly. Raymond On Sun, Aug 18, 2013 at 11:46 AM, Antoine Pitrou wrote: > On Sun, 18 Aug 2013 17:31:24 +0100 > Mark Shannon wrote: > > > > By giving the dummy object a custom type, the dummy object can be > > recognised by testing that its type equals PySetDummy_Type (or > > whatever it is called) > > > > See dictobject.c for an implementation of a suitable dummy object. > > The most reasonable thing to do would probably be to share the same > dummy object between setobject.c and dictobject.c, then. > > Raymond, it would be nice if you could take a look! > > 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/raymond.hettinger%40gmail.com > ___ 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] a Constant addition to enum
On Aug 06, 2013, at 02:36 PM, Eli Bendersky wrote: >Personally, I dislike all non-simple uses of Enums. One such use is adding >behavior to them. This can always be split to separate behavior from the >Enum itself, and I would prefer that. We went to great lengths to ensure >that things work in expected ways, but heaping additional features (even as >separate decorators) is just aggravating thiings. So -1 from me. > >Finally, I suggest we exercise restraint in adding more capabilities to >enums in 3.4; enums are a new creature for Python and it will be extremely >useful to see them used in the wild for a while first. We can enhance them >in 3.5, but premature enhancement is IMHO much more likely to do harm than >good. As you can probably guess, I fully agree. I also agree with Nick's suggestion to remove the advanced examples from the documentation. -Barry ___ 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] hg verify warnings
>> ... >> $ hg verify >> repository uses revlog format 1 >> checking changesets >> checking manifests >> crosschecking files in changesets and manifests >> checking files >> warning: copy source of 'Modules/_threadmodule.c' not in parents of >> 60ad83716733 >> warning: copy source of 'Objects/bytesobject.c' not in parents of >> 64bb1d258322 >> warning: copy source of 'Objects/stringobject.c' not in parents of >> 357e268e7c5f >> 9799 files, 79660 changesets, 176851 total revisions >> 3 warnings encountered! >> >> >> $ hg --version >> Mercurial Distributed SCM (version 2.3.2) >> (see http://mercurial.selenic.com for more information) [Tim, reproduces this kind of warning in a 1-file repository, via moving the file, then committing the removal of the old location before committing the addition of the new location] > ... > Regardless, I suspect Python's warnings came from similarly overly > elaborate learning-curve workflow, Nope! At least not for _threadmodule.c: that got renamed in a single commit (7fe3a8648ce2), and I don't see anything fishy about, or around, it. I gave up on tracing back bytesobject.c/stringobject.c, because not only did one get renamed to the other, later it got renamed back again. > and are harmless. I still expect they're harmless, albeit without a shred of evidence ;-) ___ 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
[Python-Dev] HTTPOnly and Secure cookie flags
Hi, I'm currently working on a patch for ticket #16611 [1], which addresses some inconsistencies in the handling of HTTPOnly and Secure flags in the 'https.cookies' module. I originally found out about this ticket after noticing a bug in Django [2]. I could implement a work-around for Django but first I'd like to be sure how the original issue in Python should be addressed. So I'm eager to reach a resolution for this ticket. If you have any feedback on the patch or some tips on how this ticket could be moved forward, please let me know! Thanks a lot for your help! Kind regards, Julien [1] http://bugs.python.org/issue16611 [2] https://code.djangoproject.com/ticket/20755___ 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
[Python-Dev] Status of 3.2 in Hg repository?
> hg branches default85277:4f7845be9e23 2.785276:7b867a46a8b4 3.283826:b9b521efeba3 3.385274:7ab07f15d78c (inactive) 2.682288:936621d33c38 (inactive) 3.180967:087ce7bbac9f (inactive) Is it expected that 3.2 is active? Looks like it's been that way a couple months. The branch head: > hg log -r 3.2 changeset: 83826:b9b521efeba3 branch: 3.2 parent: 83739:6255b40c6a61 user:Antoine Pitrou date:Sat May 18 17:56:42 2013 +0200 summary: Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wildcards (CVE-2013-2099). Besides that one, there are only two other changesets that would be involved in a merge of 3.2 into default, both having to do with making the 3.2.5 release. As I understand the development docs (and I may be wrong), the intent is that only the default and 2.7 branches should be active at this time. Educate me :-) ___ 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
