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

[Vinay Sajip]

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.__stderr__ being the backup)?

> StreamHandler can take ownership of an arbitrary stream (say, created
> by the caller) passed to it, but assuming ownership of a
> standard stream, that are free to be overridden by a library (such as
> py.test), is rather bizarre.

Actually, it's not bizarre at all. Are you saying it's OK for multiple
threads in a program to write to sys.stderr, whenever they want, without
restriction, even if the end result is end-user visible output which is
gibberish (for example data from two logical streams interspersed
randomly)? Just because it's a "standard" stream? 

Also, perhaps you haven't noticed that StreamHandler has no way of
knowing whether the stream it was passed was a standard stream or not.
Logging may make certain hasattr-type checks e.g. for presence of
"flush" or "close", but it can't expect to not have ownership of the
stream, even for a standard stream.

I advise you to do the following: refactor your test cases to include
the explicit handler-adding code in your setup (instead of basicConfig),
and the handler-removing and closing code in your teardown.

def setUp(self):
  self.hdlr = logging.StreamHandler(stream)
  someLogger.addHandler(h)

def tearDown(self):
someLogger.removeHandler(self.hdlr)
self.hdlr.close()

where I have given someLogger module scope in the above snippet, you may
of course make it a testcase attribute too.

No changes to py.test are required. What happens if you do this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

Changes by Vinay Sajip :


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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.__stderr__ being the backup)?

> StreamHandler can take ownership of an arbitrary stream (say, created
> by the caller) passed to it, but assuming ownership of a
> standard stream, that are free to be overridden by a library (such as
> py.test), is rather bizarre.

Actually, it's not bizarre at all. Are you saying it's OK for multiple
threads in a program to write to sys.stderr, whenever they want, without
restriction, even if the end result is end-user visible output which is
gibberish (for example data from two logical streams interspersed
randomly)? Just because it's a "standard" stream? 

Also, perhaps you haven't noticed that StreamHandler has no way of
knowing whether the stream it was passed was a standard stream or not.
Logging may make certain hasattr-type checks e.g. for presence of
"flush" or "close", but it can't expect to not have ownership of the
stream, even for a standard stream.

I advise you to do the following: refactor your test cases to include
the explicit handler-adding code in your setup (instead of basicConfig),
and the handler-removing and closing code in your teardown.

def setUp(self):
  self.hdlr = logging.StreamHandler(stream)
  someLogger.addHandler(h)

def tearDown(self):
someLogger.removeHandler(self.hdlr)
self.hdlr.close()

where I have given someLogger module scope in the above snippet, you may
of course make it a testcase attribute too. I've used a unittest-style
of setUp/tearDown, I assume py.test is similar.

No changes to py.test are required. What happens if you do this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6453] Improve bool TypeError message

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2751] Regression for executing packages

[Nick Coghlan]

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 between packages and modules matters is that
the import system has to do more bookkeeping for packages (since they
can contain modules and subpackages). Direct execution of packages was
meant to be disallowed because the Python 2.5 accident means the
__init__ module runs without that extra bookkeeping having been set up
properly, which can lead to a broken import system. Unfortunately, the
relevant error message was lost for 2.5 in a refactoring that merged
duplicated code from a couple of different parts of the standard library.

I added Barry to the nosy list as the 2.6 release manager. I'm reluctant
to re-enable a known-broken behaviour at all, but if Barry thinks it
would be worthwhile downgrading this to a DeprecationWarning rather than
an outright error in the next 2.6 maintenance then I would be willing to
do that. That would still leave you with people getting a warning
though, so I don't think it would be that much of a gain in practice.

--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Applied in r73921 in trunk, and propagated in branches.

Thanks !

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6377] distutils compiler switch ignored

[Tarek Ziadé]

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 in 2.6 for this: 

http://nightly.ziade.org/

By the time 2.7 comes out, I'll probably publish an official standalone
version for 2.6 as Marc André suggested in the past.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6377] distutils compiler switch ignored

[Tarek Ziadé]

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 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 as basis for
> creating the .compiler instance, or even better refactor the
> various commands to use a central method on the build
> command object to create a compiler object and avoid all
> the copy&paste code for this.
> Furthermore, the .finalize_options() methods could detect whether
> a per-command option as used and deprecate this use instead,
> redirecting to the build command option.

Having a single location sounds like the best idea with the current
behavior, reachable from cmd.get_compiler_object() like you did.

Now the question is, in practice, could someone force a
different compiler in build_ext for instance, or with a different
configuration than in build_clib ?

I don't see a use case in practice for that, but if so, we would need to
keep a different compiler instance per command.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[dauerbaustelle]

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
>>> locale.T_FMT
131114
>>> locale.T_FMT_AMPM
131115

It seems like the .DAY_* stuff is also broken:
>>> locale.DAY_1
131079
>>> locale.DAY_2
131080
>>> locale.DAY_7
131085

And many other variables:
>>> locale.THOUSEP
65537

The documentation says that every of these variables should be strings.

Regards,
db

[1]http://docs.python.org/library/locale.html#locale.D_T_FMT

--
components: Library (Lib)
messages: 90384
nosy: dauerbaustelle
severity: normal
status: open
title: locale.D_* and .T_* are int, not string
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6377] distutils compiler switch ignored

[Marc-Andre Lemburg]

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 as basis for
>> creating the .compiler instance, or even better refactor the
>> various commands to use a central method on the build
>> command object to create a compiler object and avoid all
>> the copy&paste code for this.
>> Furthermore, the .finalize_options() methods could detect whether
>> a per-command option as used and deprecate this use instead,
>> redirecting to the build command option.
> 
> Having a single location sounds like the best idea with the current
> behavior, reachable from cmd.get_compiler_object() like you did.
> 
> Now the question is, in practice, could someone force a
> different compiler in build_ext for instance, or with a different
> configuration than in build_clib ?
> 
> I don't see a use case in practice for that, but if so, we would need to
> keep a different compiler instance per command.

It is generally a bad idea to mix compiler types when compiling
Python extensions and usually doesn't work unless you are
very careful.

In practice, I don't think that any extension package will use
more than one compiler type for the various build parts.

However, it is well possible that a package may use differently
setup compiler instances on various commands, e.g. to point
it to different libraries, dirs, etc., so having just
one such instance on e.g. the top-level build command object
would not work out.

In fact, a single command object may even use multiple compiler
instances to e.g. build different C libs or extensions using
different sets of include and library search dirs.

I think a workable solution to the problem with the compiler
option would be to remove the option from the build_ext,
build_clib and config commands (plus any others, if there are
more) and only allow it on the build command.

The build.get_compiler_object() could then return an instance
of the chosen compiler type and the command object would then
store it in .compiler.

The various .finalize_options() method would need to propagate
any used "compiler" option back to the build command and reset
the .compiler attribute to None.

You'd still have the situation that .compiler is used as
option string and then as compiler instance, but only for
the short phase between .initialize_options() and
.finalize_options() which is not all that much of a problem
(you cannot make any use of non-finalized command objects
anyway).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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 bit confusing, but
the fact that it says "return" instead of saying that it is _is_ a
string should be a clue that the item itself is not a string. 

A doc patch would certainly be considered if you see a way to make it
more obvious.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[dauerbaustelle]

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

Regards

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[holger krekel]

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-setup method, i
am afraid.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dariusz Walczak]

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).
2) Process B exits very early (doesn't process all stdin data) and puts
large amount of data into its stderr or stdout streams.
3) IOError/OSError exception if errno variable set to errno.EPIPE is
raised on process A side.

Bug:
When the exception is catched Popen object's stdout and stderr members
may not contain data put into stderr/stdout streams by process B.

Note:
Described behaviour can be observed in Python 2.6.1 on FreeBSD 7.2 as
well as on Windows XP (Pro x64, SP2, up to date).

Real life example of such early end of process B:
openssl smime -verify -CApath /some/dir with large, unsigned email.

I attach simple reproduction code (execute sender.py script).

--
components: Library (Lib)
files: subprocess.Popen.communicate_problem_reproduction.zip
messages: 90391
nosy: dwalczak
severity: normal
status: open
title: subprocess.Popen.communicate can lose data from output/error streams 
when broken input pipe occures
type: behavior
versions: Python 2.6
Added file: 
http://bugs.python.org/file14482/subprocess.Popen.communicate_problem_reproduction.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Sean]

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.getLogger('x.y.z')
l2.setLevel(logging.INFO)
print len(l2.handlers)

l2.critical('critical')
l2.error('error')
l2.warning('warning')
l2.info('info')
l2.debug('debug')

Note, the l2(x.y.z) logger does not have a handler (it just propagates
to the l(root) logger's handler) but the l2 logger does have a different
level set.

When I try to do this with logging.config.fileConfig it fails saying I
have not specified a handler for the x.y.z logger.  But I don't want to
specify a handler, I just want to set the level and have it propagate up
the hierarchy.

Am I doing something wrong?

Sean.

P.S. Here is the config file:

[loggers]
keys=root,xyz

[handlers]
keys=consoleStderr

[formatters]
keys=simpleFormatter

[logger_root]
level=NOTSET
handlers=consoleStderr

[logger_xyz]
level=DEBUG
qualname=x.y.z

[handler_consoleStderr]
class=StreamHandler
level=NOTSET
formatter=simpleFormatter
args=(sys.stderr,)

[formatter_simpleFormatter]
%(levelname)s: %(name)s: %(message)s

--
messages: 90392
nosy: sean
severity: normal
status: open
title: With logging.config.fileConfig can't create logger without handler
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Sean]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

applied with r73930. thanks for the patch!

--
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6410] Dictionaries should support __add__

[Terry J. Reedy]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6453] Improve bool TypeError message

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6453] Improve bool TypeError message

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Must have been random glitch. I certainly did not change state and priority.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Hirokazu Yamamoto]

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
   Library c:\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\Debug\docume~1
\whiter~1\l
ocals~1\temp\tmpbj3fb0\xx_d.lib とｵﾌﾞｼﾞｪｸﾄ c:\docume~1\whiter~1\locals~1
\temp\tm
pbj3fb0\Debug\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\xx_d.exp is now 
being created
ok
test_check_extensions_list (__main__.BuildExtTestCase) ... ok
test_compiler_deprecation_warning (__main__.BuildExtTestCase) ... ok
test_compiler_option (__main__.BuildExtTestCase) ... ok
test_ext_fullpath (__main__.BuildExtTestCase) ... ok
test_finalize_options (__main__.BuildExtTestCase) ... ok
test_get_outputs (__main__.BuildExtTestCase) ... foo.c
LINK : error LNK2001: External symbol "PyInit_foo" is not resolved
c:\docume~1\whiter~1\locals~1\temp\tmp1bfgxq\tempt\docume~1\whiter~1
\locals~1\te
mp\tmpnttk0b\foo_d.lib : fatal error LNK1120: External symbol 1 is not 
resolved
LINK : fatal error LNK1141: Got trouble in building export file
ERROR
test_get_source_files (__main__.BuildExtTestCase) ... ok
test_optional_extension (__main__.BuildExtTestCase) ... ok
test_solaris_enable_shared (__main__.BuildExtTestCase) ... ok
test_user_site (__main__.BuildExtTestCase) ... ok

==
ERROR: test_get_outputs (__main__.BuildExtTestCase)
--
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 524, in 
link
self.spawn([self.linker] + ld_args)
  File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 981, in 
spawn
spawn(cmd, dry_run=self.dry_run)
  File "e:\python-dev\py3k\lib\distutils\spawn.py", line 36, in spawn
_spawn_nt(cmd, search_path, dry_run=dry_run)
  File "e:\python-dev\py3k\lib\distutils\spawn.py", line 77, in 
_spawn_nt
"command '%s' failed with exit status %d" % (cmd[0], rc))
distutils.errors.DistutilsExecError: command '"C:\Program 
Files\Microsoft Visual
 Studio\VC98\BIN\link.exe"' failed with exit status 1141

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib\distutils\tests\test_build_ext.py", line 323, in 
test_get_outputs
cmd.run()
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
394, in run

self.build_extensions()
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
503, in bui
ld_extensions
self.build_extension(ext)
  File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line 
590, in bui
ld_extension
target_lang=language)
  File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 791, in 
link_shared
_object
extra_preargs, extra_postargs, build_temp, target_lang)
  File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 526, in 
link
raise LinkError(msg)
distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual 
Studio\V
C98\BIN\link.exe"' failed with exit status 1141

--
Ran 11 tests in 1826.566s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib\distutils\tests\test_build_ext.py", line 432, in 

--
assignee: tarek
components: Distutils, Windows
files: fix_distutils_test.patch
keywords: patch
messages: 90400
nosy: ocean-city, tarek
severity: normal
status: open
title: Lib/distutils\tests\test_build_ext.py fails on VC6
versions: Python 3.2
Added file: http://bugs.python.org/file14483/fix_distutils_test.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6453] Improve bool TypeError message

[R. David Murray]

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 refreshed the page in an odd
order and reset some fields I wasn't intending to reset.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6460] test failure in test_xmlrpc on Gentoo in trunk

[R. David Murray]

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 tad bit of extra tracing in
(printing the contents of myRequests to stderr) and this is what I see:

rdmur...@partner:~/python/trunk>./python -m test.regrtest test_xmlrpc
Could not find '/home/rdmurray/python/trunk/Lib/test' in sys.path to
remove it
test_xmlrpc
[['POST /RPC2 HTTP/1.1\r\n']]
test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_xmlrpc.py", line 550,
in test_two
self.assertGreaterEqual(len(self.RequestHandler.myRequests[-1]), 2)
AssertionError: 1 not greater than or equal to 2

1 test failed:
test_xmlrpc

The test appears to hit a time out.

If there are any tests you want me to run let me know.  Oddly enough I'm
not seeing this one on 3.2.

--
assignee: krisvale
components: Library (Lib), Tests
messages: 90402
nosy: krisvale, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test failure in test_xmlrpc on Gentoo in trunk
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6453] Improve bool TypeError message

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6460] test failure in test_xmlrpc on Gentoo in trunk

[Ned Deily]

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.framework/Versions/3.2/lib/python3.2/test/te
st_xmlrpc.py", line 514, in test_two
self.assertTrue(len(self.RequestHandler.myRequests[-1]) >= 2)
AssertionError: False is not True

--
nosy: +nad

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6461] multiprocessing: freezing apps on Windows

[Stuart Mentzer]

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']
else:
prog = 'from multiprocessing.forking import main; main()'
return [_python_exe, '-c', prog, '--multiprocessing-fork']

should be:

elif getattr(sys, 'frozen', False) and not WINEXE:
return [sys.executable, '--multiprocessing-fork']
else:
prog = 'from multiprocessing.forking import main; main()'
return [_python_exe, '-c', prog, '--multiprocessing-fork']

in order for the _python_exe set with multiprocessing.set_executable to
be used rather than your app's exe.

Second, I can then get a working "frozen" package if I include
pythonw.exe (and use set_executable to point to it) and a subset of
Python's Lib directory that my process needs to call. If this is as
intended then it needs to be documented. This may just be a flaw in py2exe.

Third, the multiprocessing documentation page description for
set_executable has example code with the older setExecutable call.

--
components: Library (Lib)
messages: 90405
nosy: sgm
severity: normal
status: open
title: multiprocessing: freezing apps on Windows
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com