Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 22 December 2010 01:37, Guido van Rossum gu...@python.org wrote: Furthermore, Java's jUnit puts expected first (and makes this part of the culture/religion), so people coming from there will use that order and be freaked out if you were to swap them. And last, the order of diff arguments (old new) is also ingrained in the culture (which actually matches the expected/actual order in my mind). For what it's worth, none of the (numerous) Java projects that I've worked on over the last couple of years have used bare JUnit. Assertions are often done using the Hamcrest library - http://code.google.com/p/hamcrest/. The actual value comes first, and this combined with the use of matchers makes the failure messages very descriptive. I'd hate to go back to one of those projects where the tests tell you that two values don't match, but doesn’t tell me which is the expected value. There is a Python port - http://code.google.com/p/hamcrest/wiki/TutorialPython. I must get around to trying that. -- Cheers, Simon B. ___ 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] [Python-checkins] r87270 - python/branches/py3k/Doc/library/urllib.request.rst
On Wed, Dec 15, 2010 at 08:07:26PM +0100, antoine.pitrou wrote: Log: Move the urllib-inherited API to a distinguished section Distinguished: Legacy. :) -- Senthil ___ 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] Fault handler updated, now disabled by default
Le jeudi 23 décembre 2010 à 03:37 +0100, Martin v. Löwis a écrit : So, do you agree with the fault handler? Does someone want to give a last review because I commit it? It's a new feature, so regardless of whether it's correct or not (which I haven't reviewed yet), I don't think it should go in before 3.2 is released. I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it works correctly: all tests pass and the system fault handler (Windows popup, Apport and core dump) is also called. The fault handler is disabled by default and it is clearly separated (eg. it doesn't touch the API of a module). Can't you make an exception for this new feature? The first answer to my previous email thread was Georg, answer starting with I very much like having a traceback on (some) segmentation faults :-) Victor ___ 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] Fault handler updated, now disabled by default
The fault handler is disabled by default and it is clearly separated (eg. it doesn't touch the API of a module). Can't you make an exception for this new feature? Ultimately, it's for the release manager to decide, so I don't need to make an exception. However, I think that special cases aren't special enough to break the rules. I still wish that the beta releases had been deferred until after the Mercurial switchover, but alas, the release manager has decided otherwise - explicitly pointing out that the rationale for releasing beta 1 was to stop accepting new features. The motivation for freezing features before feature releases is not so much that existing applications may be affected by API changes (3.2 will change APIs, anyway, and users fully expect to need some porting), but that the features that are about to be released need some time for testing. This specific feature has seen very little testing. Giving it a full release cycle (i.e. until 3.3) would somewhat reduce the need for a more careful code review. Regards, Martin ___ 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] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable
On Wed, Dec 22, 2010 at 9:26 PM, Victor Stinner vstin...@edenwall.com wrote: If the kernel doesn't do that for us, I suppose that the compiler or something else does it for us. GCC does this for you if you declare your function with __attribute__(signal). In general, the compiler doesn't know that a function will be used as a signal and no portable way to indicate this. Anyway, it would just be horrible if a signal handler was responsible to save/restore integer registers. Horrible or not, the existence of __attribute__(signal) seems to indicate that this is the case on some platform, or at least was historically. I don't know whether it's the case now on any platform that Python supports. ___ 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] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable
Horrible or not, the existence of __attribute__(signal) seems to indicate that this is the case on some platform, or at least was historically. The signal attribute has an effect only on ATMEL AVR processors, according to the documentation (and according to my source grep). On other processors, gcc typically implements __attribute__((interrupt)), meaning that the function is an interrupt handler - something that you cannot express in regular C. This may involve re-enabling interrupts on entry, but may also involve other code generation aspects (such as using iret instead of ret on x86). For AVR, there was apparently some compatibility issue, introducing the need for two different ways to declare an ISR: __attribute__((interrupt)) causes interrupts to be re-enabled on entry (using the sei instruction); __attribute__((signal)) keeps them disabled. So this has nothing to do with Unix signals. Regards, Martin ___ 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] r87445 - python/branches/py3k/Lib/numbers.py
On Thu, 23 Dec 2010 19:41:33 +0100 (CET) eric.araujo python-check...@python.org wrote: def __index__(self): -index(self) +someobject[self] This is misleading as to what the method actually does, as you can read in the implementation: return int(self) ___ 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] nonlocal x = value
Am 22.12.2010 23:11, schrieb Laurens Van Houtven: On Sat, Dec 18, 2010 at 1:12 PM, Georg Brandl g.bra...@gmx.net wrote: Am 17.12.2010 17:52, schrieb Laurens Van Houtven: +1 for throwing it out of the PEP. Assignment is a thing, nonlocal/global is a thing, don't mix them up :) (That in addition to the grammar cleanliness argument Stephan already made) The trouble is what to make of nonlocal x = 3, y Is it two nonlocal declarations or one with a tuple assignment? Georg I'm not sure I understand. Isn't that another reason to throw it out? If you don't allow such assignments, there can't be any ambiguity, right? (Or am I missing something?) Yes and no -- there may not be an ambiguity to the parser, but still to the human. Except if you disallow the syntax in any case, requiring people to write nonlocal x = (3, y) which is then again inconsistent with ordinary assignment statements. Georg ___ 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] Fault handler updated, now disabled by default
Am 23.12.2010 19:23, schrieb Martin v. Löwis: The fault handler is disabled by default and it is clearly separated (eg. it doesn't touch the API of a module). Can't you make an exception for this new feature? Ultimately, it's for the release manager to decide, so I don't need to make an exception. However, I think that special cases aren't special enough to break the rules. I still wish that the beta releases had been deferred until after the Mercurial switchover, but alas, the release manager has decided otherwise - explicitly pointing out that the rationale for releasing beta 1 was to stop accepting new features. The main rationale was that the Mercurial switchover is not a fixed target and depends very much on volunteer effort, so in effect this would have been akin to deferring 3.2 for an indefinite period. The motivation for freezing features before feature releases is not so much that existing applications may be affected by API changes (3.2 will change APIs, anyway, and users fully expect to need some porting), but that the features that are about to be released need some time for testing. This specific feature has seen very little testing. Giving it a full release cycle (i.e. until 3.3) would somewhat reduce the need for a more careful code review. Exactly. I did say I like the feature, but that was a) before beta 2 was released, now the next release is a release candidate, and b) this thread showed that it is not at all obvious how the feature should look like. The fact that it isn't enabled by default also makes it seem less attractive to me, but I understand the reasons why it shouldn't be on by default. Therefore, I'm not willing to make an exception here. Georg ___ 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] nonlocal x = value
On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandl g.bra...@gmx.net wrote: Yes and no -- there may not be an ambiguity to the parser, but still to the human. Except if you disallow the syntax in any case, requiring people to write nonlocal x = (3, y) which is then again inconsistent with ordinary assignment statements. Georg Right -- but (and hence the confusion) I was arguing for not mixing global/nonlocal with assignment at all, and instead having nonlocal and global only take one or more names. That would (obviously) remove any such ambiguity ;-) cheers lvh ___ 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] r87445 - python/branches/py3k/Lib/numbers.py
Le 23/12/2010 20:55, Antoine Pitrou a écrit : def __index__(self): -index(self) +someobject[self] This is misleading as to what the method actually does, Really? Unless I misunderstood the docs, __index__ is used when the object is used as an index (or with bin or oct, but I didn’t want to complicate the docstring, just fix it). On IRC, R. David Murray said that I could just have deleted the docstring. I agree with that: I think magic methods never need a docstring, since they’re documented once and for all in the language reference. (__init__ is not an exception: its parameters can be documented in the class docstring.) as you can read in the implementation: return int(self) The fact that __index__ is implemented thanks to int/__int__ here is a detail IMO. Regards ___ 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] nonlocal x = value
Am 23.12.2010 22:03, schrieb Laurens Van Houtven: On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandl g.bra...@gmx.net wrote: Yes and no -- there may not be an ambiguity to the parser, but still to the human. Except if you disallow the syntax in any case, requiring people to write nonlocal x = (3, y) which is then again inconsistent with ordinary assignment statements. Georg Right -- but (and hence the confusion) I was arguing for not mixing global/nonlocal with assignment at all, and instead having nonlocal and global only take one or more names. That would (obviously) remove any such ambiguity ;-) Oh yes, I see -- not sure why I worded it like I did. I just wanted to reiterate the most obvious problematic point to people who hadn't followed the earlier discussions about it. Sorry. Georg ___ 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] r87445 - python/branches/py3k/Lib/numbers.py
On Thu, 23 Dec 2010 22:09:15 +0100 Éric Araujo mer...@netwok.org wrote: Le 23/12/2010 20:55, Antoine Pitrou a écrit : def __index__(self): -index(self) +someobject[self] This is misleading as to what the method actually does, Really? Unless I misunderstood the docs, __index__ is used when the object is used as an index (or with bin or oct, but I didn’t want to complicate the docstring, just fix it). Well, it's only used for converting to an integer (also, it's used in more cases than just indexing), so someobject[self] is not the actual operation. Regards Antoine. ___ 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] r87445 - python/branches/py3k/Lib/numbers.py
Am 23.12.2010 22:09, schrieb Éric Araujo: Le 23/12/2010 20:55, Antoine Pitrou a écrit : def __index__(self): -index(self) +someobject[self] This is misleading as to what the method actually does, Really? Unless I misunderstood the docs, __index__ is used when the object is used as an index (or with bin or oct, but I didn’t want to complicate the docstring, just fix it). In case Antoine's objection isn't clear yet: __index__ does *not* perform the actual indexing, as opposed to what the docstring suggests. Regards, Martin ___ 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] Fault handler updated, now disabled by default
On 23/12/2010, Victor Stinner victor.stin...@haypocalc.com wrote: I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it works correctly: all tests pass and the system fault handler (Windows popup, Apport and core dump) is also called. Doesn't build for me without #ifdef HAVE_UNISTD_H in Python/fault.c and you missed my comment about raise vs. kill in the other thread which lets the SIGILL test run as well. With those changes, I get: test_disabled (test.test_fault.FaultHandlerTests) ... ok test_fatal_error (test.test_fault.FaultHandlerTests) ... FAIL test_gil_released (test.test_fault.FaultHandlerTests) ... ok test_sigbus (test.test_fault.FaultHandlerTests) ... skipped 'need _testcapi.sigbus()' test_sigfpe (test.test_fault.FaultHandlerTests) ... skipped 'SIGFPE cannot be caught on Windows' test_sigill (test.test_fault.FaultHandlerTests) ... ok test_sigsegv (test.test_fault.FaultHandlerTests) ... ok test_xoption (test.test_fault.FaultHandlerTests) ... ok So, this does basically work as there is a SIGSEGV compatibility hack in VS8 and later (I'd neglected to compare the language across the different MSDN pages). The failure is due to the test not expecting an extra note the assert gives at the end. See attached interdiff for suggested changes. Martin issue8863_incr.diff Description: Binary data ___ 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] [Python-checkins] r87458 - python/branches/py3k/Lib/gettext.py
# a?b:c to test(a,b,c). expr = re.compile(r'(.*?)\?(.*?):(.*)') def repl(x): -return test(%s, %s, %s) % (x.group(1), x.group(2), - expr.sub(repl, x.group(3))) +return (%s if %s else %s) % (x.group(2), x.group(1), + expr.sub(repl, x.group(3))) Please update the comment as well. Regards, Martin ___ 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] [Python-checkins] r87458 - python/branches/py3k/Lib/gettext.py
2010/12/23 Martin v. Löwis mar...@v.loewis.de: # a?b:c to test(a,b,c). expr = re.compile(r'(.*?)\?(.*?):(.*)') def repl(x): - return test(%s, %s, %s) % (x.group(1), x.group(2), - expr.sub(repl, x.group(3))) + return (%s if %s else %s) % (x.group(2), x.group(1), + expr.sub(repl, x.group(3))) Please update the comment as well. Done. -- Regards, Benjamin ___ 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] [Python-checkins] r87445 - python/branches/py3k/Lib/numbers.py
On Fri, Dec 24, 2010 at 4:41 AM, eric.araujo python-check...@python.org wrote: Author: eric.araujo Date: Thu Dec 23 19:41:33 2010 New Revision: 87445 Log: Fix small inaccuracy: there is no index function Yes, there is, it just isn't a builtin - it lives in the operator module. def __index__(self): - index(self) + someobject[self] return int(self) Changing the docstring to say operator.index(self) would be the clearest solution here. (Choosing to accept arbitrary index objects as integer equivalents is up to the object being indexed, just like interpreting slices is - a dict, for example, will never invoke __index__ methods). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Fault handler updated, now disabled by default
Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit : this thread showed that it is not at all obvious how the feature should look like Ok, I understand. I closed #8863 (rejected) and I created a third party module on the Python cheese shop: http://pypi.python.org/pypi/faulthandler/ The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2. A third party module can evolve faster outside Python. Victor ___ 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] Fault handler updated, now disabled by default
Le jeudi 23 décembre 2010 à 22:58 +, Martin (gzlist) a écrit : On 23/12/2010, Victor Stinner victor.stin...@haypocalc.com wrote: I tested my patch on Windows (XP), Ubuntu (10.4) and FreeBSD (8) and it works correctly: all tests pass and the system fault handler (Windows popup, Apport and core dump) is also called. Doesn't build for me without #ifdef HAVE_UNISTD_H in Python/fault.c Yes, I wrote a comment about that in the issue. But then I realized that this header is not needed at all. you missed my comment about raise vs. kill in the other thread which lets the SIGILL test run as well Oh, I didn't noticed that this change enables sigill() on Windows. Nice :-) I created a third party module from my patch: http://pypi.python.org/pypi/faulthandler/ I commited your patch, thanks. I added you to the authors as a contributor. Victor ___ 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] Fault handler updated, now disabled by default
Am 24.12.2010 03:21, schrieb Victor Stinner: Le jeudi 23 décembre 2010 à 21:59 +0100, Georg Brandl a écrit : this thread showed that it is not at all obvious how the feature should look like Ok, I understand. I closed #8863 (rejected) and I created a third party module on the Python cheese shop: http://pypi.python.org/pypi/faulthandler/ The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2. A third party module can evolve faster outside Python. Very good. I take it you'll make a new issue then for inclusion in 3.3? Georg ___ 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
