Re: [Python-Dev] Hg question
On Wed, Apr 13, 2011 at 4:35 AM, Alexander Belopolsky wrote: > I was preparing a commit to 3.2 and default branches and mistakenly > used -m insread of -l commit option. As a result, I have If you had caught the change before merging to default, then "hg rollback" would have done the trick, but since there are *two* commits you want to alter, then it seems like one of the hg strip approaches others have suggested will be necessary. Agreed on the usability annoyances arising from mixing the desire for a relative clean history in the main repository and hg's near total intolerance for mistakes, though :P Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] peps: Update PEP 399 to include comments from python-dev.
Georg Brandl, 13.04.2011 08:54: On 13.04.2011 02:07, Antoine Pitrou wrote: On Tue, 12 Apr 2011 19:50:34 -0400 Tres Seaver wrote: Trying to accelerate existing code which doesn't have the coverage is insane: how can you know that the accelerator doesn't subtly change the semantics without tests? Well, why do you think tests guarantee that the semantics are the same? Tests are not a magic bullet. "Covering" a code path doesn't ensure that every possible behaviour is accounted for. def foo(a, b): if condition(a): bar = b do_something_with(bar) This has 100% coverage if "condition" is usually true :) I understand that you are joking. However, the PEP mentions *branch* coverage as the 100% goal, which would imply that the above issue gets caught. Stefan ___ 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] Bug? Can't rebind local variables after calling pdb.set_trace()
On Tue, Apr 12, 2011 at 1:22 PM, Guido van Rossum wrote: > > Looking at the pastebin you are using !lv = 2. Why the !? Without it, > it works fine: > > I just wanted to make sure I was executing a python statement and not a pdb alias. I re-tested without the exclamation mark and still have the same issue: -> import pdb; pdb.set_trace() (Pdb) list 1 gv = 1 2 3 def f(): 4 lv = 1 5 -> import pdb; pdb.set_trace() 6 7 if __name__ == '__main__': 8 f() [EOF] (Pdb) lv 1 (Pdb) lv = 2 (Pdb) lv 1 (Pdb) -- Djoume Salvetti Director of Development T:416.601.1999 x 249 www.trapeze.com twitter: trapeze 175 Bloor St. E., South Tower, Suite 900 Toronto, ON M4W 3R8 ___ 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 (3.1): Fix Issue11703 - urllib2.geturl() does not return correct url when the original
On Wed, Apr 13, 2011 at 01:43:39AM +0200, Antoine Pitrou wrote: > Can you add a Misc/NEWS entry? Added. Thanks for noticing this. -- Senthil ___ 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] peps: Update PEP 399 to include comments from python-dev.
On Wed, 13 Apr 2011 06:28:58 +0200 Stefan Behnel wrote: > > However, I think we are really discussing a theoretical issue here. All the > PEP is trying to achieve is to raise the bar for C code in the stdlib, for > exactly the reason that it can easily introduce subtle semantic differences > in comparison to generic Python code. True. But then we're much better without a formal requirement that some people will start trying to require because they don't understand that its metric is pointless. > I think it would help to point out in the PEP that code that fails to touch > the theoretical 100% test coverage bar is not automatically excluded from > integration, but needs solid reasoning, review and testing in the wild in > order to be considered an equivalent alternative implementation. > But then > again, this should actually be required anyway, even for code with an > exceedingly high test coverage. I'm not sure what kind of "testing in the wild" you refer to. If you mean that it should have e.g. been published on the Cheeseshop, I don't think that's an useful requirement for an accelerator module. 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] Mentor for Py3 benchmarking
Hi Arc, I think you should forward this to python-dev. (CCed) There was a discussion on this over there, so someone should be definitely interested. On Tue, Apr 12, 2011 at 11:33:55AM -0400, Arc Riley wrote: > We have a number of students who proposed to port PyPy's benchmarking suite to > Python3 to run on speed.python.org, we don't have a mentor for these at the > moment. > > Would anyone here (pref previous GSoC mentor/student) like to take one of > these > on? > > We have until Monday (4/18) to evaluate students, get patches/blogs/etc taken > care of, and all mentors assigned. If there are people here who want to > mentor > talk to either Tarek (for packaging) or Martin v. Löwis (for python-core). If > you're an existing python-dev contributor we could especially use your help. -- Senthil ___ 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] peps: Update PEP 399 to include comments from python-dev.
On 4/13/2011 7:52 AM, Antoine Pitrou wrote: On Wed, 13 Apr 2011 06:28:58 +0200 Stefan Behnel wrote: I think it would help to point out in the PEP that code that fails to touch the theoretical 100% test coverage bar is not automatically excluded from integration, but needs solid reasoning, review and testing in the wild in order to be considered an equivalent alternative implementation. But then again, this should actually be required anyway, even for code with an exceedingly high test coverage. I'm not sure what kind of "testing in the wild" you refer to. If you mean that it should have e.g. been published on the Cheeseshop, I don't think that's an useful requirement for an accelerator module. The real testing in the wild will come after the accelerator is released. Is there any easy way for users to avoid the accelerator, to see if it is the source of a problem, short of editing the import in the .py file? Test/support appears to jump through some hoops to do so. -- Terry Jan Reedy ___ 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] peps: Update PEP 399 to include comments from python-dev.
On Apr 13, 2011, at 4:52 AM, Antoine Pitrou wrote: > On Wed, 13 Apr 2011 06:28:58 +0200 > Stefan Behnel wrote: >> >> However, I think we are really discussing a theoretical issue here. All the >> PEP is trying to achieve is to raise the bar for C code in the stdlib, for >> exactly the reason that it can easily introduce subtle semantic differences >> in comparison to generic Python code. > > True. But then we're much better without a formal requirement that > some people will start trying to require because they don't understand > that its metric is pointless. I concur. For most part, anyone converting from C-to-Python or Python-to-C is already doing their best to make the two as similar as they can. The PEP falls short because its coverage metric conflates the published API with its implementation details. The PEP seems confused about the role of white box testing versus black box testing. Nor does the PEP provide useful guidance to anyone working on a non-trivial conversion such as decimal, OrderedDict, or threading. If the underlying theme is "nothing written in C is good for PyPy", perhaps the PEP should address whether we want any new C modules at all. That would be better than setting a formal requirement that doesn't address any of the realities of building two versions of a module and keeping them in sync. Raymond ___ 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] peps: Update PEP 399 to include comments from python-dev.
Antoine Pitrou, 13.04.2011 02:07: > On Tue, 12 Apr 2011 19:50:34 -0400 > Tres Seaver wrote: >> Trying to accelerate existing code which doesn't have the coverage is >> insane: how can you know that the accelerator doesn't subtly change the >> semantics without tests? > > Well, why do you think tests guarantee that the semantics are the same? > Tests are not a magic bullet. "Covering" a code path doesn't ensure > that every possible behaviour is accounted for. When I suggested we add 100% branch coverage as a recommendation or requirement to the PEP, I pointed out that it was a place to *start*. Nobody is saying it guarantees the semantics are the same, that was the whole point of replacing the statement about semantics with the statement about test coverage. When we find places where the two versions don't match, we will have to (a) decide the compatibility issue[*] and (b) add tests that enshrine the decision. As Tres said, if I were *writing* an accelerator, I'd want to start with 100% branch coverage just to have as good as practical a check on my implementation as I could. I'd also try to think of additional tests. I'm doing this in email (increasing test coverage to 100% before rewriting algorithms) even though I'm not doing C accelerators. It just seems like the sensible thing to do. (You may think I'm really crazy, since some of the tests needed to get to 100% branch coverage will be testing lines of code that I'm removingbut those tests represent particular edges cases and I want to know that those edge cases continue to pass after I change the code.) [*] Maybe the PEP needs to talk about the basis on which those decisions will be made: maintaining compatibility across Python implementations. In other words, a CPython C accelerator can be viewed as *breaking compatibility with standard Python* if it doesn't implement the documented interface of the Python version of the module. (My apologies if this is in fact already discussed, I didn't reread the PEP to check.) The idea is to use the test suite as the check for this, adding tests as necessary. -- R. David Murray http://www.bitdance.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] Pass possibly imcompatible options to distutil's ccompiler
On Wed, 13 Apr 2011 12:25:59 +0900, David Cournapeau wrote: > On Tue, Apr 12, 2011 at 8:32 AM, Nick Coghlan wrote: > > On Tue, Apr 12, 2011 at 7:41 AM, Lukas Lueg > > wrote: > >> Any other ideas on how to solve this in a better way? > > > > Have you tried with distutils2? If it can't help you, it should really > > be looked into before the packaging API is locked for 3.3. > > distutil2 is almost identical to distutils as far as compilation goes, > so I am not sure why it would help the OP. As I read it, Nick's thought wasn't that distutils2 would help the OP, but that the OP could help Distutils2 and the community by taking his use case to the developers and making sure that that use case is supported before the release of packaging in 3.3. -- R. David Murray http://www.bitdance.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] cpython: Fix 64-bit safety issue in BZ2Compressor and BZ2Decompressor.
On 12.04.2011 23:05, nadeem.vawda wrote: > http://hg.python.org/cpython/rev/0010cc5f22d4 > changeset: 69275:0010cc5f22d4 > user:Nadeem Vawda > date:Tue Apr 12 23:02:42 2011 +0200 > summary: > Fix 64-bit safety issue in BZ2Compressor and BZ2Decompressor. > > files: > Lib/test/test_bz2.py | 36 +++- > Modules/_bz2module.c | 33 + > 2 files changed, 59 insertions(+), 10 deletions(-) > > > diff --git a/Lib/test/test_bz2.py b/Lib/test/test_bz2.py > --- a/Lib/test/test_bz2.py > +++ b/Lib/test/test_bz2.py Hi, for reviewing and "hg log" purposes it would be good to include a bit more information in the commit message, like where the safety issue was and what its potential implications were. (Of course that is different if there is an issue on the tracker to refer to; usually the issue is explained clearly in the issue.) Georg ___ 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 (merge default -> default): merge from push conflict.
On 13.04.2011 03:43, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/a4d1a3e0f7bd > changeset: 69306:a4d1a3e0f7bd > parent: 69305:35b16d49c0b1 > parent: 69299:c8d075051e88 > user:Senthil Kumaran > date:Wed Apr 13 09:38:51 2011 +0800 > summary: > merge from push conflict. Hi, this message is not quite correct -- there is no conflict involved. You're just merging two heads on the same branch in order to have only one head in the master repo. Georg ___ 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: Fix 64-bit safety issue in BZ2Compressor and BZ2Decompressor.
Thanks for the feedback. I'll be sure to include more information in my future commit messages. Nadeem ___ 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] Test cases not garbage collected after run
On 07/04/2011, Michael Foord wrote: > On 07/04/2011 20:18, Robert Collins wrote: >> >> Testtools did something to address this problem, but I forget what it >> was offhand. Some issues were worked around, but I don't remember any comprehensive solution. > The proposed "fix" is to make test suite runs destructive, either > replacing TestCase instances with None or pop'ing tests after they are > run (the latter being what twisted Trial does). run-in-a-loop helpers > could still repeatedly iterate over suites, just not call the suite. Just pop-ing is unlikely to be sufficient in practice. The Bazaar test suite (which uses testtools nowadays) has code that pops during the run, but still keeps every case alive for the duration. That trebles the runtime on my memory-constrained box unless I add a hack that clears the __dict__ of every testcase after it's run. Martin ___ 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 (merge default -> default): merge from push conflict.
On Wed, Apr 13, 2011 at 08:24:32PM +0200, Georg Brandl wrote: > > summary: > > merge from push conflict. > > this message is not quite correct -- there is no conflict involved. > You're just merging two heads on the same branch in order to have > only one head in the master repo. Okay, got it. I should have just said merge. (I probably typed push conflict, because push was not allowed as some had already pushed to repo in quick succession), it is just a merge. Thanks, Senthil ___ 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] Pass possibly imcompatible options to distutil's ccompiler
On Thu, Apr 14, 2011 at 3:04 AM, R. David Murray wrote: > As I read it, Nick's thought wasn't that distutils2 would help the OP, > but that the OP could help Distutils2 and the community by taking his > use case to the developers and making sure that that use case is > supported before the release of packaging in 3.3. A little of both, actually. (I don't know either distutils or distutils2 well enough to know precisely what the latter handles better, I just know that it is designed to be easier to extend without being as fragile as custom commands in distutils) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
