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

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 n

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

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 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 s

[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 indicato

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 > r

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

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 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 argumen

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: se

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable

Victor Stinner 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-

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable

On Mon, 20 Dec 2010 15:55:57 +0100, Stefan Krah wrote: > Victor Stinner wrote: > > Stefan Krah wrote: > > > I think the output is not particularly informative: > > > > > > $ ./python Lib/test/crashers/gc_inspection.py > > > (, , , , , > > > , > > > , , , ) Fatal Python error: Segmentation fault

Re: [Python-Dev] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable

On Mon, Dec 20, 2010 at 12:51 PM, Victor Stinner 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

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). > > > > Hel

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 wrote: > > Victor Stinner 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

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 oc

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

On 20/12/2010, Michael Foord 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? "The SIGILL, SIGSEGV, and SIGTERM signals

Re: [Python-Dev] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable

On Mon, Dec 20, 2010 at 11:56 AM, Stefan Krah wrote: > Victor Stinner 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, bec

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.p

Re: [Python-Dev] sqlite, DDL, and transactions

On Mon, Dec 20, 2010 at 10: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). > > Attached patch addresses the issue. Patch is against 2.6.1

Re: [Python-Dev] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable

Victor Stinner 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 developer

[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

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.melotti wrote: Author: ezio.melotti Date: Sat Dec 18 21:00:04 2010 New Revision: 87389 Log: #10573: use actual/expected consistently in unittest methods. Ch

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.

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable

Victor Stinner 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 > > (, , , , , , > > , , , ) Fatal Python error: Segmentation fault > > > > Traceback (most recent call

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 on

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 curre

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 > (, , , , , , > , , , ) Fatal Python error: Segmentation fault > > Traceback (most recent call first): > File "Lib/test/crashers/gc_

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 t

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

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 Pitrou wrote: On Sat, 18 Dec 2010 20:23:49 -0800 Guido van Rossum wrote: I may be unique, but I fear there is no great answer. On the one hand I almos

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

Stefan Krah 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

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

Alexander Belopolsky wrote: > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl 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

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

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