Re: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sat, 15 Apr 2006, Tim Peters wrote: [...] Hmm, will 2.5's doctest work under Python 2.4? I guess that's not guaranteed, since I don't see any comment in doctest.py implying it needs to be compatible with old Pythons. doctest compatibility with 2.4 is neither a goal nor a non-goal for 2.5. I'm not sure why it's being asked, since the incompatible change projected for 2.5 is in how the trackback module spells some exception names; and doctest (every version of doctest) gets its idea of the name of an exception from the traceback module. Ah, yes. (Does the channelling service extend to divining the questions that posters on python-dev *should* have asked? No?) OK, I suppose I should have asked will 2.5's module traceback work with Python 2.4?. I guess the answer is something resembling no, but of course (?) the question I'm really interested in is how, without too much effort or ugliness, can people run their doctests on both 2.4 and 2.5? I guess if I care sufficiently, I should just go ahead and back-port to 2.4 insert whatever #$! code turns out to need back-porting here ;- and post it somewhere for the public good. John ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On 4/16/06, John J Lee [EMAIL PROTECTED] wrote: OK, I suppose I should have asked will 2.5's module traceback work with Python 2.4?. I guess the answer is something resembling no, but of course (?) the question I'm really interested in is how, without too much effort or ugliness, can people run their doctests on both 2.4 and 2.5? I think there was an example earlier - you could change your doctest to not rely on the exact exception by catching it: try: ... 1/0 ... except ZeroDivisionError: ... print Divide by zero! ... Divide by zero! Whether that counts as too much effort or ugliness, I'm not sure. Personally, my instinct is that having the whole traceback in a doctest is at least as ugly. Paul. ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On 4/16/06, Paul Moore [EMAIL PROTECTED] wrote: Personally, my instinct is that having the whole traceback in a doctest is at least as ugly. Well, it depends on what you use doctest for. If you use it to write unit tests, the try/except solution is fine, and perhaps preferable. If you use it as *documentation*, where doctest is used to ensure that the documentation is accurate, showing a (short) traceback seems to be the logical thing to do. In a sample session where you want to show that a certain exception is raised for a certain combination of erroneous arguments (for example), showing the traceback is much more natural than putting a try/except around the erroneous call. So one person's ugly is another person's pretty. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sun, 16 Apr 2006, Guido van Rossum wrote:
On 4/16/06, Paul Moore [EMAIL PROTECTED] wrote:
Personally, my instinct is that having the whole traceback in a
doctest is at least as ugly.
You don't need the whole traceback -- e.g.:
If a URL is supplied, it must have an authority (host:port) component.
According to RFC 3986, having an authority component means the URL must
have two slashes after the scheme:
_parse_proxy('file:/ftp.example.com/')
Traceback (most recent call last):
ValueError: proxy URL with no authority: 'file:/ftp.example.com/'
I think the try: ... except FooException: print 'FooException occurred'
style is uglier and less natural than that, but I guess it's not a big
deal.
Well, it depends on what you use doctest for. If you use it to write
unit tests, the try/except solution is fine, and perhaps preferable.
[...]
Preferable because depending less on irrelevant details? I had thought
that, apart from the issue with module traceback, IGNORE_EXCEPTION_DETAIL
made that a non-issue in most cases, but perhaps I missed something
(again).
John
___
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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Sat, 15 Apr 2006, Tim Peters wrote: [...] [also John] Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... That's news to Tim ;-) You mentioned use of '...' / ELLIPSIS, IIRC, so I assumed that would work -- but it seems not, from your latest post (that I'm replying to here). It's not possible to add a new doctest option in 2.5 that would allow a doctest to work under both 2.4 and 2.5: the test would blow up under 2.4, because 2.4's doctest wouldn't recognize the (new in 2.5) option, and would raise a ValueError of its own griping about the unknown option name. slaps forehead [...] import decimal try: 1 / decimal.Decimal(0) except decimal.DivisionByZero: print good good Yes, that works, I see. Kind of annoying of course, but can't be helped. Hmm, will 2.5's doctest work under Python 2.4? I guess that's not guaranteed, since I don't see any comment in doctest.py implying it needs to be compatible with old Pythons. Oddly enough, ELLIPSIS doesn't actually work for this purpose: [...] John ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
[John J Lee] ... You mentioned use of '...' / ELLIPSIS, IIRC, so I assumed that would work -- but it seems not, from your latest post (that I'm replying to here). Different context -- answering why IGNORE_EXCEPTION_DETAIL exists given that ELLIPSIS can do everything it does (provided you don't care about Pythons before 2.4). That sub-thread was a red herring (a distraction from the real topic here). ... Hmm, will 2.5's doctest work under Python 2.4? I guess that's not guaranteed, since I don't see any comment in doctest.py implying it needs to be compatible with old Pythons. doctest compatibility with 2.4 is neither a goal nor a non-goal for 2.5. I'm not sure why it's being asked, since the incompatible change projected for 2.5 is in how the trackback module spells some exception names; and doctest (every version of doctest) gets its idea of the name of an exception from the traceback module. ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On 4/14/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 14 April 2006 02:31, Martin v. Löwis wrote: Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I also think the traceback module should be corrected, and the test cases updated, despite the objections that it may break other people's doctest test cases. Let me chime in with agreement (2.5 only of course). I don't mind one way or the other, but with the number of people working actively on the code at the moment, I think reverting broken patches that don't have trivial test fixes is the way to go. The buildbot system is useless, otherwise. That was the right thing to do (short of fixing all the missing tests, which requires actual thinking :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... On Fri, 14 Apr 2006, John J Lee wrote: [...] Assuming this is fixed in 2.5 final, is there some way to write doctests that work on both 2.4 and 2.5? If not, should something like doctest.IGNORE_EXCEPTION_DETAIL be added -- say IGNORE_EXCEPTION_MODULE? [...] ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
[John J Lee] Assuming this is fixed in 2.5 final, is there some way to write doctests that work on both 2.4 and 2.5? If not, should something like doctest.IGNORE_EXCEPTION_DETAIL be added -- say IGNORE_EXCEPTION_MODULE? [also John] Sorry, please ignore the post of mine I'm replying to here. I missed part of the thread, and Tim has already answered my question... That's news to Tim ;-) It's not possible to add a new doctest option in 2.5 that would allow a doctest to work under both 2.4 and 2.5: the test would blow up under 2.4, because 2.4's doctest wouldn't recognize the (new in 2.5) option, and would raise a ValueError of its own griping about the unknown option name. It would be possible to add a new doctest option in 2.5 that would (just) allow a doctest running _under_ 2.5 to accept a bare name in an exception despite that the traceback module changed in 2.5 to produce some.dotted.name instead. That doesn't seem very useful, though (as above, it would force the test to fail when run under 2.4). Of course a doctest can contain any Python code, so there are many ways to write a doctest that passes under all versions of Python, without active help from doctest. For example, using the running example in this thread, this way works under all versions of Python with a decimal module: import decimal try: 1 / decimal.Decimal(0) except decimal.DivisionByZero: print good good Oddly enough, ELLIPSIS doesn't actually work for this purpose: import decimal 1 / decimal.Decimal(0) #doctest: +ELLIPSIS Traceback (most recent call last): [etc] ...DivisionByZero: x / 0 That test fails under 2.4, and would also fail under the presumably changed 2.5. The problem is that, as the docs say, when trying to guess where an exception message starts, doctest skips down to the first line after the Traceback line indented the same as the Traceback line and starting with an _alphanumeric_ character. There is no such line in this example (the exception line starts with a period), so doctest believes the example is showing expected stdout, not that it's showing an exception. The delightfully baffling result is that doctest complains that the example raises an exception when an exception wasn't expected. Stinking magic ;-) ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [georg.brandl] Author: georg.brandl Date: Wed Apr 12 23:14:09 2006 New Revision: 45321 Modified: python/trunk/Lib/test/test_traceback.py python/trunk/Lib/traceback.py python/trunk/Misc/NEWS Log: Patch #860326: traceback.format_exception_only() now prepends the exception's module name to non-builtin exceptions, like the interpreter itself does. And all the trunk buildbot runs have failed since, in at least test_decimal, test_doctest and test_unpack. Please run tests before checking in. Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Right. That's too much of a behavior change. Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. Cheers, 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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [Georg Brandl] Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. Nobody ever expects that a checkin will break tests, so merely expecting that a checkin won't break tests is not sufficient reason to skip running tests. You made a checkin that broke every buildbot slave we have, and I suggest you're taking a wrong lesson from that ;-) No objection, mylord ;) Do release-build tests without -uall take over half an hour on your box? Running that much is good enough precaution. Even (on boxes with makefiles) running make quicktest is mounds better than doing no testing. All the cases of massive buildbot test breakage we've seen this week would have been caught by doing just that much before checkin. Until now, I've always run with -uall. Running make quicktest is fine, but if the buildbots starts failing with -uall afterwards, no one will accept that as an excuse ;) When previously-passing buildbots start failing, it at least stops me cold, and (I hope) stops others too. Sometimes it's unavoidable. For example, I spent almost all my Python time Monday repairing a variety of new test failures unique to the OpenBSD buildbot (that platform is apparently unique in assigning addresses with the sign bit set, which broke all sorts of tests after someone changed id() to always return a positive value). That's fine -- it happens. It's the seemingly routine practice this week of checking in changes that break the tests everywhere that destroys productivity without good cause. I see, and I'm sorry I was part of it. Relatedly, if someone makes a checkin and sees that it breaks lots of buildbot runs, they should revert the patch themself instead of waiting for someone else to get so frustrated that they do it. Reverting is very easy with svn, but people are reluctant to revert someone else's checkin. The buildbot system is useless so long as the tests fail, and having the tests pass isn't optional. For excuse, I posted here immediately after I saw that the tests failed, asking whether to change doctest or revert my change. I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. Fine. There's another one, python.org/sf/1326077, which looks suspicious to me too. 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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I also think the traceback module should be corrected, and the test cases updated, despite the objections that it may break other people's doctest test cases. 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
[georg.brandl] Author: georg.brandl Date: Wed Apr 12 23:14:09 2006 New Revision: 45321 Modified: python/trunk/Lib/test/test_traceback.py python/trunk/Lib/traceback.py python/trunk/Misc/NEWS Log: Patch #860326: traceback.format_exception_only() now prepends the exception's module name to non-builtin exceptions, like the interpreter itself does. And all the trunk buildbot runs have failed since, in at least test_decimal, test_doctest and test_unpack. Please run tests before checking in. The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
At 09:14 PM 4/12/2006 -0400, Tim Peters wrote: The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). It's not fine by me if the reason for the failure is that doctests trapping specific exceptions no longer work with the patch. If that's the case, the patch should be reverted entirely, absent any compelling reasoning for breaking *everyone else's* doctests in 2.5. ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
On Thursday 13 April 2006 11:14, Tim Peters wrote: Patch #860326: traceback.format_exception_only() now prepends the exception's module name to non-builtin exceptions, like the interpreter itself does. And all the trunk buildbot runs have failed since, in at least test_decimal, test_doctest and test_unpack. Please run tests before checking in. The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Correct. I have reverted this on the release24-maint branch. Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). I'm reverting on the trunk, too. Per PJE's email as well, I think this needs discussion before committing (and it needs the tests updated, first!) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
[Tim] ... Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). [Phillip] It's not fine by me if the reason for the failure is that doctests trapping specific exceptions no longer work with the patch. If that's the case, the patch should be reverted entirely, absent any compelling reasoning for breaking *everyone else's* doctests in 2.5. I agree with the patch author's position that it's a bug that the traceback module's functions' output doesn't match the interpreter's traceback output. That certainly wasn't intended; it's most likely left over from the days when only strings could be exceptions, and nobody noticed that the old traceback-module code didn't work exactly right anymore when the notion of exceptions was generalized. WRT doctests, it's a mixed bag. Yes, some tests will fail. doctests are always vulnerable to changes like this. OTOH, the change also simplifies writing new doctests. I remember being baffled at doing things like: import decimal 1 / decimal.Decimal(0) Traceback (most recent call last): File stdin, line 1, in ? File C:\Python24\lib\decimal.py, line 1314, in __rdiv__ return other.__div__(self, context=context) File C:\Python24\lib\decimal.py, line 1140, in __div__ return self._divide(other, context=context) File C:\Python24\lib\decimal.py, line 1222, in _divide return context._raise_error(DivisionByZero, 'x / 0', sign) File C:\Python24\lib\decimal.py, line 2267, in _raise_error raise error, explanation decimal.DivisionByZero: x / 0 in an interactive shell, pasting it into a doctest, and then seeing the doctest fail because the exception name somehow magically changed to just DivisionByZero. I got used to that before I found time to understand it, though. Future generations wouldn't suffer this cognitive dissonance. A less-desirable (IMO) alternative is to change the Python core to display bare (non-dotted) exception names when it produces a traceback. The fundamental bug here is that the core and the traceback module produce different tracebacks given the same exception info, and changing either could repair that. ___ 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] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: A less-desirable (IMO) alternative is to change the Python core to display bare (non-dotted) exception names when it produces a traceback. Much less desirable, considering that there are modules which define an exception just called error on the assumption that you're going to see the module name as well. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
