[issue6461] multiprocessing: freezing apps on Windows

New submission from Stuart Mentzer : Freezing apps with multiprocessing on Windows seems to be broken. First, in get_command_line in multiprocessing/forking.py I find that this code: if getattr(sys, 'frozen', False): return [sys.executable, '--multiprocessing-fork']

[issue6460] test failure in test_xmlrpc on Gentoo in trunk

Ned Deily added the comment: FWIW, I've just seen a couple of intermittent 'test_two' failures with a current py3k on OS X but, in each case, the test passed when auto rerun in verbose mode. test test_xmlrpc failed -- Traceback (most recent call last): File "/Library/Frameworks/Python.fram

[issue6453] Improve bool TypeError message

Terry J. Reedy added the comment: yes, I was trying to avoid bothering you with the noise. This is one of those 'everything gone wrong' situations. If only I had unselected 'open only' when I did the search... -- ___ Python tracker

[issue6460] test failure in test_xmlrpc on Gentoo in trunk

New submission from R. David Murray : Another apparent fallout from r73638 (issue 6267). On my gentoo system I am currently seeing a consistent failure in test_xmlrpc of 'test_two' in KeepaliveServerTestCase (as is the Gentoo buildbot). I made the assert the new GreaterEqual and stuck just a ta

[issue6453] Improve bool TypeError message

R. David Murray added the comment: On your test post I got deleted from the nosy list. Was that intentional? I wonder if your browser is doing something weird with the form field settings. Or it may have as you say been a random thing...I know that has happened to me once or twice where I ref

[issue6459] Lib/distutils\tests\test_build_ext.py fails on VC6

New submission from Hirokazu Yamamoto : I got distutils error on Lib/distutils\tests\test_build_ext.py. I hope attached file will fix this issue. (This should complete r64127) E:\python-dev\py3k>py3k Lib\distutils\tests\test_build_ext.py test_build_ext (__main__.BuildExtTestCase) ... xxmodule.c

[issue6453] Improve bool TypeError message

Terry J. Reedy added the comment: Must have been random glitch. I certainly did not change state and priority. -- ___ Python tracker ___ _

[issue6453] Improve bool TypeError message

Terry J. Reedy added the comment: Testing. I am 99.9% sure *I* did not reopen. Testing to see if OP post auto-reopens. -- nosy: -r.david.murray ___ Python tracker ___ __

[issue6410] Dictionaries should support __add__

Terry J. Reedy added the comment: > what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}? > Should it be {"a": 1, "b": 2} or {"a": 2, "b": 1}? or {"a":[1,2], "b":[1,2]} As I remember, Guido rejected because of this ambiguity. -- nosy: +tjreedy __

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

R. David Murray added the comment: I was unable to reproduce this using the suggested regrtest pair, even if I ran -R ::, on Gentoo, kernel 2.6.30, with nptl. -- priority: -> normal ___ Python tracker

[issue6456] locale.D_* and .T_* are int, not string

R. David Murray added the comment: They can't be static string constants because they aren't constants. They depend on the current locale settings. I'm reopening this as a doc bug. -- assignee: -> georg.brandl components: +Documentation -Library (Lib) nosy: +georg.brandl resolution:

[issue6447] PATCH: typo (English) in subprocess module

Amaury Forgeot d'Arc added the comment: applied with r73930. thanks for the patch! -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed ___ Python tracker __

[issue6458] With logging.config.fileConfig can't create logger without handler

Sean added the comment: there is a missing "format=" on the last line of my config file. Doesn't change the stated problem though. -- ___ Python tracker ___ _

[issue6458] With logging.config.fileConfig can't create logger without handler

New submission from Sean : Using "logging" module I can do the following: f = logging.Formatter("%(levelname)s: %(name)s: %(message)s") h = logging.StreamHandler() h.setLevel(logging.NOTSET) h.setFormatter(f) l = logging.getLogger() l.addHandler(h) l2 = logging.getLo

[issue6457] subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures

New submission from Dariusz Walczak : It's possible to lose data piped through standard output and/or error streams when large ammounts of data are transfered. Reproduction: 1) Process A spawns process B with all standard I/O pipes and transfers large ammount of data to it (100kB in my sample).

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Mark Dickinson added the comment: It would also be interesting to know whether Neal's system is using the LinuxThreads library, or whether it's using NPTL. If it's the former, it might go some way to explaining the problem. -- ___ Python tracker

[issue6333] logging: ValueError: I/O operation on closed file

holger krekel added the comment: Actually py.test catches stdout separately for setup and for the test code. Moreover, functional or integration test code (py.test is not only for unittests) can easily trigger some implicit logging-module usage which cannot eaysily be factored into a testcase-s

[issue6456] locale.D_* and .T_* are int, not string

Amaury Forgeot d'Arc added the comment: The description of each of these constants could start like this: """ When passed to :func:`nl_langinfo`, return a string ... """ + the "Example:" paragraph should be moved in a more prominent place, near the top of the file for example. -- nosy:

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue6456] locale.D_* and .T_* are int, not string

dauerbaustelle added the comment: I would suggest to make those constants be strings. There's no need for those int values; in most cases, you want the strings and not the int values. Until then, I would put that nl_langinfo() stuff in a warning or info box (or highlight it somehow differently)

[issue6456] locale.D_* and .T_* are int, not string

R. David Murray added the comment: If you look a little further up in the page you will see: "The nl_langinfo() function accepts one of the following keys. Most descriptions are taken from the corresponding description in the GNU C library." I agree that the descriptions of the constants are a

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: >> The "compiler" option on the build_ext and config commands >> are not really needed. Their .finalize_options() methods could >> easily pull in the build option value and place it into >> an .compiler_type attribute which then gets used

[issue6456] locale.D_* and .T_* are int, not string

New submission from dauerbaustelle : The locale.D_* and locale.T_* attributes are ints with weird values instead of strings (see documentation[1]). Example: >>> import locale >>> locale.setlocale(locale.LC_ALL, 'en_US.utf8') 'en_US.utf8' >>> locale.D_T_FMT 131112 >>> locale.D_FMT 131113 >>> lo

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: > You never run a command twice unless you explicitly reinitialize it > (which then resets .compiler to None and then fetches the command line > option again), so the above is not a problem. In practice yes that's true. > The "compiler" option on the build_ext an

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: @Nicolas : That's because you run it with Python 2.6 distutils, which doesn't have that change. If you want to build the current trunk with Python 2.6, you may want to install a standalone version of distutils. I have a nightly build of the trunk you may install i

[issue6455] Lib/distutils/tests/test_build_ext.py fails on windows

Tarek Ziadé added the comment: Applied in r73921 in trunk, and propagated in branches. Thanks ! -- status: open -> closed ___ Python tracker ___

[issue2751] Regression for executing packages

Nick Coghlan added the comment: If you need to support Python 2.6 as well as 3.1, the simplest thing to do is just tell people to run "pygame.tests.main" always (i.e. completely skip the idea of executing the package directly and always run a submodule instead). The reason the distinction betwe

[issue6453] Improve bool TypeError message

Changes by Amaury Forgeot d'Arc : -- resolution: -> duplicate status: open -> closed ___ Python tracker ___ ___ Python-bugs-list maili

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Are you suggesting that the ownership of `sys.stderr` belongs to the > logging module once logging.basicConfig (that initializes a > StreamHandler with stderr) is called? > That no other module/library is to close sys.stderr even though they > created it (sys.__

[issue6333] logging: ValueError: I/O operation on closed file

Changes by Vinay Sajip : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/optio

[issue6333] logging: ValueError: I/O operation on closed file

Vinay Sajip added the comment: > Are you suggesting that the ownership of `sys.stderr` belongs to the > logging module once logging.basicConfig (that initializes a > StreamHandler with stderr) is called? > That no other module/library is to close sys.stderr even though they > created it (sys.__