Re: [Python-Dev] Locale-specific formatting
On Mon, Dec 20, 2010 at 01:09:19AM +0100, ??ric Araujo wrote: Le 18/12/2010 16:33, Oleg Broytman a ??crit : This is quite a known problem, not specific to Python. Locale settings are global for a process, and this is one of the thousands reasons why locale is considered so horrible. ICU is perhaps the only way around the problem. Babel rocks: http://babel.edgewall.org/ Unicode CLDR! Never heard of it before, thank you for pointing this out. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
Antoine Pitrou wrote: For a non-native English speaker, 'a' and 'b' don't evoke 'after' and 'before' but simply the first two letters of the latin alphabet, and their ordering is therefore obvious with respect to function arguments. It's not just non-native English speakers either. I too think of a, b as being first, second rather than after, before. -- Steven ___ 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
Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl g.bra...@gmx.net wrote: .. In any case, this is coming pretty late; beta 2 is scheduled for this weekend, and even if this is something that only kicks in when all hope is lost anyway, it is a new feature. I should like to hear approval from a few more devs before I will let this go into 3.2. I am -1 on the feature as written. I would be -0 if it did not install signal handlers by default and even better was implemented in a separate module, not in core. I would not want this to be the default either. I think the output is not particularly informative: $ ./python Lib/test/crashers/gc_inspection.py (object object at 0x7f01827ad870, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/gc_inspection.py, line 29 in g File Lib/test/crashers/gc_inspection.py, line 32 in module Segmentation fault Segmentation fault Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] It's hard to get signal handlers right across multiple platforms; even SIGINT catching does not work properly on OpenBSD: http://bugs.python.org/issue8714 In short, I agree that having more signal handlers by default is not a good idea. Stefan Krah ___ 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
Stefan Krah ste...@bytereef.org wrote: Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] And this test does not report anything at all: $ ./python Lib/test/crashers/compiler_recursion.py [no output at all] $ echo $? 0 Without the patch: $ ./python Lib/test/crashers/compiler_recursion.py Segmentation fault $ echo $? 139 Stefan Krah ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 19/12/2010 19:55, Raymond Hettinger wrote: On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote: On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrousolip...@pitrou.net wrote: On Sat, 18 Dec 2010 20:23:49 -0800 Guido van Rossumgu...@python.org wrote: I may be unique, but I fear there is no great answer. On the one hand I almost always code it as e.g. assertEqual(actual, expected), which matches my preference for e.g. if x == 5: rather than if 5 == x:. On the other hand in those assert* functions that show a nice diff of two lists, when reading such a diff my expectation is that old, new corresponds to expected, actual. Which then freaks me out until I realize that I coded it as actual, expected... And yet expected, actual still looks weird to me. :-( This could be nicely resolved by renaming the arguments a and b, and having the diff display a, b. It's quite natural (both the diff ordering and the arguments ordering), and they are consistent with each other. So 'a' stands for 'after' and 'b' for 'before', right? :-) If you go down the a / b path instead of actual/expected, the diffs are straight-forward but some of the other output styles needed to be changed also (replace the messages for unexpected and missing elements to things in a but not in b and things in b but not in a. Ah man, we've *nearly* finished bikeshedding about the names of unittest assert methods so its time to move onto the names and order of the arguments. Really? I wouldn't use a/b but first/second [1] as they have a more obvious meaning. However, I'm reluctant to move away from the actual/expected terminology. It's standard terminology for testing (used by all the other unit testing frameworks I looked at phpunit, JUnit and NUnit), but more importantly it is a useful way to think about testing - and one used by most devs I've worked with. You fetch an 'actual' result by calling your code and compare it against a pre-computed 'expected' result. Hopefully the two are the same. Talking about your actual value and your expected value is a natural way to talk in testing, so it's a useful concept. Once you use the 'actual' and 'expected' terminology you have a natural order for displaying failure message results: if an element is present in your actual but not in your expected then it is extra. If an element is in your expected but not in your actual then it is missing. Straightforward. (Of course it maybe that your actual is correct and it is your expected result needs correcting, that doesn't affect how failure messages should be presented though.) The only thing left to decide is then the order - (actual, expected) or (expected, actual). Raymond, myself, Guido and Ezio have all expressed a preference for (actual, expected). I like this comment from Raymond on the relevant issue [2]: I also tend to use actual/expected and find the reverse to be a form Yoda-speak, assert 5 == x, perhaps misread the prophecy was, etc. As the current ordering used within unittest is (actual, expected), to reverse it would be dumb (why should everyone using the current ordering reformat all their tests for the new order?). So, -1 on dropping actual and expected. They're standard and useful terminology / concepts for testing. If we do move to a more agnostic wording in the failure messages (whilst keeping actual / expected as argument names and in the documentation perhaps?) then I prefer first / second to a / b. All the best, Michael Foord [1] Interestingly unittest did use (first, second) for assert argument names back in 2.1 when it was added: http://svn.python.org/view/python/branches/release21-maint/Lib/unittest.py?revision=24536view=markup [2] http://bugs.python.org/issue10573 Raymond ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessinghttp://www.sqlite.org/different.html ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : Ah man, we've *nearly* finished bikeshedding about the names of unittest assert methods so its time to move onto the names and order of the arguments. Really? Apparently someone decided this bikeshedding was important enough to make an SVN commit out of it. If you think it isn't worth discussing then perhaps it wasn't worth changing in the first place :) The only thing left to decide is then the order - (actual, expected) or (expected, actual). Raymond, myself, Guido and Ezio have all expressed a preference for (actual, expected). I like this comment from Raymond on the relevant issue [2]: I also tend to use actual/expected and find the reverse to be a form Yoda-speak, assert 5 == x, perhaps misread the prophecy was, etc. Isn't it some kind of ethnocentric comment? Natural order is not the same in all languages, and I don't see why actual should come before expected. And the problem here is that (actual, expected) is in reverse order of the diff displayed on error. Now if you look at various TypeErrors raised in Python, the error message is most often expected some type, got other type. So there expected always comes before actual, and apparently it was natural to the authors of that code. Perhaps they are all Yoda-speakers. And moreover, some methods such as assertRaises() already have their args in the (expected, actual) order. If we do move to a more agnostic wording in the failure messages (whilst keeping actual / expected as argument names and in the documentation perhaps?) then I prefer first / second to a / b. Well, no. The whole point of displaying results as a/b (or first/second) is that they map intuitively to the first and second args. If, however, you name those args actual and expected, it becomes confusing. Also, it wouldn't fix that your diff would still be in a weird order compared to the method args (unless you think it's fine to display an expected - actual diff). 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 20/12/2010 13:47, Antoine Pitrou wrote: Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : Ah man, we've *nearly* finished bikeshedding about the names of unittest assert methods so its time to move onto the names and order of the arguments. Really? Apparently someone decided this bikeshedding was important enough to make an SVN commit out of it. If you think it isn't worth discussing then perhaps it wasn't worth changing in the first place :) The only change was to use them consistently and the only code change was to re-order the arguments in a method that is new and not in any previous version of Python. You're arguing for a much bigger change. The only thing left to decide is then the order - (actual, expected) or (expected, actual). Raymond, myself, Guido and Ezio have all expressed a preference for (actual, expected). I like this comment from Raymond on the relevant issue [2]: I also tend to use actual/expected and find the reverse to be a form Yoda-speak, assert 5 == x, perhaps misread the prophecy was, etc. Isn't it some kind of ethnocentric comment? Natural order is not the same in all languages, and I don't see why actual should come before expected. Agreement that actual, expected was preferred came from an American, a Dutchman, an Englishman and an Italian. :-) As it is what unittest currently uses anyway you'll need more than I don't see why to reverse it. And the problem here is that (actual, expected) is in reverse order of the diff displayed on error. Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result. Now if you look at various TypeErrors raised in Python, the error message is most often expectedsome type, gotother type. So there expected always comes before actual, and apparently it was natural to the authors of that code. Perhaps they are all Yoda-speakers. And moreover, some methods such as assertRaises() already have their args in the (expected, actual) order. If we do move to a more agnostic wording in the failure messages (whilst keeping actual / expected as argument names and in the documentation perhaps?) then I prefer first / second to a / b. Well, no. The whole point of displaying results as a/b (or first/second) is that they map intuitively to the first and second args. If, however, you name those args actual and expected, it becomes confusing. Also, it wouldn't fix that your diff would still be in a weird order compared to the method args (unless you think it's fine to display an expected - actual diff). I told you how I think the diff should be generated and gave the reasons for it. If we use first / second in failure messages (but not necessarily in documentation or argument names - your objections notwithstanding) then the messages for the container asserts don't need to imply a direction (as Raymond suggested, wording like in first but not in second and in second but not in first). The string diffs are more problematic as they actually use difflib to generate the failure output. I'm also against dropping the use of actual / expected concepts and terminology within unittest as I think they are useful. We don't necessarily need to use them in the failure outputs but it seems like you want them to be dropped altogether. All the best, Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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 PYTHONNOFAUL THANDLER environment variable
Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit : I think the output is not particularly informative: $ ./python Lib/test/crashers/gc_inspection.py (object object at 0x7f01827ad870, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/gc_inspection.py, line 29 in g File Lib/test/crashers/gc_inspection.py, line 32 in module Segmentation fault Segmentation fault The backtrace is valid. Don't you think that this backtrace is more useful than just Segmentation fault? Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] I didn't tried with patch version 9, but with the patch version 10 I get: - $ ./python Lib/test/crashers/nasty_eq_vs_dict.py Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/nasty_eq_vs_dict.py, line 16 in __hash__ File Lib/test/crashers/nasty_eq_vs_dict.py, line 40 in __fill_dict File Lib/test/crashers/nasty_eq_vs_dict.py, line 30 in __eq__ File Lib/test/crashers/nasty_eq_vs_dict.py, line 47 in module Segmentation fault Erreur de segmentation $ echo $? 139 - And this test does not report anything at all: $ ./python Lib/test/crashers/compiler_recursion.py [no output at all] $ echo $? 0 Patch version 9 doesn't call the previous handler. Please retry with patch version 10 (which call the previous handler). With the patch version 10 I get: - $ ./python Lib/test/crashers/compiler_recursion.py Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/compiler_recursion.py, line 5 in module Segmentation fault Erreur de segmentation $ echo $? 139 - 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Le lundi 20 décembre 2010 08:22:40, vous avez écrit : Looking at your function list, my other concern is that you are calling Python API without holding the GIL, IIUC. In particular, you are accessing _PyThreadState_Current, which may not point to the current thread if the current thread has released the GIL. Ah? Where does _PyThreadState_Current point to if the GIL is not hold when the fault handler is called? The GIL is likely held by a different thread, then. _PyThreadState_Current will point to the state of this other thread. I tested when the GIL released: the fault handler is unable to retrieve the thread state and so the backtrace is not printed. Which thread state should be retrieve? I don't know yet: maybe the last active thread state? It doesn't look trivial to fix this issue because if there is no thread (only the main thread), release the GIL clears the thread state pointer (to it to NULL) without storing it somewhere else (whereas with multiple threads, the last active thread is stored in gil_last_holder. I should ask Antoine (or someone one) how the new GIL works. Of this thread? I don't think so. gil_last_holder might also refer to a different thread. Another variable might be created to store the (pointer to the) last active thread state. I don't think that it will possible the acquire the GIL in Py_FatalError() or in the fault handler. I agree. We all love deadlocks :-) 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
Le lundi 20 décembre 2010 à 14:03 +, Michael Foord a écrit : On 20/12/2010 13:47, Antoine Pitrou wrote: Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : Ah man, we've *nearly* finished bikeshedding about the names of unittest assert methods so its time to move onto the names and order of the arguments. Really? Apparently someone decided this bikeshedding was important enough to make an SVN commit out of it. If you think it isn't worth discussing then perhaps it wasn't worth changing in the first place :) The only change was to use them consistently and the only code change was to re-order the arguments in a method that is new and not in any previous version of Python. You're arguing for a much bigger change. No, I'm first of all arguing for a first/second or a/b argument naming. Which was exactly the case before the change that triggered this thread. The only thing left to decide is then the order - (actual, expected) or (expected, actual). Raymond, myself, Guido and Ezio have all expressed a preference for (actual, expected). I like this comment from Raymond on the relevant issue [2]: I also tend to use actual/expected and find the reverse to be a form Yoda-speak, assert 5 == x, perhaps misread the prophecy was, etc. Isn't it some kind of ethnocentric comment? Natural order is not the same in all languages, and I don't see why actual should come before expected. Agreement that actual, expected was preferred came from an American, a Dutchman, an Englishman and an Italian. :-) I'm not sure what that's supposed to prove, unless you have problems with the idea that what is natural for a couple of people isn't natural for everyone. You also apparently missed that part: Now if you look at various TypeErrors raised in Python, the error message is most often expectedsome type, gotother type. So there expected always comes before actual, and apparently it was natural to the authors of that code. Perhaps they are all Yoda-speakers. As it is what unittest currently uses anyway you'll need more than I don't see why to reverse it. unittest doesn't use it anyway, since it used first/second before that change. Actually, as I pointed out, (expected, actual) is used in assertRaises in friends. And the problem here is that (actual, expected) is in reverse order of the diff displayed on error. Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result. Which, again, they don't. Let's see: self.assertEqual(actual, expected) AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c - e + d The diff shows expected - actual, but it would be logical (in your own logic) to display actual - expected. The whole issue disappears if you drop this idea of naming the arguments actual and expected. I'm also against dropping the use of actual / expected concepts and terminology within unittest as I think they are useful. We don't necessarily need to use them in the failure outputs but it seems like you want them to be dropped altogether. I'm saying that they cause confusion wrt. to the actual error display (as Guido also admitted). Feel free to come up with a solution that doesn't get rid of actual/expected, if that's what you want ;) 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] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable
Victor Stinner vstin...@edenwall.com wrote: Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit : I think the output is not particularly informative: $ ./python Lib/test/crashers/gc_inspection.py (object object at 0x7f01827ad870, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/gc_inspection.py, line 29 in g File Lib/test/crashers/gc_inspection.py, line 32 in module Segmentation fault Segmentation fault The backtrace is valid. Don't you think that this backtrace is more useful than just Segmentation fault? Perhaps I misunderstood, but I thought the purpose of the patch was to let developers act more quickly on bug reports. I wonder if this output really speeds up the process. Do you have an example bug where this patch helps in finding the precise location of a segfault? Patch version 9 doesn't call the previous handler. Please retry with patch version 10 (which call the previous handler). I did use version 10. I've verified the same behavior with a fresh py3k checkout and this patch: $ md5sum segfault_handler-10.patch e1b5a9439d2b51d0a63f701dd694796d segfault_handler-10.patch My machine currently has a load average of 2. Perhaps you'll be able to reproduce it if you crank up the load average. Stefan Krah ___ 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 PYTHONNOFA ULTHANDLER?environment variable
Le lundi 20 décembre 2010 15:55:57, Stefan Krah a écrit : The backtrace is valid. Don't you think that this backtrace is more useful than just Segmentation fault? Perhaps I misunderstood, but I thought the purpose of the patch was to let developers act more quickly on bug reports. I wonder if this output really speeds up the process. The fault handler helps developers because they don't have to have a Python compiled in debug mode and to run the application in a debugger (like gdb). If the developer is unable to reproduce an error, because it's an Heisenbug, or because the developer doesn't have the same OS, libraries and/or applications, the fault handler helps the developer to isolate the problem. Many bugs only occur once and you cannot report a bug report because you don't have any useful information. But the fault handler doesn't help graphical applications not started from a terminal... Do you have an example bug where this patch helps in finding the precise location of a segfault? Any bug report which only contain Segmentation fault information. But I cannot give you a revelant example because users are too shy to report an issue if they don't have more information than just the program crashed. With a fault handler displaying the Python backtrace, I hope that more *users* will report bugs. Example of an issue with only the Segmentation fault information: http://bugs.python.org/issue6011#msg121551 I am unable to reproduce this crash, and I'm very frustrated because I want to fix it! :-) Another example which might benefit from the fault handler: http://bugs.python.org/issue7424 --- Compiling /usr/pkg/lib/python2.6/test/test_builtin.py ... [1] Segmentation fault (core dumped) PYTHONPATH=/usr/... *** Error code 139 --- If the reporter already wrote a minimal script, it doesn't help. The fault handler helps to write the minimal script (to isolate the bug). I did use version 10. I've verified the same behavior with a fresh py3k checkout and this patch: (...) My machine currently has a load average of 2. Perhaps you'll be able to reproduce it if you crank up the load average. What is your OS (name, version)? I only tested crashers on Linux (Debian Sid). 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/18/2010 04:46 PM, Terry Reedy wrote: On 12/18/2010 3:48 PM, Antoine Pitrou wrote: On Sat, 18 Dec 2010 21:00:04 +0100 (CET) ezio.melottipython-check...@python.org wrote: Author: ezio.melotti Date: Sat Dec 18 21:00:04 2010 New Revision: 87389 Log: #10573: use actual/expected consistently in unittest methods. Change was requested by M. Foord and R. Hettinger (and G.Brandl for b2). IMHO, this should be reverted. The API currently doesn't treat these arguments differently, so they should really be labeled first and second. Otherwise, the user will wrongly assume that the signature is asymmetric and that they should be careful about which order they pass the arguments in. I've always presumed it would make a difference in error displayed anyway. The error report on assert failure *is* often asymmetrical ;=). From Michael's post: This is particularly relevant for the methods that produce 'diffed' output on failure - as the order determines whether mismatched items are missing from the expected or additional to the expected. This change struck me as a nice bit of polishing. I like (actual, expected) in the asserts. It matches my expected ordering of input/output and how I use comparisons in 'if' statements. I feel it is more important that the diffs are consistent with other diffs in python. So (for me), changing the asymmetrical output to be symmetrical would be in the category of foolish consistency because changing that, introduces other inconsistencies I'd rather not have. It doesn't bother me that the functions arguments aren't the same order of the diffs as long as the labels and wording are obvious enough in the messages. So maybe the diff output can be improved a bit instead of changing the terms and ordering. Ron ___ 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
[Python-Dev] sqlite, DDL, and transactions
Hi
The python sqlite module automatically commits open transactions
when it encounters a DDL statement. This is unnecessary; DDL is
transaction in my testing (see attached).
Attached patch addresses the issue. Patch is against 2.6.1, but
looking at Trunk in svn, it seems like the patch is needed and
would apply. One issue I could foresee is that this behavior might
depend on the sqlite version in use (I'm on 3.6.10).
Thanks
Scott
diff -Nu -r --show-c-func work/Python-2.6.1/Modules/_sqlite/cursor.c work.new/Python-2.6.1/Modules/_sqlite/cursor.c
--- work/Python-2.6.1/Modules/_sqlite/cursor.c 2008-09-12 15:33:22.0 -0700
+++ work.new/Python-2.6.1/Modules/_sqlite/cursor.c 2010-12-17 14:26:48.323301733 -0800
@@ -69,6 +69,14 @@ static pysqlite_StatementKind detect_sta
return STATEMENT_DELETE;
} else if (!strcmp(buf, replace)) {
return STATEMENT_REPLACE;
+} else if (!strcmp(buf, create)) {
+return STATEMENT_CREATE;
+} else if (!strcmp(buf, alter)) {
+return STATEMENT_ALTER;
+} else if (!strcmp(buf, drop)) {
+return STATEMENT_DROP;
+} else if (!strcmp(buf, pragma)) {
+return STATEMENT_PRAGMA;
} else {
return STATEMENT_OTHER;
}
@@ -560,6 +568,10 @@ PyObject* _pysqlite_query_execute(pysqli
case STATEMENT_DELETE:
case STATEMENT_INSERT:
case STATEMENT_REPLACE:
+case STATEMENT_CREATE:
+case STATEMENT_ALTER:
+case STATEMENT_DROP:
+case STATEMENT_PRAGMA:
if (!self-connection-inTransaction) {
result = _pysqlite_connection_begin(self-connection);
if (!result) {
@@ -569,8 +581,9 @@ PyObject* _pysqlite_query_execute(pysqli
}
break;
case STATEMENT_OTHER:
-/* it's a DDL statement or something similar
- - we better COMMIT first so it works for all cases */
+/* something else
+ - we better COMMIT first so it works for all cases.
+ - XXX this is probably a bad idea (surprising) */
if (self-connection-inTransaction) {
result = pysqlite_connection_commit(self-connection, NULL);
if (!result) {
diff -Nu -r --show-c-func work/Python-2.6.1/Modules/_sqlite/cursor.h work.new/Python-2.6.1/Modules/_sqlite/cursor.h
--- work/Python-2.6.1/Modules/_sqlite/cursor.h 2008-05-31 14:33:27.0 -0700
+++ work.new/Python-2.6.1/Modules/_sqlite/cursor.h 2010-12-17 14:27:24.893792279 -0800
@@ -48,7 +48,8 @@ typedef struct
typedef enum {
STATEMENT_INVALID, STATEMENT_INSERT, STATEMENT_DELETE,
STATEMENT_UPDATE, STATEMENT_REPLACE, STATEMENT_SELECT,
-STATEMENT_OTHER
+STATEMENT_CREATE, STATEMENT_ALTER, STATEMENT_DROP,
+STATEMENT_PRAGMA, STATEMENT_OTHER
} pysqlite_StatementKind;
extern PyTypeObject pysqlite_CursorType;
import atexit
import os
import sqlite3
class FakeError:
pass
def table_exists(conn, table):
sql = 'PRAGMA TABLE_INFO(%s) ' % table
cur = conn.execute(sql)
row = cur.fetchone()
return row is not None
def row_count(conn, table):
cur = conn.execute('SELECT COUNT(*) FROM %s' % table)
row = cur.fetchone()
return row[0]
def index_exists(conn, table):
sql = 'PRAGMA INDEX_INFO(%s) ' % table
cur = conn.execute(sql)
row = cur.fetchone()
return row is not None
def column_exists(conn, table, column):
sql = 'PRAGMA TABLE_INFO(%s) ' % table
cur = conn.execute(sql)
for row in cur:
if row[1] == column:
return True
return False
def create_temp_database():
filename = os.tempnam('/tmp', 'test') + '.db'
#print using filename, filename
conn = sqlite3.connect(filename)
atexit.register(os.remove, filename)
conn.execute('CREATE TABLE foo (id INTEGER)')
conn.commit()
assert table_exists(conn, 'foo')
return conn
def test_dml():
''' check basic dml is transactional '''
conn = create_temp_database()
conn.execute('INSERT INTO foo VALUES (1)')
conn.rollback()
assert row_count(conn, 'foo') == 0
def test_table_create():
''' check that table create is transactional '''
conn = create_temp_database()
conn.execute('INSERT INTO foo VALUES (1)')
conn.execute('CREATE TABLE bar (id INTEGER)')
assert table_exists(conn, 'bar')
conn.execute('INSERT INTO bar VALUES (1)')
conn.rollback()
assert not table_exists(conn, 'bar')
def test_index_create():
''' check that index create is transactional '''
conn = create_temp_database()
conn.execute('INSERT INTO foo VALUES (1)')
conn.execute('CREATE INDEX foo_by_id ON foo (id)')
assert index_exists(conn, 'foo_by_id')
conn.execute('INSERT INTO foo VALUES (2)')
conn.rollback()
assert not index_exists(conn, 'foo_by_id')
def test_column_add():
''' check that column add is transactional '''
Re: [Python-Dev] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable
Victor Stinner vstin...@edenwall.com wrote: Le lundi 20 décembre 2010 15:55:57, Stefan Krah a écrit : The backtrace is valid. Don't you think that this backtrace is more useful than just Segmentation fault? Perhaps I misunderstood, but I thought the purpose of the patch was to let developers act more quickly on bug reports. I wonder if this output really speeds up the process. The fault handler helps developers because they don't have to have a Python compiled in debug mode and to run the application in a debugger (like gdb). If the developer is unable to reproduce an error, because it's an Heisenbug, or because the developer doesn't have the same OS, libraries and/or applications, the fault handler helps the developer to isolate the problem. This is what I'm sceptical about. I think the tracebacks are don't carry enough information for that. Any bug report which only contain Segmentation fault information. But I cannot give you a revelant example because users are too shy to report an issue if they don't have more information than just the program crashed. With a fault handler displaying the Python backtrace, I hope that more *users* will report bugs. I wonder. It would be fine to make the tracebacks optional and tell the user to rerun the program with the proper environment variable set. I did use version 10. I've verified the same behavior with a fresh py3k checkout and this patch: (...) My machine currently has a load average of 2. Perhaps you'll be able to reproduce it if you crank up the load average. What is your OS (name, version)? I only tested crashers on Linux (Debian Sid). Ubuntu 8.10, 64-bit, real hardware. I also tested on FreeBSD-8.0-qemu: $ ./python Lib/test/crashers/compiler_recursion.py Illegal instruction: 4 (core dumped) $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] Stefan Krah ___ 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] sqlite, DDL, and transactions
On Mon, Dec 20, 2010 at 10:48, Scott Urban scott.ur...@isilon.com wrote: Hi The python sqlite module automatically commits open transactions when it encounters a DDL statement. This is unnecessary; DDL is transaction in my testing (see attached). Attached patch addresses the issue. Patch is against 2.6.1, but looking at Trunk in svn, it seems like the patch is needed and would apply. One issue I could foresee is that this behavior might depend on the sqlite version in use (I'm on 3.6.10). Thanks Scott Can you submit this to bugs.python.org? Bug reports and their patches on the mailing list tend to get lost. Additionally, 2.7 would be the 2.x version to fix this against (branches/release27-maint when looking in svn). ___ 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] sqlite, DDL, and transactions
On 20/12/2010 16:48, Scott Urban wrote: Hi The python sqlite module automatically commits open transactions when it encounters a DDL statement. This is unnecessary; DDL is transaction in my testing (see attached). Hello Scott, Please post your patch to the Python bug tracker. http://bugs.python.org/ All the best, Michael Foord Attached patch addresses the issue. Patch is against 2.6.1, but looking at Trunk in svn, it seems like the patch is needed and would apply. One issue I could foresee is that this behavior might depend on the sqlite version in use (I'm on 3.6.10). Thanks Scott ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessinghttp://www.sqlite.org/different.html ___ 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 Mon, Dec 20, 2010 at 11:56 AM, Stefan Krah ste...@bytereef.org wrote: Victor Stinner vstin...@edenwall.com wrote: .. The fault handler helps developers because they don't have to have a Python compiled in debug mode and to run the application in a debugger (like gdb). If the developer is unable to reproduce an error, because it's an Heisenbug, or because the developer doesn't have the same OS, libraries and/or applications, the fault handler helps the developer to isolate the problem. This is what I'm sceptical about. I think the tracebacks are don't carry enough information for that. My concern is that the traceback generated by a signal handler may actually contain *less* information that what would otherwise be available from the core dump or other system diagnostic facilities. Whenever you continue to execute code after a fault occurs (even in an alternative stack), you change register values and run the risk that the program will not be able to produce a core dump at all or will produce a core dump with misleading information in it. I think Stefan's approach is the correct one: before we agree on this feature, the proponents should present actual crashers for which reports generated by the patch are actually helpful. ___ 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 20/12/2010, Michael Foord fuzzy...@voidspace.org.uk wrote: On 19/12/2010 23:02, Victor Stinner wrote: I don't think that kill() is available on Windows. Can just use raise instead. But, is any of this change valid on Windows? http://msdn.microsoft.com/library/xdkz3x12 The SIGILL, SIGSEGV, and SIGTERM signals are not generated under Windows NT. They are included for ANSI compatibility. And the last signal this concerns is explicitly skipped in the tests on the latest patch under windows with the note SIGFPE cannot be catched on Windows. Signals are a posix compatibility hack on win32, they're unlikely to do what you want. Thanks to Brian Curtin there is now an os.kill() on Windows, but it doesn't handle the full range of signals. Which uses GenerateConsoleCtrlEvent and is completely the wrong thing. 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 PYTHONNOFAUL THANDLER environment variable
Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit : Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] Oh, I understood. I always test with Python compiled using --with-pydebug. With pydebug, a segfault occurs. Without pydebug, there is an unlimited loop. The patch is not related to the lack of segfault :-) (Retry without the patch) 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] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable
Le lundi 20 décembre 2010 18:22:48, Alexander Belopolsky a écrit : On Mon, Dec 20, 2010 at 11:56 AM, Stefan Krah ste...@bytereef.org wrote: Victor Stinner vstin...@edenwall.com wrote: .. The fault handler helps developers because they don't have to have a Python compiled in debug mode and to run the application in a debugger (like gdb). If the developer is unable to reproduce an error, because it's an Heisenbug, or because the developer doesn't have the same OS, libraries and/or applications, the fault handler helps the developer to isolate the problem. This is what I'm sceptical about. I think the tracebacks are don't carry enough information for that. Yes, in some cases the backtrace doesn't help. But why don't you want to display the backtrace if it can help in some other cases? My concern is that the traceback generated by a signal handler may actually contain *less* information that what would otherwise be available from the core dump or other system diagnostic facilities. I changed my patch to call the previous signal handler starting at version 10. So the core dump function or OS fault handler will be called two. Said differently, it only gives *more* information, not less. If you have a better OS fault handler than Python fault handler, you should disable Python fault handler by setting the environment variable. Whenever you continue to execute code after a fault occurs (even in an alternative stack), you change register values and run the risk that the program will not be able to produce a core dump at all or will produce a core dump with misleading information in it. Are you sure that a signal handler changes the registers? At least Linux saves integer and float registers before calling the signal handler, and then restores them. The fault handler only changes some registers and write some bytes on the stack. The stack pointer is restored at exit, so I don't think that it causes troubles to use a core dump. Dump a core file doesn't rely on process registers or mappings. Why do you think that it will break the core dump function? 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] sqlite, DDL, and transactions
On Mon, Dec 20, 2010 at 17:03:51, Michael Foord sent: On 20/12/2010 16:48, Scott Urban wrote: Hi The python sqlite module automatically commits open transactions when it encounters a DDL statement. This is unnecessary; DDL is transaction in my testing (see attached). Hello Scott, Please post your patch to the Python bug tracker. http://bugs.python.org/ http://bugs.python.org/issue10740 Thanks Scott ___ 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 Mon, Dec 20, 2010 at 12:51 PM, Victor Stinner vstin...@edenwall.com wrote: .. Are you sure that a signal handler changes the registers? At least Linux saves integer and float registers before calling the signal handler, and then restores them. What if the program crashes (again) in the signal handler before having a chance to restore registers? Also, can you point to documentation that describes register restoring behavior? I am not sure all registers are (or even can be) restored. The fault handler only changes some registers and write some bytes on the stack. The stack pointer is restored at exit, so I don't think that it causes troubles to use a core dump. Dump a core file doesn't rely on process registers or mappings. Why do you think that it will break the core dump function? Because I had actual experience with that using R. Your code may be better, but R brings up a dialog on segfault asking whether to produce a core dump. Occasionally, that core dump would be completely unusable because it would point to an unrelated point in the code. I don't have a specific case handy because long ago I disabled segfault handlers in the local R installation. (I actually use RPy which loads R into Python as a shared library, so the two handlers will conflict anyways.) ___ 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 Mon, 20 Dec 2010 15:55:57 +0100, Stefan Krah ste...@bytereef.org wrote: Victor Stinner vstin...@edenwall.com wrote: Stefan Krah wrote: I think the output is not particularly informative: $ ./python Lib/test/crashers/gc_inspection.py (object object at 0x7f01827ad870, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) Fatal Python error: Segmentation fault Traceback (most recent call first): File Lib/test/crashers/gc_inspection.py, line 29 in g File Lib/test/crashers/gc_inspection.py, line 32 in module Segmentation fault Segmentation fault The backtrace is valid. Don't you think that this backtrace is more useful than just Segmentation fault? Perhaps I misunderstood, but I thought the purpose of the patch was to let developers act more quickly on bug reports. I wonder if this output really speeds up the process. Do you have an example bug where this patch helps in finding the precise location of a segfault? How is 'line 29 in g' not more precise than 'Segmentation fault'? Now imagine that this error is being produced from a 20,000 line application program bundle... -- R. David Murray www.bitdance.com ___ 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
Victor Stinner vstin...@edenwall.com wrote: Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit : Another test is hanging indefinitely (Ubuntu 64-bit): $ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output] Oh, I understood. I always test with Python compiled using --with-pydebug. With pydebug, a segfault occurs. Without pydebug, there is an unlimited loop. I'll open a feature request for more reliable segfaults. ;) Still, on FreeBSD-8.0 the patch does not produce a traceback and also appears to change the signal: [without the patch] $ ./python Lib/test/crashers/compiler_recursion.py Segmentation fault: 11 (core dumped) $ echo $? 139 [with the patch] $ ./python Lib/test/crashers/compiler_recursion.py Illegal instruction: 4 (core dumped) $ echo $? 132 Stefan Krah ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/20/2010 6:31 AM, Antoine Pitrou wrote: Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result. Which, again, they don't. Let's see: self.assertEqual(actual, expected) AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c - e + d The diff shows expected - actual, but it would be logical (in your own logic) to display actual - expected. The whole issue disappears if you drop this idea of naming the arguments actual and expected. I'm not a unittest user, although I probably will become one, in time, when I learn enough to contribute to Python, instead of just find bugs in it from use. I don't much care what the parameters names are, although the terms actual and expected seem good for testing scenarios if properly used, but the above does not match what I would expect the behavior to be from a testing scenario: run the test, and tell me what changed from the expected results. If the expected result (not parameter) is d and the actual result (not parameter) is e, the diff should show a b c - d + e Thinking-that-sometimes-a-novice's-expectations-are-relevant-to-such-discussions'ly yours, Glenn ___ 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Mon, Dec 20, 2010 at 1:55 AM, Steven D'Aprano st...@pearwood.info wrote: Antoine Pitrou wrote: For a non-native English speaker, 'a' and 'b' don't evoke 'after' and 'before' but simply the first two letters of the latin alphabet, and their ordering is therefore obvious with respect to function arguments. It's not just non-native English speakers either. I too think of a, b as being first, second rather than after, before. I was mostly being facetious (my main point being there's no perfect solution here), though I *have* seen serious code using the b=before/a=after convention. -- --Guido van Rossum (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] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable
Do you have an example bug where this patch helps in finding the precise location of a segfault? How is 'line 29 in g' not more precise than 'Segmentation fault'? I think Stefan is treating precise location as an absolute property, not a relative one. The precise location would be the very instruction causing the fault; this is something that a core dump provides, unless a signal handler interferes with that. In many crashes I fixed, the Python stack trace was irrelevant to understand the nature of the crash. Of course, there were also counter- examples where you'ld need the Python stack (or, rather, the entire interpreter trace) to understand how the crashing case can occur in the first place. 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
The GIL is likely held by a different thread, then. _PyThreadState_Current will point to the state of this other thread. I tested when the GIL released: the fault handler is unable to retrieve the thread state and so the backtrace is not printed. Which thread state should be retrieve? I don't know yet: maybe the last active thread state? It doesn't look trivial to fix this issue because if there is no thread (only the main thread), release the GIL clears the thread state pointer (to it to NULL) without storing it somewhere else (whereas with multiple threads, the last active thread is stored in gil_last_holder. I should ask Antoine (or someone one) how the new GIL works. I don't think this is possible to fix. Just put a sleep() call before the crash, and have a parallel thread perform a while-loop to see what I mean: it should give you a stack trace of the wrong thread, possibly touching transient objects which go away while you inspect them. Another variable might be created to store the (pointer to the) last active thread state. Please understand: the last active thread may not be the one that got the signal. Instead, it may be another thread that keeps running while your thread crashes. 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
[Python-Dev] Search-friendly shortcuts for Windows?
Something I noticed after installing the 3.2 beta on my Windows 7 laptop is that the start menu shortcuts aren't particularly search friendly. Searching loses the heirarchical information, so attempting to directly locate pyt provides two separate Python Command Line shortcuts, with no indicator as to which one will start which version. Given the changing dynamics of the desktop launch menus to better support direct access as an alternative to hierarchical navigation, would it be reasonable to consider including the major version number in the start menu shortcut names? (Question is mainly for Martin, obviously, but I'm also curious if anyone else has encountered the same thing) Regards, 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou solip...@pitrou.net wrote: Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result. Which, again, they don't. Let's see: self.assertEqual(actual, expected) AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c - e + d The diff shows expected - actual, but it would be logical (in your own logic) to display actual - expected. The whole issue disappears if you drop this idea of naming the arguments actual and expected. To make this a bit clearer... class Ex(ut.TestCase): ... def demo(self): ... self.assertEqual(actual, expected) ... Ex(demo).demo() Traceback (most recent call last): snip TB details AssertionError: 'actual' != 'expected' - actual + expected For the actual/expected terminology the diff is the wrong way around (as of 3.2b1, anyway). My own +1 goes to keeping the actual/expected terminology (and ordering) and adjusting the diffs accordingly (with a header noting that the diff is old=expected, new=actual). assertRaises() *is* an exception to the general actual/expected pattern, but that asymmetry is forced by the ability to pass arbitrary positional arguments to the function being tested (which later proved useful for the context manager form as well). 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] Search-friendly shortcuts for Windows?
On 12/20/2010 8:38 PM, Nick Coghlan wrote: Given the changing dynamics of the desktop launch menus to better support direct access as an alternative to hierarchical navigation, would it be reasonable to consider including the major version number in the start menu shortcut names? I would very much like that. I once changed some the entries but bugfix or later alpha/beta/gamma/final installation reset everything. (Question is mainly for Martin, obviously, but I'm also curious if anyone else has encountered the same thing) Now that I have multiple versions of Python installed (for development testing), I have *three* identical 'IDLE (Python GUI)' entries in the left-hand frequently-used programs column of the Start panel. This is really useless and therefore a waste of space. -- Terry Jan Reedy ___ 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] Search-friendly shortcuts for Windows?
On 12/20/2010 8:38 PM, Nick Coghlan wrote: would it be reasonable to consider including the major version number in the start menu shortcut names? +1 First thing I did was add an x.y prefix to the Python shortcuts. There are a lot of application shortcuts on my Win7 system that have version numbers that have no naming conflicts, so even if a single version of Python was installed, it would not look out of place at all. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Search-friendly shortcuts for Windows?
Given the changing dynamics of the desktop launch menus to better support direct access as an alternative to hierarchical navigation, would it be reasonable to consider including the major version number in the start menu shortcut names? (Question is mainly for Martin, obviously, but I'm also curious if anyone else has encountered the same thing) I can't see anything wrong with that, but I'm terrible with wording. So somebody would have to spell out the exact wording that each of the start menu items should have. In doing so, also take into consideration that some people install 32-bit and 64-bit versions simultaneously. 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
