From report at bugs.python.org  Mon Mar  1 00:40:32 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sun, 28 Feb 2010 23:40:32 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

gdb 7 can be extended with Python code, allowing the writing of domain-specific pretty-printers and commands.  

I've been working on gdb 7 hooks to make it easier to debug python itself, as mentioned here:
https://fedoraproject.org/wiki/Features/EasierPythonDebugging


I'm attaching a patch for merger with "trunk".  My hope is to be the maintainer of this work, although I do not yet have SVN commit rights (see http://mail.python.org/pipermail/python-committers/2010-February/000711.html )

The code is fully compatible with the existing "Misc/gdbinit" macros - you can freely use both as needed.

= Two versions of Python =
This code is intended to run inside gdb.  There are potentially two Python versions involved here: that of the "inferior process" (the one being debugged), and that of the debugger.

As I understand things, gdb only supports embedding Python 2 at the moment.  This code is thus targeting that version of Python.

So far, I've attempted to keep this code so that it will run when the "inferior process" is either Python 2 or Python 3.  I could vary this code in the py3k branch if desired.  The code would then track the "inferior process" version of Python, so that code to debug Python 3 would live in the py3k branch.  That code would still be written for Python 2, though.

= Makefile changes =

The Makefile installs the gdb hooks to -gdb.py relative to the built python (even if you're not using them), which some may find irritating.  It needs to do this for the test_gdb.py selftest to work (and for the gdb hooks to be usable if you're actually using them to debug your build of Python).

Should I write a gdb configuration test to check for the availability of gdb built with python?

I've added the file to .hgignore and .bzrignore.  IIRC, a similar thing can be done to the SVN metadata (I don't think this is expressable as a patch, though).  Alternatively, I could wire up the gdb tests to load the file from its location in the source tree.

However, I intend for this code to be installed to a location alongside the build Python, so that it can be automatically detected and used by gdb.  Typically this means copying it to the path of the ELF file with a -gdb.py file.  In my RPM builds I add an extra copy, locating it relative to the location of the stripped DWARF data (e.g. /usr/lib/debug/usr/lib64/libpython26.so.1.0-gdb.py)

= Selftests =
The selftest runs whatever version of "gdb" is in the path, which then invokes the built version of python, running simple "print" commands and verifying that gdb is corrrectly representing the results in backtraces (even in the face of corrupt data).  I haven't fully tested the error cases yet (e.g. for when gdb is not installed).

The tests take about 14 seconds to run on my box:
[david at brick trunk-gdb]$ time ./python Lib/test/regrtest.py -v -s test_gdb
The CWD is now /tmp/test_python_19369
test_gdb
test_NULL_ob_type (test.test_gdb.DebuggerTests) ... ok
test_NULL_ptr (test.test_gdb.DebuggerTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_classic_class (test.test_gdb.DebuggerTests) ... ok
test_corrupt_ob_type (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_flags (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_name (test.test_gdb.DebuggerTests) ... ok
test_dicts (test.test_gdb.DebuggerTests) ... ok
test_getting_backtrace (test.test_gdb.DebuggerTests) ... ok
test_int (test.test_gdb.DebuggerTests) ... ok
test_lists (test.test_gdb.DebuggerTests) ... ok
test_long (test.test_gdb.DebuggerTests) ... ok
test_modern_class (test.test_gdb.DebuggerTests) ... ok
test_singletons (test.test_gdb.DebuggerTests) ... ok
test_strings (test.test_gdb.DebuggerTests) ... ok
test_subclassing_list (test.test_gdb.DebuggerTests) ... ok
test_subclassing_tuple (test.test_gdb.DebuggerTests)
This should exercise the negative tp_dictoffset code in the ... ok
test_tuples (test.test_gdb.DebuggerTests) ... ok
test_unicode (test.test_gdb.DebuggerTests) ... ok

----------------------------------------------------------------------
Ran 18 tests in 13.233s

OK
1 test OK.
[36833 refs]

real	0m13.599s
user	0m11.771s
sys	0m1.384s

= Platform support =
I don't have access to anything other than Linux, so I've no idea how well this stuff works on other platforms.  My testing so far has been on Fedora, though I've heard of successful usage of this on Debian.

= Legal stuff =

Earlier versions of this code were licensed under the LGPL 2.1
I'm relicensing the code to be "under the same license as Python itself", assuming that's legally OK.  Do I need to state that in the file header, or is that redundant?

I'm in the process of doing the PSF Contributor Agreement paperwork (as an individual); waiting to get my hands on a fax machine.  My employer, Red Hat, has agreed for me to retain copyright on all contributions I make to Python.

----------
components: Demos and Tools
messages: 100226
nosy: dmalcolm
severity: normal
status: open
title: Add gdb7 hooks to make it easier to debug Python
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Mon Mar  1 00:43:21 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sun, 28 Feb 2010 23:43:21 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267400601.05.0.202520784248.issue8032@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16403/add-gdb7-python-hooks-to-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Mon Mar  1 00:52:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Feb 2010 23:52:38 +0000
Subject: [issue8031] Can't get f2py to work at all
In-Reply-To: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>
Message-ID: <1267401158.02.0.27118482171.issue8031@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is a 3rd party package problem. Please ask the maintainers of it.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________

From report at bugs.python.org  Mon Mar  1 01:40:41 2010
From: report at bugs.python.org (Peter Jones)
Date: Mon, 01 Mar 2010 00:40:41 +0000
Subject: [issue8031] Can't get f2py to work at all
In-Reply-To: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>
Message-ID: <694570C513DA446095B8CDEEDA8D90B0@XPS630>


Peter Jones <pjones0 at hughes.net> added the comment:

I would like to recall this bug report. What happend was I went to the f2py 
web site and dowloaded the "latest" version and installed it over Pythoh 
x,y. So I uninstalled P x,y and resinstalled and the f2py works OK now. Some 
one should make it more clear in the documentation to not do what I did.

Peter.

----- Original Message ----- 
From: "Peter Jones" <report at bugs.python.org>
To: <pjones0 at hughes.net>
Sent: Sunday, February 28, 2010 2:45 PM
Subject: [issue8031] Can't get f2py to work at all

New submission from Peter Jones <pjones0 at hughes.net>:

I am user 11943. OS is Windows Vista Ultimate. I have followed the 
instructions on how to use f2py and get this error when I try it (is this a 
known bug? It appears that there is bug in f2py):

C:\Python26\Scripts>python f2py.py
Traceback (most recent call last):
  File "f2py.py", line 3, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
<module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
<module>
    import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
    as=b['args']
     ^
SyntaxError: invalid syntax

I have also tried the example to create a fortran module for python and get 
this error:

C:\Python26\Scripts>python 
f2py.py -c --fcompiler=gnu95 --compiler=mingw32 -lmsvcr71 -m cep cep.for

Traceback (most recent call last):
  File "f2py.py", line 3, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
<module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
<module>
    import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
    as=b['args']
     ^
SyntaxError: invalid syntax

Additionally I use the Lahey/Fujitsu 95 compiler. Do I just replace the 
gnu95 with lahey?
Also Is the msvrc71.dll file the correct one to use? I use MSVC VS 2009, 
which uses msvc90.dll. Should I use it instead?

----------
files: unnamed
messages: 100225
nosy: PeterJones
severity: normal
status: open
title: Can't get f2py to work at all
Added file: http://bugs.python.org/file16402/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________

From report at bugs.python.org  Mon Mar  1 01:56:45 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Mon, 01 Mar 2010 00:56:45 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267405005.49.0.909886387177.issue7242@psf.upfronthosting.co.za>


Greg Jednaszewski <jednaszewski at gmail.com> added the comment:

I tested the updated patch, and the new unit test passes on my Sol 8 sparc, but the test_threading test still hangs on my system.  However, given that the test is skipped on several platforms and it does work on more relevant versions of Solaris, it's probably OK.  It's possible that an OS bug is causing that particular hang.

Plus, the original patch fixed the 'real world' scenario I was running into, so I'd like to see it get into the release candidate if you're OK with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Mon Mar  1 02:03:46 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 01 Mar 2010 01:03:46 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1267405426.53.0.174632266739.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Thanks for your interest!  I'm actually still working on the
patch I posted, docs and a test suite, and I'll post something
soon.

Yes, you could just use b"".join() with sendmsg() (and get
slightly annoyed because it doesn't accept buffers ;) ).  I made
sendmsg() take multiple buffers because that's the way the system
call works, but also to match recvmsg_into(), which gives you the
convenience of being able to receive part of the message into a
bytearray and part into an array.array("i"), say, if that's how
the data is formatted.

As you might know, gather-write with sendmsg() can give a
performance benefit by letting the kernel assemble the message
while copying the data from userspace rather than having
userspace copy the data once to form the message and then having
the kernel copy it again when the system call is made.  I suppose
with Python you just need a larger message to see the benefit :)
Since it can read from buffers, though, socket.sendmsg() can pull
a large chunk of data straight out of an mmap object, say, and
attach headers from a bytes object without the mmapped data being
touched by Python at all (or even entering userspace, in this
case).

The patch is for 3.x, BTW - "y*" is valid there (and does take a
buffer).

As for a good reference, I haven't personally seen one.  There's
POSIX and RFC 3542, but they don't provide a huge amount of
detail.  Perhaps the (updated) W. Richard Stevens networking
books?  I've got the Stevens/Rago second edition of Advanced
Programming in the Unix Environment, which discusses FD and
credential passing with sendmsg/recvmsg, but not very well (it
misuses CMSG_LEN, for one thing).  The networking books were
updated by different people though, so perhaps they do better.

The question of whether to use CMSG_NXTHDR() to step to the next
header when constructing the buffer for sendmsg() is a bit murky,
in particular.  I've assumed that this is the way to do it since
the examples in RFC 3542 (and most of the code I've seen
generally) use CMSG_FIRSTHDR() to get the initial pointer, but
I've found that glibc's CMSG_NXTHDR() can (wrongly, I think)
return NULL if the buffer hasn't been zero-filled beforehand
(this causes segfaults with the patch I initially posted).

@Wim:

Yes, the rfc3542 module from that package looks as if it would be
usable with these patches - although it's Python 2-only, GPL-only
and looks unmaintained.  Those kind of ancillary data
constructors will actually be needed to make full portable use of
sendmsg() and recvmsg() for things like IPv6, SCTP, Linux's
socket error queues, etc.  The same goes for data for the
existing get/setsockopt() methods, in fact - the present
suggestion to use the struct module is pretty inadequate when
there are typedefs involved and implementations might add and
reorder fields, etc.

The objects in that package seem a bit overcomplicated, though,
messing about with setter methods instead of just subclassing
"bytes" and having different constructors to create the object
from individual arguments or received bytes (say, ucred(1, 2, 3)
or ucred.from_bytes(...)).

Maybe the problem of testing patches well has been putting people
off so far?  Really exercising the system's CMSG_*HDR() macros in
particular isn't entirely straightforward.  I suppose there's
also a reluctance to write tests while still uncertain about how
to present the interface - that's another reason why I went for
the most general multiple-buffer form of sendmsg()!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Mar  1 02:55:29 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Mar 2010 01:55:29 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1267408529.12.0.73617592325.issue3892@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r.david.murray - sounds like a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Mon Mar  1 03:03:11 2010
From: report at bugs.python.org (Fred Fettinger)
Date: Mon, 01 Mar 2010 02:03:11 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>


New submission from Fred Fettinger <fettinge at gmail.com>:

Handling of long integers is broken for arguments to sqlite functions created with the create_function api. Integers passed to a sqlite function are always converted to int instead of long, which produces an incorrect value for integers outside the range of a int32 on a 32 bit machine. These failures cannot be reproduced on a 64 bit machine, since sizeof(long) == sizeof(long long).

I attached a program that demonstrates the failure. This program reports failures on a 32 bit machine, and all tests pass on a 64 bit machine.

----------
components: Library (Lib)
files: sqlite_long_test.py
messages: 100235
nosy: BinaryMan32
severity: normal
status: open
title: sqlite: broken long integer handling for arguments to user-defined functions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16404/sqlite_long_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Mon Mar  1 03:22:19 2010
From: report at bugs.python.org (Fred Fettinger)
Date: Mon, 01 Mar 2010 02:22:19 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1267410139.17.0.934416418103.issue8033@psf.upfronthosting.co.za>


Fred Fettinger <fettinge at gmail.com> added the comment:

I've never really looked at the python source before, but this is my best guess at the problem:

For the standard SELECT query:
In Modules/_sqlite/cursor.c, _pysqlite_fetch_one_row() has this code:
PY_LONG_LONG intval;
...
} else if (coltype == SQLITE_INTEGER) {
    intval = sqlite3_column_int64(self->statement->st, i);
    if (intval < INT32_MIN || intval > INT32_MAX) {
        converted = PyLong_FromLongLong(intval);
    } else {
        converted = PyInt_FromLong((long)intval);
    }
}

For user-defined function arguments:
In Modules/_sqlite/connection.c, _pysqlite_build_py_params() has this code:
PY_LONG_LONG val_int;
...
case SQLITE_INTEGER:
    val_int = sqlite3_value_int64(cur_value);
    cur_py_value = PyInt_FromLong((long)val_int);
    break;

A select query can return long integers from C to python but a user-defined function argument cannot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Mon Mar  1 03:58:34 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Mon, 01 Mar 2010 02:58:34 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1267412314.09.0.0723729940766.issue6729@psf.upfronthosting.co.za>


Ryan Coyner <rcoyner at gmail.com> added the comment:

You don't want to do c_size_t = c_void_p because that will prevent type checking. We want c_size_t to be integers; setting it to c_void_p will accept other values. The lines that define c_size_t are doing a sizeof check to determine how many bits the CPU supports, and c_size_t should represent unsigned integers [1].

On a 16-bit machine: c_size_t = c_uint
On a 32-bit machine: c_size_t = c_ulong
On a 64-bit machine: c_size_t = c_ulonglong

Now, ssize_t is like size_t, except that it is signed [2]. So if I am not mistaken, all we have to do is:

if sizeof(c_uint) == sizeof(c_void_p):
    c_size_t = c_uint
    c_ssize_t = c_int
elif sizeof(c_ulong) == sizeof(c_void_p):
    c_size_t = c_ulong
    c_ssize_t = c_long
elif sizeof(c_ulonglong) == sizeof(c_void_p):
    c_size_t = c_ulonglong
    c_ssize_t = c_longlong


Patch attached with documentation and unit test.


[1] - http://www.gnu.org/software/libc/manual/html_node/Important-Data-Types.html
[2] - http://www.gnu.org/software/libc/manual/html_node/I_002fO-Primitives.html

----------
keywords: +patch
nosy: +rcoyner
Added file: http://bugs.python.org/file16405/issue6729.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Mon Mar  1 04:12:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Mar 2010 03:12:55 +0000
Subject: [issue8031] Can't get f2py to work at all
In-Reply-To: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>
Message-ID: <1267413175.97.0.512449595883.issue8031@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

This is indeed a problem with f2py. Please tell its maintaines that they can?t name an object ?as? since it?s a reserved keyword in Python?2.6 and higher. Testing with 2.5 (previous stable version, released in 2006) would have shown it: <http://www.python.org/doc/2.5/whatsnew/pep-343.html> points to <http://www.python.org/dev/peps/pep-0343/> which tells in ?Transition Plan?:

    ?In Python 2.5, the new syntax will only be recognized if a future
    statement is present:

          from __future__ import with_statement

    This will make both 'with' and 'as' keywords.  Without the future
    statement, using 'with' or 'as' as an identifier will cause a
    Warning to be issued to stderr.

    In Python 2.6, the new syntax will always be recognized; 'with'
    and 'as' are always keywords.?

So we?ll close here, since it is a normal, documented behavior. The f2py people have to fix their code.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________

From report at bugs.python.org  Mon Mar  1 04:16:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Mar 2010 03:16:34 +0000
Subject: [issue8031] Can't get f2py to work at all
In-Reply-To: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>
Message-ID: <1267413394.97.0.130620871467.issue8031@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

While I?m thinking about this, is there a way to make the syntax error traceback more informative, i.e. adding ?'{}' is a reserved keyword? in such cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________

From report at bugs.python.org  Mon Mar  1 04:34:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Mar 2010 03:34:38 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1267414478.25.0.456310689331.issue7849@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"lazy" sounds like a bad name for that parameter. It makes me think of lazy evaluation, not error checking.

There's also the problem that check_py3k_warnings() will check all DeprecationWarnings, not only py3k-specific ones. We need a Py3kDeprecationWarning subclass.
Besides, there doesn't seem to be any point accepting positional arguments in check_py3k_warnings(). If you want a custom filter, just use check_warnings() instead.

----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Mon Mar  1 06:01:02 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Mar 2010 05:01:02 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267419662.21.0.52848942194.issue8032@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Mon Mar  1 06:09:40 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Mar 2010 05:09:40 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1267420180.11.0.872924418497.issue6926@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

In PC/pyconfig.h we #define Py_WINVER to _WIN32_WINNT_WIN2K  (0x500)  for 32bit builds.

I think we should update this to _WIN32_WINNT_WINXP  (0x501)  for all builds, not just 64bit.

Assigning to loewis as he does our windows release builds so likely knows what the ramifications of this would be.

----------
assignee:  -> loewis
nosy: +gregory.p.smith, loewis
priority:  -> high
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Mon Mar  1 07:47:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Mar 2010 06:47:10 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1267426030.07.0.012833564807.issue6926@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Bumping the API level to XP might mean that we stop supporting Windows 2000; I'm not sure whether we agreed to that yet.

I'd be curious to find out why the constants were defined in Python 2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Mon Mar  1 08:49:03 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Mar 2010 07:49:03 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1267429743.02.0.392040491496.issue6926@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

"extended support" for windows 2000 server ends in a few months, mainstream support ended 5 years ago:

 http://support.microsoft.com/lifecycle/?LN=en-us&x=8&y=9&p1=7274

That, IMNSHO, implies that python 2.7 and 3.2 should not bother supporting win2k.

Regardless, I'd imagine we can look the particular constants in question up and hard code the values when the header files don't define them for us (that is also the obvious workaround for anyone needing them in code today).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________

From report at bugs.python.org  Mon Mar  1 10:16:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Mar 2010 09:16:32 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1267414478.25.0.456310689331.issue7849@psf.upfronthosting.co.za>
Message-ID: <e43810331003010116u380ec2f2w9962694e551e06ea@mail.gmail.com>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> "lazy" sounds like a bad name for that parameter. It makes me think of lazy evaluation, not error checking.
>

"check_warnings(quiet=True)"  sounds good?

> There's also the problem that check_py3k_warnings() will check all DeprecationWarnings, not only py3k-specific ones. We need a Py3kDeprecationWarning subclass.

+0 about this additional subclass, because the current py3k warnings
are around since 2.6 (r55525).
And if the subclass is accepted, we will need Py3kSyntaxWarning too.
Maybe the "-3" warnings should become "-Wd" warnings at some point,
because 3.2 will probably become trunk after
"branches/release27-maint/" is created. Then we will deprecate the
"-3" switch :)

> Besides, there doesn't seem to be any point accepting positional arguments in check_py3k_warnings(). If you want a custom filter, just use check_warnings() instead.
>

Both are needed, because the "check_py3k_warnings" is no-op except if
"-3" is passed on the command line.
I thought to implement "check_warnings(py3k=True)", at first. But
since this function will be used in 83% of the cases, it may be more
convenient to use a specific name "check_py3k_warnings":
 - 56 test modules will use check_py3k_warnings
 - 11 test modules will use check_warnings

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Mon Mar  1 12:02:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Mar 2010 11:02:02 +0000
Subject: [issue8034] logging: Improve error handing in
	RotatingFileHandler.doRollover()
In-Reply-To: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>
Message-ID: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

My server is running as root and is writing logs into /var/log/nucentral.log. I tried to run it under a different user ("nucentral"), and I changed /var/log/nucentral.log file permissions.

I'm using:
   MAX_LOG_FILESIZE = 5 * 1024 * 1024
   MAX_LOG_FILES = 10   # including .log, so last file prefix is .log.9

   handler = RotatingFileHandler('/var/log/nucentral.log', 'a',
      maxBytes=MAX_LOG_FILESIZE, backupCount=(MAX_LOG_FILES - 1),
      encoding='utf8')

The problems start at the next rollover: the user is not allowed to write into /var/log, and so rename /var/log/nucentral.log to /var/log/nucentral.log.1 (and /var/log/nucentral.log.2 to /var/log/nucentral.log.3) fails. We have here a new problem: doRollover() starts by closing the log file and then rename files. If rename fails, the stream is closed and no new stream is opened. But my server catchs any exception and write them into /var/log/nucentral.log. The rename exception will be written... in the log file, but writing in a closed file raise a new exception! The log system is completly broken and go into an evil recursion loop :-)

I can fix my code responsible to log any exception to avoid the recursion, and avoid the directory permission by writing into /var/log/nucentral/. But there is still the problem of closing the stream before renaming the log files.

I propose to close the stream *after* renaming old log files. Attached patch closes the stream just before reopening it. It works correctly on Linux.

I don't know if it's possible on Windows to rename a file which is currently open :-/ Anyway, the goal is to ensure that the stream is open when exiting the doRollover() function. Another idea would be to use the following pattern:
  stream.close()
  try:
     ...
  except:
     self.stream = self._open()
     raise
  else:
     self._mode = 'w'
     self.stream = self._open()

----------
components: Library (Lib)
files: logging_rotate.patch
keywords: patch
messages: 100252
nosy: haypo
severity: normal
status: open
title: logging: Improve error handing in RotatingFileHandler.doRollover()
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16406/logging_rotate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8034>
_______________________________________

From report at bugs.python.org  Mon Mar  1 12:09:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Mar 2010 11:09:36 +0000
Subject: [issue8034] logging: Improve error handing in
	RotatingFileHandler.doRollover()
In-Reply-To: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>
Message-ID: <1267441776.96.0.497039459444.issue8034@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I forgot something: to avoid trying to file rotation at each log message, the rotation should be disabled at the first error. For RotatingFileHandler, it can be something like:
 try:
  ...
 except:
  self.maxBytes=0
  raise

For TimedRotatingFileHandler, a flag (new attribute) would be required.

I'm not sure that disabling the rotation if the first rotation failure is a good idea, but most the time if the logging system is broken, the application starts to fail randomly :-/ Anyway, the first rotation exception is still raised and so would be catched by something :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8034>
_______________________________________

From report at bugs.python.org  Mon Mar  1 13:38:31 2010
From: report at bugs.python.org (instigate_team)
Date: Mon, 01 Mar 2010 12:38:31 +0000
Subject: [issue7573] Position independent include of Python.h
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1267447111.14.0.113629788929.issue7573@psf.upfronthosting.co.za>


instigate_team <narine_martirosyan at instigatedesign.com> added the comment:

Ok, this can be considered as a future request as Ubuntu 9.10 not so common operating system nowdays.

Please note that the error was noticed only on Ubuntu 9.10, where glibc library version is 2.10.1. Python works OK with GNU C library versions less than 2.10.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Mon Mar  1 16:34:37 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Mar 2010 15:34:37 +0000
Subject: [issue8034] logging: Improve error handing in
	RotatingFileHandler.doRollover()
In-Reply-To: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>
Message-ID: <1267457677.32.0.290597757825.issue8034@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Hi Victor,

A couple of points:

1. On Windows, you can't rename files which are open, so the strategy of closing after renaming doesn't work.

2. Using the alternative strategy (on failure, open the file with the current mode, else open with 'w') - if the exception is re-raised in doRollover, the message about to be logged is not logged (because doRollover is called before logging the message). So, nothing gets written to the log file: each attempt to emit() fails because of the exception in doRollover.

If, on the other hand, the exception is not re-raised, then the write of the logged message proceeds as expected, but the log file then grows without limit - definitely a Bad Thing as it could then interfere with normal program operation (e.g. when the disk fills up).

So, I think the better solution is for the user who has this kind of problem to subclass the handler (as it cannot do what it's meant to do, for reasons beyond its control) and to override handleError and attempt recovery based on the circumstances of the exception (for example in your case, switch the handler's base file name to some writable location).

I'm also not sure if disabling rotation on error is useful or not: the conditions causing the error might be removed externally (e.g. write protection reinstated, file locks released).

I'm not sure why, on logging errors, you would find that your application starts to fail randomly: I've tried to ensure that logging problems interfere with application operation as little as possible. Of course external factors might be affecting both application operation and logging operation, correlation != causation :-)

What do you think?

----------
assignee:  -> vinay.sajip
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8034>
_______________________________________

From report at bugs.python.org  Mon Mar  1 16:45:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Mar 2010 15:45:56 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
Message-ID: <1267458356.51.0.0674148191594.issue5802@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Even if we changed the ACL of the executable, any user could still add malicious code to be executed on import, as the C:\PythonXY directory doesn't require specific privileges for writing to it, and it shouldn't by default. When installed to "C:\Program Files", certain privileges are required to install anything, so regular users can't install third party code or swap out the interpreter. 

If you need the added security, you are more than welcome to choose to install Python to a more secure location. Defaulting to "C:\Program Files" isn't necessary.

See also: issues #1074873 and #818030

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5802>
_______________________________________

From report at bugs.python.org  Mon Mar  1 17:36:05 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 01 Mar 2010 16:36:05 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1267263010.38.0.733789505065.issue6500@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531003010835o73ba516bg53d5d4ec1bdbaa24@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Ok.  I'll take a look, too.

Jeremy

On Sat, Feb 27, 2010 at 4:30 AM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Changes by Ezio Melotti <ezio.melotti at gmail.com>:
>
>
> ----------
> nosy: +orsenthil
> status: pending -> open
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6500>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6500>
_______________________________________

From report at bugs.python.org  Mon Mar  1 20:08:01 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 01 Mar 2010 19:08:01 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267470481.79.0.36414526175.issue1530559@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

The fix breaks my package PyCUDA, which relies on handing struct something that can be cast to long. (i.e. not a float, but something representing a memory address on a GPU)

Am I out of luck?

----------
nosy: +inducer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 20:37:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Mar 2010 19:37:17 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267472237.23.0.166681658609.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd be open to re-allowing use of __int__ (and __long__) consistently for all integer packing codes in 2.7, as a temporary measure;  I'd really prefer not to allow this for 3.x.

What would make more sense, IMO, would be to allow use of the __index__ method (in both 2.7 and 3.x) to convert custom non-integer classes to integers before packing;  this is supposed to be the modern approach to creating integer-like classes that can be used as integers (e.g., in list indices).  Andreas, would this work for you, or do you need to be able to use __int__ and/or __long__?

Re-opening while we're discussing this.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 20:55:01 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 01 Mar 2010 19:55:01 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267473301.7.0.235228035743.issue1530559@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

AFAICS, __index__ would be fine.

To make sure I understand your proposed solution correctly: You'd go through the argument list beforehand and cast everything that's not a number type or str to int by means of __index__?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 21:09:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Mar 2010 20:09:18 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267474158.56.0.918560646594.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

More or less, yes:  when trying to pack a non-integer `x` (i.e. something that's not an instance of int or long) with an integer format code (one of 'bBhHiIlLqQ', or 'P'), `x.__index__()` would be called to convert `x` to an integer, and that integer would be packed as usual (possibly raising OverflowError).  Other format codes wouldn't be affected.

I'm not quite sure what you mean by 'beforehand':  the conversion would happen at the same time as it currently does.

It might be a struggle for me to get to this before the 2.7 betas.  If anyone's interested in submitting a patch, it would be welcome.

----------
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 21:09:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Mar 2010 20:09:35 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1267474175.26.0.403036178803.issue3892@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied skip patch to trunk in r78558, and 2.6 in 78560.

----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Mon Mar  1 21:13:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 01 Mar 2010 20:13:42 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267474422.71.0.834743614073.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Also, it may be that some of r73858 needs to be reverted; going from accepting non-ints and longs in 2.6 to a TypeError in 2.7 is a bit much;  there should have at least been a DeprecationWarning.  I need to find some time to look at this properly, and work out what on earth I was thinking at the time.

----------
priority: normal -> high
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 21:31:52 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 01 Mar 2010 20:31:52 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267475512.42.0.196689777175.issue1530559@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

Thanks for the clarification of 'beforehand'--I had understood from your description that this would be some sort of preprocessing step.

I agree that the TypeError is a bit much, though I'm biased of course. If you'd like my input on things you come up with, please don't hesitate to ping me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  1 22:20:09 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 01 Mar 2010 21:20:09 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1267478409.54.0.0818585541027.issue7250@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I can't come up with a good way to test this either. :(

I'm just going to apply the suggested change and we'll have to test it in 2.6.5 rc 1.  PJE, will you be able to do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7250>
_______________________________________

From report at bugs.python.org  Mon Mar  1 22:40:20 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Mon, 01 Mar 2010 21:40:20 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1267479620.2.0.0950339526047.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Will I be able to do what?  I have a kludgy test and a patch in my checkout, I was just waiting for word back from you (since Feb 19) on whether that would be ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7250>
_______________________________________

From report at bugs.python.org  Mon Mar  1 23:20:07 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Mon, 01 Mar 2010 22:20:07 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>


New submission from Vilnis Termanis <vilnis.termanis at googlemail.com>:

If an object, which as been put() in the multiprocessing.Queue is changed immediately after the put() call then changed version may be added to the queue which I assume is not the expected behaviour:

>>> from multiprocessing import Queue
>>> q = Queue()
>>> obj = [[i for i in xrange(j * 10, (j * 10) + 10)] for j in xrange(0,10)]
>>> q.put(obj); obj[-1][-1] = None
>>> obj2 = q.get()
>>> print obj2[-1][-1]
None

Note: This also happens if the queue is called form a child process like in the attached example.

----------
components: Library (Lib)
files: queue_example.py
messages: 100278
nosy: vilnis.termanis
severity: normal
status: open
title: multiprocessing.Queue's put() not atomic thread wise
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16409/queue_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Mon Mar  1 23:28:33 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Mon, 01 Mar 2010 22:28:33 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267482513.63.0.958385550471.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

More notes:
- Reason for non-atmoic behaviour is due to queue _feeder thread sending the object after the put() method has already exited. Hence changing the object straight after put() can result in the modified object being sent instead.
- Reproduced under Win32 and Ubuntu-64 with v2.6.4
- Not tried with v3.* but looking at the ToT code
  it might also be affected
- The attached patch makes put() atomic but I am completely unsure about whether this is the correct way to address the problem (if it's seen as one).

Regards,
VT

----------
keywords: +patch
Added file: http://bugs.python.org/file16410/queues.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 01:50:21 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 00:50:21 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267491021.88.0.689352702755.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Quick though (last one I promise):

Maybe put() could have an argument to indicate whether to be thread-blocking (i.e. guaranteeing the object to be sent in its current state) or not. The (current) non-thread-blocking mode will have better performance for the put()-calling process if there are a lot of processes trying to write to the queue at once since it can continue regardless (while the _feed thread waits for the internal Pipe to become available).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 02:57:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Mar 2010 01:57:29 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1267495049.96.0.551921110346.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I've uploaded the patch to http://codereview.appspot.com/223088

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Tue Mar  2 03:02:48 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 02:02:48 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267495368.25.0.598614468286.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Hi Meador,

I apologise: I really shouldn't have called it a patch. It's just to show one way that I've found fixes the problem (but presumably reduces performance in other cases, hence the suggestion & wait for feedback on the issue). I'm not really experienced with Python (nor am I an experienced / particularly good developer in general) so it's probably safer to treat me just as a regular user who stumbled upon a problem. :) (I'm definitely not shying away from "ticking all the boxes" but I don't see that there is any point in me trying to yet.)

Regards,
VT

PS: I've re-attached the example "fix" with the diff the right way round (sorry).

----------
Added file: http://bugs.python.org/file16412/lock_suggestion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 13:12:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Mar 2010 12:12:41 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1267531961.76.0.0630216239958.issue2001@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Tue Mar  2 13:26:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Mar 2010 12:26:18 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
Message-ID: <1267532778.3.0.743229313678.issue5802@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 1284316, which is still open, and should probably remain open even though there's no consensus to make a change (yet?).

----------
nosy: +ezio.melotti, flox, r.david.murray
priority:  -> normal
superseder:  -> Win32: Security problem with default installation directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5802>
_______________________________________

From report at bugs.python.org  Tue Mar  2 13:31:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Mar 2010 12:31:37 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267533097.72.0.34237395936.issue1284316@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that Ezio and Flox have been improving the test suite and code to handle paths-with-spaces better.  Perhaps we will eventually get to the point where it is possible to fix this, although Tim's point about python being a CLI/scripting tool remains.

Or perhaps the permissions of the actual install directory could be changed at install time if the install is done by an administrator.

----------
components: +Windows
nosy: +ezio.melotti, flox, michael.foord, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 13:39:21 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Mar 2010 12:39:21 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267533561.19.0.653964557093.issue1284316@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This is similar to an issue I reported to the security team (same underlying issue). My concern was that with an admin installed version of Python an arbitrary user can modify site.py, or create sitecustomize.py, and cause arbitrary code execution when the admin runs Python.

IMO an admin installed Python should require admin priveleges to write to the Python install directory. I think many users would find installing to "Program Files" a pain and it would break many scripts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 14:57:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Mar 2010 13:57:46 +0000
Subject: [issue8038] Not all the new assert* unittest.TestCase methods have
	negative (not) equivalents
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Originally reported as a bug against unittest2: http://code.google.com/p/unittest-ext/issues/detail?id=3

There are some assert* methods that don't have their assertNot* 
counterparts. There's assertDictEqual, assertSequenceEqual, 
assertRegexpMatches, but no assertDictNotEqual, assertSequenceNotEqual, 
assertRegexpNotMatches, for example.

They should be present for the sake of completeness (I don't like to have to look into the docs to check if a method has a negative counterpart), but also because they ask for a custom output. For example, the error accompanying assertRegexpNotMatches could show the matching part of the text, which is the part that really interests me. assert_(re.match(...)) will only tell me that None is not true...

----------
assignee: michael.foord
components: Library (Lib)
messages: 100291
nosy: michael.foord
severity: normal
status: open
title: Not all the new assert* unittest.TestCase methods have negative (not) equivalents
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:00:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Mar 2010 14:00:09 +0000
Subject: [issue8038] Not all the new assert* unittest.TestCase methods have
	negative (not) equivalents
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1267538409.72.0.560456885438.issue8038@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:02:20 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Mar 2010 14:02:20 +0000
Subject: [issue8038] Not all the new assert* unittest.TestCase methods have
	negative (not) equivalents
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1267538540.51.0.612622248718.issue8038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Should there be a 'discussion' stage for the tracker? 

This isn't *really* at the 'test needed' stage, I'm not 100% convinced we should add all these extra methods just 'for the sake of completeness' - but if they are *needed* they should be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:24:57 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 02 Mar 2010 14:24:57 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1267539897.88.0.448519826053.issue2292@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Updating version; does someone want to revive this for 3.2?

----------
nosy: +akuchling
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:26:02 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 02 Mar 2010 14:26:02 +0000
Subject: [issue706392] faster _socket.connect variant desired
Message-ID: <1267539962.15.0.122879324026.issue706392@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706392>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:26:06 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 02 Mar 2010 14:26:06 +0000
Subject: [issue8039] precedence rules for ternary operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

So http://docs.python.org/reference/expressions.html doesn't currently mention the ternary operator as far as I can see. Maybe this is trivial, but it would be nice to know where it fits into the hierarchy.

(I.e., my co-worker just came up to me asking when he needed the parentheses around the entire expression and when he didn't, and I couldn't give him a good answer.)

----------
assignee: georg.brandl
components: Documentation
messages: 100294
nosy: djc, georg.brandl
severity: normal
status: open
title: precedence rules for ternary operator
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8039>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:31:42 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 02 Mar 2010 14:31:42 +0000
Subject: [issue8039] precedence rules for ternary operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267540302.48.0.334490528942.issue8039@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8039>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:32:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Mar 2010 14:32:00 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1267540320.3.0.47217786586.issue2292@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe this would be blocked by the moratorium.  Correct me if I'm wrong.

----------
assignee: twouters -> pedronis
keywords: +after moratorium
nosy: +pedronis, r.david.murray
stage:  -> patch review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar  2 15:32:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Mar 2010 14:32:14 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267540334.28.0.0435664796532.issue1284316@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 16:22:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Mar 2010 15:22:22 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1267543342.97.0.819609897373.issue2292@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

fix inadvertent reassignment.

----------
assignee: pedronis -> twouters
nosy:  -pedronis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar  2 16:30:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Mar 2010 15:30:46 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Currently, trying to use a web search engine to find something in the Python docs often returns the documentation for only one version of Python.  Something a very old version like 2.3.

It would be nice if the documentation pages on docs.python.org included links to older and later versions of the same documentation page, if one exists.  That would make it much easier to navigate to the desired version of a page.  The extra links could be placed on the sidebar on the left side, perhaps below the Quick Search box.

Additionally, it might help search engines find and index the documentation for the other versions.

Microsoft does this for their .NET documentation and it's very handy (e.g., http://msdn.microsoft.com/en-us/library/system.windows.forms.control.aspx)

----------
assignee: georg.brandl
components: Documentation
messages: 100297
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: It would be nice if documentation pages linked to other versions of the same document
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Tue Mar  2 16:34:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Mar 2010 15:34:58 +0000
Subject: [issue8041] No documentation for Py_TPFLAGS_HAVE_STACKLESS_EXTENSION
	or Py_TPFLAGS_HAVE_VERSION_TAG.
In-Reply-To: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za>
Message-ID: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The documentation for Py_TPFLAGS_DEFAULT mentions Py_TPFLAGS_HAVE_STACKLESS_EXTENSION and Py_TPFLAGS_HAVE_VERSION_TAG, but neither of them is documented.  They aren't mentioned in the 2.6 documentation (presumably because they were introduced in 3.x?).

http://docs.python.org/dev/py3k/c-api/typeobj.html?highlight=py_tpflags_have_gc#Py_TPFLAGS_DEFAULT

----------
assignee: georg.brandl
components: Documentation
messages: 100298
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: No documentation for Py_TPFLAGS_HAVE_STACKLESS_EXTENSION or Py_TPFLAGS_HAVE_VERSION_TAG.
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8041>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:18:55 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 02 Mar 2010 16:18:55 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267546735.83.0.0119697251925.issue1284316@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I personally make heavy use of the command line and continue to install python to %ProgramFiles%. I find the space in the pathname to be a non-issue. After %programfiles%\Python26 and %programfiles%\Python26\Scripts are added to the path, and .py is added to PATHEXT, everything behaves very well. I use cmd.exe and powershell, and both of these shells handle the spaces well enough, including supporting tab completion (so if one _does_ need to reference a path with a space in it, it's not even necessary to know what the syntax is).

With Python 3, support for version of Windows prior to XP (including DOS) has been deprecated, so it seems to me rather regressive to insist on DOS 8.3 compatibility.

I concur that early on, I would struggle with the spaces if Python was installed to %programfiles%, but since about Python 2.3 or 2.4, I've had only the one problem with setuptools, and that has been fixed.

IMO, supporting installation to Program Files is not only the right thing to do, but it will make Python more robust.

On the other hand, I may be unaware of any use cases which are still problematic. Perhaps there are still many who always launch python using \python26\python. That command would then become "\program files\python26\python". I find that to be a small price to pay for the gains in security and consistency (and compartmentalization).

Furthermore, a heavy command-line user is probably also a power user, and if typing "C:\Program Files\Python26\Python" is too onerous, I'm sure he can find a workaround, such as setting the path, creating hardlinks or symlinks, setting up aliases, etc.

I agree it's a shame the de-facto location for Programs on Windows isn't a more amenable name.

Personally, I always override the default installation directory, so it matters to me little what choice is made for the default, but on the whole, I believe users would be better off with Python in Program Files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:19:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Mar 2010 16:19:35 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1267546775.02.0.511063670108.issue8040@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:23:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Mar 2010 16:23:16 +0000
Subject: [issue7892] refactor "test_dict.py" using new assertRaises context
	manager.
In-Reply-To: <1265734285.51.0.850285768728.issue7892@psf.upfronthosting.co.za>
Message-ID: <1267546996.33.0.125680512082.issue7892@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done with r78582 and r78583.

----------
assignee:  -> flox
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7892>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:35:25 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Mar 2010 16:35:25 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267547725.49.0.162248131834.issue1284316@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I've tried installations of Python to Program Files in recent years (Python 2.4 and 2.5) and found many scripts/tools unable to cope with the space in the path. I always ended up reinstalling. (Usually using sys.executable in conjunction with calling out to shell scripts.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:38:47 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 16:38:47 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267547927.24.0.187973408387.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

I couldn't see the wood for the trees:
If put() is thread-blocking, multiprocessing.Queue is reduced to the same functionality as multiprocessing.queues.SimpleQueue, if I'm not mistaken. So maybe there should be a warning in the documentation that, for multiprocessing.[Joinable]Queue, modifying obj straight after calling put(obj) might en-queue the modified version.

To me at least this wasn't obvious until I looked at the multiprocessing.queue code.

I've modified the example for clarity and retracted the (unworthy) patch attempt.

Regards,
VT

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:39:00 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 16:39:00 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267547940.19.0.0366245719409.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16412/lock_suggestion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:39:04 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 16:39:04 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267547944.65.0.0635259922495.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16409/queue_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 17:40:27 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 16:40:27 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267548027.68.0.592446489398.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Added file: http://bugs.python.org/file16413/queue_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 19:24:20 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 18:24:20 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267554260.07.0.0997833834625.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Alternative suggestion (since SimpleQueue doesn't provide buffering):

Allow option to force immediate pickling of the object to be en-queued, i.e. pickling when adding to internal buffer instead of as part of Connection.send() in _feed thread. Does this sound like a reasonable solution? (I'll do my best to write unit tests etc. as per submission guidelines, if so.)

Regards,
VT

----------
Added file: http://bugs.python.org/file16414/pickle_suggestion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 20:12:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 02 Mar 2010 19:12:33 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1267557153.85.0.6421546105.issue2292@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would like to see this revisited when the moratorium is lifted.
Added 3.3 as a surrogate for that.
As per GvR above, it will need a PEP to pin down details, alternatives, and use cases and discussion on python-ideas list.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar  2 20:15:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 02 Mar 2010 19:15:19 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1267557319.7.0.0878050147652.issue2292@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whoops, just noticed newish 'after moratorium' keyword. Good idea.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar  2 20:53:22 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Tue, 02 Mar 2010 19:53:22 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1267559602.89.0.361689625305.issue5315@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I'm seeing something very similar to this.  In my case, I have a single-threaded program, and select fails to be interrupted by SIGCHLD.  I'm still tracking down more details, so I'll report back if I find more information.

----------
nosy: +amcnabb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:03:31 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 21:03:31 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267563811.28.0.0604005808657.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Performance comparison before/after suggested change (adding/removing 1000-item list 10000 times).

Inline
----
1.926 <class 'multiprocessing.queues.Queue'>
1.919 <class 'queues_pickled.Queue'>
1.907 <class 'queues_pickled.Queue'> (bufferPickled = True)

<class 'threading.Thread'>
----
2.138 <class 'multiprocessing.queues.Queue'>
2.379 <class 'queues_pickled.Queue'>
2.304 <class 'queues_pickled.Queue'> (bufferPickled = True)

<class 'multiprocessing.process.Process'>
----
1.158 <class 'multiprocessing.queues.Queue'>
1.151 <class 'queues_pickled.Queue'>
1.141 <class 'queues_pickled.Queue'> (bufferPickled = True)

----------
Added file: http://bugs.python.org/file16415/pickle_suggestion_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:03:53 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 21:03:53 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267563833.01.0.654109051211.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16414/pickle_suggestion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:12:54 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Mar 2010 21:12:54 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267564374.95.0.630027496653.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Added file: http://bugs.python.org/file16416/queue_perf.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:26:06 2010
From: report at bugs.python.org (Matt Gattis)
Date: Tue, 02 Mar 2010 21:26:06 +0000
Subject: [issue8042] mmap buffer implementation does not respect seek pos
In-Reply-To: <1267565166.19.0.574774228876.issue8042@psf.upfronthosting.co.za>
Message-ID: <1267565166.19.0.574774228876.issue8042@psf.upfronthosting.co.za>


New submission from Matt Gattis <gattis at gmail.com>:

If you do:

import io,mmap

b = io.BytesIO("abc")
m = mmap.mmap(-1,10)
m.seek(5)
b.readinto(m)

M is now:
'abc\x00\x00\x00\x00\x00\x00\x00'

Basically there is no way to readinto/recv_into an arbitary position in an mmap object without creating a middle-man string.

----------
messages: 100308
nosy: Matt.Gattis
severity: normal
status: open
title: mmap buffer implementation does not respect seek pos
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8042>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:27:33 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Tue, 02 Mar 2010 21:27:33 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1267565253.38.0.471412168597.issue5315@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

Sorry for the noise.  It turns out that my problem was unrelated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:43:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Mar 2010 21:43:04 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267566184.66.0.680699284331.issue1284316@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I propose that people in favor of changing the default install location write a PEP proposing that this be done.

Notice that this is independent of the issue at hand, which is about the ACLs on c:\pythonXY. I have tried fixing it, and failed so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 22:45:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Mar 2010 21:45:07 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1267566307.68.0.453334527987.issue8040@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It think it's also extremely difficult to implement, since the switchover to a new documentation generator. Contributions are welcome.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:39:42 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 02 Mar 2010 22:39:42 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1267569582.89.0.77569108195.issue1284316@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Martin: Would it be sufficient to copy the ACLs from %programfiles%, or would it be better to hard-code the permissions from %programfiles% from a known standard configuration? Is it known if the ACLs on %programfiles% in WinXP differ from later platforms? What difficulty have you encountered?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:51:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Mar 2010 22:51:40 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
In-Reply-To: <1267569582.89.0.77569108195.issue1284316@psf.upfronthosting.co.za>
Message-ID: <4B8D9678.8070801@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin: Would it be sufficient to copy the ACLs from %programfiles%,
> or would it be better to hard-code the permissions from
> %programfiles% from a known standard configuration? Is it known if
> the ACLs on %programfiles% in WinXP differ from later platforms? What
> difficulty have you encountered?

I can only answer the last question: I tried using the ACL features in
MSI (i.e. with the LockPermissions table), and couldn't get that to work.

Personally, I would think that restricting write access to the user
performing the installation should be good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:52:05 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 02 Mar 2010 22:52:05 +0000
Subject: [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

On Python 2.6 and Python 2.7a, calling ntpath.realpath(os.devnull) returns '\\\\nul' (two backslashes followed by nul), which is not a valid filename.

This appears to have been fixed in Python 3.1, as on 3.1.1, ntpath.realpath(os.devnull) returns '\\\\.\\nul' which apparently is the absolute path to the NULL file handle.

----------
components: Windows
messages: 100314
nosy: jaraco
severity: normal
status: open
title: ntpath.realpath munges os.devnull
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8043>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:53:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Mar 2010 22:53:04 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1267570384.15.0.969257739141.issue2973@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited grooverdan's patch: r78596 (trunk), r78597 (2.6), r78598 (py3k), 78599 (3.1).

The API was changed in... 2004, 6 years ago! I hope that everybody upgraded to the new OpenSSL version since that. Anyway, the warning should be fixed, and Python should be compatible with any OpenSSL version.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Tue Mar  2 23:53:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Mar 2010 22:53:17 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1267570397.04.0.176801912618.issue2973@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Wed Mar  3 00:01:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Mar 2010 23:01:54 +0000
Subject: [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267570914.63.0.487129853411.issue8043@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This might be related to #7909.

----------
components: +Library (Lib)
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8043>
_______________________________________

From report at bugs.python.org  Wed Mar  3 00:31:58 2010
From: report at bugs.python.org (David Watson)
Date: Tue, 02 Mar 2010 23:31:58 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1267572718.76.0.717839049563.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

OK, here's a new version as a work in progress.  A lot of the new
stuff is uncommented (particularly the support code for the
tests), but there are proper docs this time and a fairly complete
test suite (but see below).

There are a couple of changes to the interface (hopefully the
last).  The recvmsg() methods no longer receive ancillary data by
default, since calling them on an AF_UNIX socket with the old
default buffer could allow a malicious sender to send unwanted
file descriptors up to receiver's resource limit, and in a
multi-threaded program, another thread could then be prevented
from opening new file descriptors before the receiving thread had
a chance to close the unwanted ones.

Since the ancillary buffer size argument is now more likely to
need a value, I've moved it to second place; the basic argument
order is now the same as in Kalman Gergely's patch.  CMSG_LEN()
and CMSG_SPACE() are now provided.

I've also used socket.error instead of ValueError when rejecting
some buffer object/array for being too big to handle, since the
system call itself might cause socket.error to be raised for a
smaller (oversized) object, failing with EMSGSIZE or whatever.

The code is now much more paranoid about checking the results of
the CMSG_*() macros, and will raise RuntimeError if it finds its
assumptions are not met.

I'd still like to add tests for receiving some of the RFC 3542
ancillary data items, especially since the SCM_RIGHTS tests can't
always (ever?) test recvmsg() with multiple items (if you send
two FD arrays, the OS can coalesce them into a single array
before delivering them).

----------
Added file: http://bugs.python.org/file16417/baikie-hwundram-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Mar  3 00:58:07 2010
From: report at bugs.python.org (Albert Hopkins)
Date: Tue, 02 Mar 2010 23:58:07 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1267574287.77.0.79333407006.issue5380@psf.upfronthosting.co.za>


Changes by Albert Hopkins <marduk at python.net>:


----------
nosy: +marduk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Wed Mar  3 01:22:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Mar 2010 00:22:35 +0000
Subject: [issue7820] parser: restores all bytes in the right order if
	check_bom() fails
In-Reply-To: <1264908263.1.0.898518004348.issue7820@psf.upfronthosting.co.za>
Message-ID: <1267575755.88.0.117458491343.issue7820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r78603 (trunk), r78608 (py3k), r78609 (3.1).

Delay the fix in 2.6 after the release of 2.6.5. This issue is far from being critical, I don't want to introduce a regression after an RC :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Wed Mar  3 01:38:50 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 03 Mar 2010 00:38:50 +0000
Subject: [issue7909] os.path.abspath(os.devnull) returns \\\\nul should be nul?
In-Reply-To: <1265900984.97.0.533817039299.issue7909@psf.upfronthosting.co.za>
Message-ID: <1267576730.29.0.446971290524.issue7909@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This bug does not exhibit in Python 3.1.1.

----------
nosy: +jaraco
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7909>
_______________________________________

From report at bugs.python.org  Wed Mar  3 01:40:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Mar 2010 00:40:22 +0000
Subject: [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267576822.96.0.666890805546.issue8043@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8043>
_______________________________________

From report at bugs.python.org  Wed Mar  3 01:43:14 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 03 Mar 2010 00:43:14 +0000
Subject: [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267576994.52.0.601340254086.issue8043@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed, this is a duplicate. My search failed probably because ntpath.abspath is ntpath.realpath.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8043>
_______________________________________

From report at bugs.python.org  Wed Mar  3 01:51:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Mar 2010 00:51:58 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1267577518.36.0.474863878942.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

thread fix commited: r78610 (trunk), r78611 (py3k), r78612 (3.1).

Delay the backport to 2.6 after the 2.6.5 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Wed Mar  3 02:07:53 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Wed, 03 Mar 2010 01:07:53 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267578473.25.0.907692851685.issue7449@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

In the test_xmlrpc.py case I changed the value from URL to 'http:' because the code that sets URL to a valid url relies on threading.  When threading is disabled, URL is set to None and the test will fail.  The two ServerProxy test cases that were modified in this way do not actually use the network at all.  They instead test that the close() method returns None and that the transport() method returns the transport passed in to the constructor.  I figured setting the url to 'http:' instead of an empty string was more readable.  The reader would know that the string was supposed to be a url and that it was utterly meaningless in this case.

In the test_macostools.py case, the os.unlink(TESTFN2) call is a copy and paste error from the previous test.  This test tried to remove an alias it never created, and it failed to check that the destination directory for the alias actually was a directory (it only checked that the path existed - in my case it was a file, not a directory).  I fixed the test to check that sys.prefix is a directory, and then clean up sys.prefix/TESTFN2.

The skip_if_no decorator is not absolutely necessary and could have been skipped.  I believe it adds to the readability of the code because with the decorator it becomes obvious that the test should skip in some cases.  Perhaps this is what import_module() is for - if so, should I document it?  I also believe the decorator helps prevent cases where a resource is allocated (like creating a directory), then the import_module() call fails and a test artifact is left laying around on disk.  Having said that, I do not know if this actually happens in any of the tests and so might be a moot point.  

In reference to disliking the naming of skip_if_no(), I do not like the naming either.  The decorator attempts to import the module, then raises SkipTest if there was an ImportError.  I think it is essential to have the words "import" and "skip" in the method name to help indicate what the decorator does.  These are names I could live with:

import_or_skip_test('threading')
import_module_or_skip_test('threading')
skip_test_unless_import('threading')

My preference is for the last one.  Let me know which one you like best and I'll change the name to that.

----------
Added file: http://bugs.python.org/file16418/nothreads_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Wed Mar  3 02:46:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Mar 2010 01:46:20 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267580780.2.0.591605409747.issue7449@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't reviewed the whole patch, but I would suggest that instead of making a test_support.skip_if_no (or any other name), you use use @unittest.skipUnless(threading) (note that lack of quotes around threading...you seem to already be getting it defined correctly in all the modules I scaned).  That's what other test modules do in similar situations.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:05:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Mar 2010 02:05:03 +0000
Subject: [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267581903.02.0.306524318053.issue8043@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8043>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:14:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Mar 2010 02:14:03 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1267578473.25.0.907692851685.issue7449@psf.upfronthosting.co.za>
Message-ID: <201003030314.14539.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In the test_xmlrpc.py case I changed the value from URL to 'http:' because
> the code that sets URL to a valid url relies on threading.  When threading
> is disabled, URL is set to None and the test will fail.

I would prefer something like:

if support threads:
   url = URL
else:
   url = "http:"

To avoid modifying the current tests in the most common case, Python with 
threads.

> In the test_macostools.py case, the os.unlink(TESTFN2) call is a copy and
>  paste error from the previous test (...)

Is this fix related to threads? If not, please open a different issue with a 
patch just to fix that.

> The skip_if_no decorator is not absolutely necessary and could have been
>  skipped.  I believe it adds to the readability of the code because with
>  the decorator it becomes obvious that the test should skip in some
>  cases.  Perhaps this is what import_module() is for - if so, should I
>  document it? (...)

I like your decorator, but not it's name :-)

import_module() is not a decorator, but your decorator call it, so it's fine.

> These are names I could live with:
> 
> import_or_skip_test('threading')
> import_module_or_skip_test('threading')
> skip_test_unless_import('threading')

The main goal is to skip a test, so a name starting with "skip" is a good 
idea. You might drop "test_" because we already have a context (namespace): 
the function is defined in the test_support module.

@test_support.skip_unless_import('thread') doesn't look bad :-)

--

Comments about your new patch.

Lib/ctypes/test/test_errno.py is completly skipped whereas only half the tests 
depends on threads.

I don't really like the idea of skipping the whole file if threads are 
disabled (except for tests only based on tests, like test_threading.py). If 
someone adds a new test without reading the imports header, he will not notice 
that the test will be skipped if threads are not available, even if his test 
doesn't depend on threads. Since Python 2.7 and 3.0+ supports class 
decorators, why not using a decorator on classes instead of the blacklisting 
the whole file? I don't know if you decorator can be used on a class without 
any change. You need maybe to add **kw to the wrapper() function.

Lib/test/test_sqlite.py: only Lib/sqlite3/test/dbapi.py depends on threads, 
all other tests should work without thread.

Lib/test/test_urllib2_localnet.py shouldn't inherit from BaseTestCase because 
it overrides all methods (setUp and tearDown), but simply from 
unittest.TestCase. This is not directly related to your patch.

reap_threads(): you should move the "import thread" to do it only once, and 
write a dummy decorator if threads are disabled. Something like:

if have threads:
  def reap_threads(func):
    ...
else:
  def reap_threads(func):
    # do nothing
    return func

And write a doc string to explain that the function does nothing if threads 
are disabled.

fork_wait.py, test_bz2.py: the decorator is maybe useless here (import_module 
should be enough). Or do you suggest it for the readability?

Lib/test/test_multiprocessing.py: I guess that some tests can be executed 
without thread (only testcases_threads require threads?).

Lib/test/test_capi.py: because of import_module('threading'), TestPendingCalls 
will be skipped whereas TestPendingCalls.test_pendingcalls_non_threaded() 
works without threads.

Lib/test/test_hashlib.py can simply use @reap_threads and import_module() in 
test_threaded_hashing() (instead of using a try/except at the beginning of the 
file).

...

I'm too tired to re-read the whole patch. I think that you understood my 
ideads, and I don't have to detail changes on each file.

Can you write a new version of the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:23:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 03 Mar 2010 02:23:04 +0000
Subject: [issue8044] Py_EnterRecursiveCall and Py_LeaveRecursiveCall are
	undocumented
In-Reply-To: <1267582984.0.0.0717168026591.issue8044@psf.upfronthosting.co.za>
Message-ID: <1267582984.0.0.0717168026591.issue8044@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Here's the original message proposing the addition of these routines to the C API, which might serve as the basis of documentation:

http://mail.python.org/pipermail/python-dev/2003-October/039445.html

----------
assignee: georg.brandl
components: Documentation
messages: 100325
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: Py_EnterRecursiveCall and Py_LeaveRecursiveCall are undocumented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8044>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:33:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2010 02:33:53 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

potential 2.6.5 release blocker

The changes introduced for Issue7999 in r78546, r78547, r78548, r78549 cause test_tcl to fail when it is run after test_os, as is normal under regrtest.  The problem is that the posixmodule was modified to accept values of -1 for setreuid and setregid and, although the tests added for them claim that they do nothing, on OS X 10.6 (in a framework build at least) they do have a side effect.  A simplified test case demonstrates:

$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> Tcl().loadtk()  # Tk window opens
>>> ^D
$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> import os
>>> os.getuid(), os.geteuid()
(501, 501)
>>> os.setreuid(-1, -1)
>>> os.getuid(), os.geteuid()
(501, 501)
>>> Tcl().loadtk()
2010-03-02 18:20:28.375 Python[21147:60f] The application with bundle ID org.python.python is running setugid(), which is not allowed.
$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> import os
>>> os.getgid(), os.getegid()
(20, 20)
>>> os.setregid(-1, -1)
>>> os.getgid(), os.getegid()
(20, 20)
>>> Tcl().loadtk()
2010-03-02 18:25:15.952 Python[21163:60f] The application with bundle ID org.python.python is running setugid(), which is not allowed.

Searching the web for "running setugid(), which is not allowed" shows various programs affected by this change in OS X 10.6, apparently to close a security hole.

Unfortunately, the module and test changes cause the standard python regression test to abort at test_tcl. For 2.6.5 at least, suggest disabling the two new -1, -1 tests on OS X.  (I assume that the other branches exhibit the same behavior but I haven't explicitly tested them yet.)

----------
messages: 100326
nosy: barry, gregory.p.smith, ned.deily, ronaldoussoren
severity: normal
status: open
title: test_tcl aborts on OS X 10.6 with "The application with bundle ID org.python.python is running setugid(), which is not allowed."
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:37:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2010 02:37:32 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267583852.34.0.500235966487.issue8045@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Thanks to Tom Loredo for bringing up the issue on the pythonmac-sig list.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:41:15 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2010 02:41:15 +0000
Subject: [issue7999] setregid does not work with -1 as argument
In-Reply-To: <1266919086.08.0.79034896457.issue7999@psf.upfronthosting.co.za>
Message-ID: <1267584075.44.0.996325928108.issue7999@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Apparently there is a side effect on OS X 10.6 of setting to -1.  See Issue8045.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7999>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:45:45 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 03 Mar 2010 02:45:45 +0000
Subject: [issue7909] os.path.abspath(os.devnull) returns \\\\nul should be nul?
In-Reply-To: <1265900984.97.0.533817039299.issue7909@psf.upfronthosting.co.za>
Message-ID: <1267584345.44.0.331680512523.issue7909@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Attaching a test against trunk which elicits the error reported in this bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file16419/issue7909-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7909>
_______________________________________

From report at bugs.python.org  Wed Mar  3 03:47:40 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Mar 2010 02:47:40 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267584460.99.0.332904714735.issue8045@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Just disabling those two tests is the best thing for the 2.6.5 release if we don't get around to the actual fix:

Since calling setreuid(-1, -1) is apparently not such a no-op on all systems these tests would be better if we ran them in a subprocess so that they don't alter the main test runner process state.

----------
assignee:  -> gregory.p.smith
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Wed Mar  3 04:39:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 03 Mar 2010 03:39:53 +0000
Subject: [issue8046] mmap.mmap as a context manager
In-Reply-To: <1267587593.82.0.663403244999.issue8046@psf.upfronthosting.co.za>
Message-ID: <1267587593.82.0.663403244999.issue8046@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Most file or file-like objects operate as context managers, except for mmap (and maybe a few others?). Attached is a patch with tests and documentation.

The patch also introduces an additional attribute to mmap, "closed".

----------
components: Library (Lib)
files: mmap_context_mgr.diff
keywords: needs review, patch, patch
messages: 100331
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: mmap.mmap as a context manager
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16420/mmap_context_mgr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8046>
_______________________________________

From report at bugs.python.org  Wed Mar  3 05:43:03 2010
From: report at bugs.python.org (Hong Chen)
Date: Wed, 03 Mar 2010 04:43:03 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1267532778.3.0.743229313678.issue5802@psf.upfronthosting.co.za>
Message-ID: <3ec02ba21003022042h49596ccgf9659401bdc1f51f@mail.gmail.com>


Hong Chen <cn.hongchen at gmail.com> added the comment:

Sure. Thank you for the information!

Hong

On Tue, Mar 2, 2010 at 4:26 AM, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> See also issue 1284316, which is still open, and should probably remain open even though there's no consensus to make a change (yet?).
>
> ----------
> nosy: +ezio.melotti, flox, r.david.murray
> priority: ?-> normal
> superseder: ?-> Win32: Security problem with default installation directory
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5802>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5802>
_______________________________________

From report at bugs.python.org  Wed Mar  3 08:15:25 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 03 Mar 2010 07:15:25 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

The xml.etree.ElementTree package in the Python 3.x standard library breaks compatibility with existing ET 1.2 code. The serialiser returns a unicode string when no encoding is passed. Previously, the serialiser was guaranteed to return a byte string. By default, the string was 7-bit ASCII compatible.

This behavioural change breaks all code that relies on the default behaviour of ElementTree. Since there is no longer a default encoding in Python 3, unicode strings are incompatible with byte strings, which means that the result of the serialisation can no longer be written to a file, for example.

XML is well defined as a stream of bytes. Redefining it as a unicode string *by default* is hard to understand at best.

Finally, it would have been good to look at the other ET implementation before introducing such a change. The lxml.etree package has had support for serialising XML into a unicode string for years, and does so in a clear, safe and explicit way. It requires the user to pass the 'unicode' (Py3 'str') type as encoding parameter, e.g.

    tree.tostring(encoding=str)

which is explicit enough to make it clear that this is different from a normal encoding.

----------
components: Library (Lib)
messages: 100333
nosy: scoder
severity: normal
status: open
title: Serialiser in ElementTree returns unicode strings in Py3k
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Wed Mar  3 09:17:35 2010
From: report at bugs.python.org (Noam Raphael)
Date: Wed, 03 Mar 2010 08:17:35 +0000
Subject: [issue8048] doctest assumes sys.displayhook hasn't been touched
In-Reply-To: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>
Message-ID: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>


New submission from Noam Raphael <noamraph at gmail.com>:

Hello,

This bug is the cause of a bug reported about DreamPie: https://bugs.launchpad.net/bugs/530969

DreamPie (http://dreampie.sourceforge.net) changes sys.displayhook so that values will be sent to the parent process instead of being printed in stdout. This causes doctest to fail when run from DreamPie, because it implicitly assumes that sys.displayhook writes the values it gets to sys.stdout. This is why doctest replaces sys.stdout with its own file-like object, which is ready to receive the printed values.

The solution is simply to replace sys.displayhook with a function that will do the expected thing, just like sys.stdout is replaced. The patch I attach does exactly this.

Thanks,
Noam

----------
components: Library (Lib)
files: doctest.py.diff
keywords: patch
messages: 100334
nosy: noam
severity: normal
status: open
title: doctest assumes sys.displayhook hasn't been touched
type: behavior
Added file: http://bugs.python.org/file16421/doctest.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8048>
_______________________________________

From report at bugs.python.org  Wed Mar  3 10:10:51 2010
From: report at bugs.python.org (dawton)
Date: Wed, 03 Mar 2010 09:10:51 +0000
Subject: [issue8049] Wrong calculation result
In-Reply-To: <1267607451.17.0.432380400907.issue8049@psf.upfronthosting.co.za>
Message-ID: <1267607451.17.0.432380400907.issue8049@psf.upfronthosting.co.za>


New submission from dawton <dawton at centrum.cz>:

I'm using Python 2.3 and today I found out, that Python gives following result:
>>> 2.05*60
122.99999999999999

while
>>> 2.05*10*6
123.0

Is there some explanation or is it a bug?
Thanks for answer!

----------
messages: 100335
nosy: dawton
severity: normal
status: open
title: Wrong calculation result
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8049>
_______________________________________

From report at bugs.python.org  Wed Mar  3 10:32:53 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 03 Mar 2010 09:32:53 +0000
Subject: [issue8049] Wrong calculation result
In-Reply-To: <1267607451.17.0.432380400907.issue8049@psf.upfronthosting.co.za>
Message-ID: <1267608773.4.0.513971326504.issue8049@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Please read http://docs.python.org/tutorial/floatingpoint.html

----------
nosy: +eric.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8049>
_______________________________________

From report at bugs.python.org  Wed Mar  3 11:08:52 2010
From: report at bugs.python.org (dawton)
Date: Wed, 03 Mar 2010 10:08:52 +0000
Subject: [issue8049] Wrong calculation result
In-Reply-To: <1267608773.4.0.513971326504.issue8049@psf.upfronthosting.co.za>
Message-ID: <1267610928.142253.11785.nullmailer@mail1010.cent>


dawton <dawton at centrum.cz> added the comment:

thanks a lot!
*d.

______________________________________________________________
> Od: "Eric Smith" <report at bugs.python.org>
> Komu: dawton at centrum.cz
> Datum: 03.03.2010 10:32
> P?edm?t: [issue8049] Wrong calculation result
>
>Eric Smith <eric at trueblade.com> added the comment:
>
>Please read http://docs.python.org/tutorial/floatingpoint.html
>
>----------
>nosy: +eric.smith
>resolution:  -> invalid
>status: open -> closed
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue8049>
>_______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8049>
_______________________________________

From report at bugs.python.org  Wed Mar  3 12:22:58 2010
From: report at bugs.python.org (Joaquin Cuenca Abela)
Date: Wed, 03 Mar 2010 11:22:58 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267615378.39.0.902858703138.issue7143@psf.upfronthosting.co.za>


Joaquin Cuenca Abela <e98cuenc at gmail.com> added the comment:

Hi,

RFC 2046, 5.1.1 refers to the CRLF that happens just before the boundary. It says nothing about an encoded CRLF.

>From Andreas example, if you have:

Content-Type: text/plain; name="test.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="test.txt"

MTIzCg==
--------------040103020004000509010404--

You are correctly eating the CRLF that exists between MTIzCg== and --------------040103020004000509010404--, because it's part of the boundary.

You are also eating the CRLF that is inside the base64 encoded text, and I agree with Andreas that this is incorrect. Will you please consider reopening this bug?

----------
nosy: +Joaquin.Cuenca.Abela

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Wed Mar  3 13:08:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Mar 2010 12:08:35 +0000
Subject: [issue8048] doctest assumes sys.displayhook hasn't been touched
In-Reply-To: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>
Message-ID: <1267618115.81.0.515250065956.issue8048@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8048>
_______________________________________

From report at bugs.python.org  Wed Mar  3 13:15:03 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 03 Mar 2010 12:15:03 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267618503.22.0.164398884593.issue7232@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Okay, it is done, see r78623 (trunk) and r78626 (py3k).

Thanks to all for your work and support!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Wed Mar  3 13:16:02 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 03 Mar 2010 12:16:02 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267618562.81.0.155380473924.issue7232@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Wed Mar  3 13:38:36 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 03 Mar 2010 12:38:36 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1267619916.24.0.552412400456.issue2973@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Because we're in release candidate mode, I reverted the change to the release26-maint branch.  It doesn't seem critical enough to sneak in between rc and final.  Please do re-apply after 2.6.5 final is released though!

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Wed Mar  3 14:25:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 03 Mar 2010 13:25:23 +0000
Subject: [issue8039] precedence rules for ternary operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267622723.74.0.321446086864.issue8039@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

For what it's worth, these are properly called "Conditional Expressions". See PEP 308 for the gory details, including figuring out what the precedence is. It was news to me that the allowed syntax is slightly different in 2.x and 3.x.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8039>
_______________________________________

From report at bugs.python.org  Wed Mar  3 14:44:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Mar 2010 13:44:41 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267623881.94.0.139641830562.issue8047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not an ElementTree user, but that spelling (etree.tostring(encode=str), or even etree.tostring(encode=unicode)) strikes me as horrible.  You don't encode to unicode, you *decode* to unicode.  Thus the current Python3 interface works the way I'd expect: if I don't specify an encoding, I get unicode.  If I do specify an encoding, I get encoded bytes.  In the general case the fact that you can no longer get away with being sloppy about what encoding a byte stream is in, the way you could in Python2, is a feature of Python3, not a bug.

If anything, having 'tostring' return bytes is broken, given its name.  But I think we fudge that by claiming it is returning a 'byte string' when given an encoding.

That said, I'm not sure how much, if at all, my opinion counts :)

----------
nosy: +effbot, flox, r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Wed Mar  3 15:08:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Mar 2010 14:08:57 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267625337.02.0.975220304987.issue7143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I misunderstood, and did not see that the newline in question was inside the base64 string.  Thank you for pointing out my mistake.

Would either of you like to propose a patch, including a test case?

(I've removed 2.5 because it is in security-fix-only mode).

----------
assignee:  -> r.david.murray
keywords: +easy
resolution: invalid -> 
stage: committed/rejected -> test needed
status: closed -> open
title: get_payload(decode=True) eats last newline -> get_payload(decode=True) eats last newline in base64 encoded payload
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Wed Mar  3 15:12:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Mar 2010 14:12:06 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267625526.33.0.435358273233.issue7143@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Wed Mar  3 15:27:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Mar 2010 14:27:49 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1267626469.36.0.287198719129.issue2973@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

barry> Because we're in release candidate mode, 
barry> I reverted the change to the release26-maint branch.

Yeah, sorry. I realized that after backporting the fix to 2.6.

barry> Please do re-apply after 2.6.5 final is released though!

Ok. I reopened to issue to not forget.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Wed Mar  3 15:33:43 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 03 Mar 2010 14:33:43 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267626823.96.0.419434568201.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I agree that the lxml API is somewhat clumsy here. I just mentioned it to show that there are already ways to do it in a backwards compatible way, so this change does two things: it breaks existing code, and it does so in a way that is incompatible with other existing implementations. That's what *I* would call horrible.

Also, this is absolutely not a feature that is restricted to Py3, so what's the equivalent feature in the standard library of Py2 going to be, and how much code will it break for the Py2 series?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Wed Mar  3 16:00:18 2010
From: report at bugs.python.org (Allison Vollmann)
Date: Wed, 03 Mar 2010 15:00:18 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>


New submission from Allison Vollmann <allisonvoll at gmail.com>:

When call SMTP.sendmail (with simple sendmail local sent and with smtp auth), the follow exception be raised (with debug output):

send: 'mail FROM:<xxx> size=5\r\n'
reply: '250 2.1.0 Ok\r\n'
reply: retcode (250); Msg: 2.1.0 Ok
send: 'rcpt TO:<xxx>\r\n'
reply: '250 2.1.5 Ok\r\n'
reply: retcode (250); Msg: 2.1.5 Ok
send: 'data\r\n'
reply: '354 End data with <CR><LF>.<CR><LF>\r\n'
reply: retcode (354); Msg: End data with <CR><LF>.<CR><LF>
data: (354, 'End data with <CR><LF>.<CR><LF>')

Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    s.sendmail(to, to, msg)
  File "C:\Python26\lib\smtplib.py", line 710, in sendmail
    (code,resp) = self.data(msg)
  File "C:\Python26\lib\smtplib.py", line 474, in data
    q = quotedata(msg)
  File "C:\Python26\lib\smtplib.py", line 157, in quotedata
    re.sub(r'(?:\r\n|\n|\r(?!\n))', CRLF, data))
  File "C:\Python26\lib\re.py", line 151, in sub
    return _compile(pattern, 0).sub(repl, string, count)
TypeError: expected string or buffer

This error appear because 'data' isn't an string object, just replacing "q = quotedata(msg)" for "q = quotedata(str(msg))" (in Python26\lib\smtplib.py:474) solves the problem, but i can't understand how this simple mistake does not be noticed

Teste in: 
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2,
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Regular Expressions
messages: 100346
nosy: Allison.Vollmann
severity: normal
status: open
title: smtplib SMTP.sendmail (TypeError: expected string or buffer)
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8050>
_______________________________________

From report at bugs.python.org  Wed Mar  3 16:00:33 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 03 Mar 2010 15:00:33 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1267628433.01.0.177502017251.issue7808@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Florent, Could you explain the changes to the unittest?. I don't understand them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Wed Mar  3 16:24:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 03 Mar 2010 15:24:07 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1267629847.87.0.211185610104.issue8050@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components: +Library (Lib) -Regular Expressions
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8050>
_______________________________________

From report at bugs.python.org  Wed Mar  3 16:34:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Mar 2010 15:34:11 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1267630451.26.0.152413773226.issue7808@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Could you explain the changes to the unittest?

The reference to "self" in the hooks were preventing the GC of the test case, as far as I understand, because it creates a cycle.
When using weak references, there's no more dead cycles.
It is my own explanation, maybe it's not exactly what happens.

For the sys.traceback, I could not explain it better than the FAQ:
http://docs.python.org/faq/design.html#how-does-python-manage-memory

I may add a small comment in test_replication to explain the usage of weakref.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Wed Mar  3 18:24:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Mar 2010 17:24:50 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267637090.07.0.832760646435.issue8047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that backward compatibility, while nice to retain, was not considered a stopper for cleaning up interfaces in py3.  Exactly how considered this change was, I have no idea, but as I said it does make sense to me.  As for 2.x, what's there is what's there, as far as I can see.  Florent could speak to whether or not that API is likely to change in 2.7, but I doubt it will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Wed Mar  3 20:10:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Mar 2010 19:10:57 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267643457.44.0.00136663727014.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With ET 1.3, the serializer ElementTree.write() should output bytes only. And the default encoding is still US-ASCII.

The new behaviour is specific to the 3.x branch (since 3.0, r56841).
Even if it is not fully backward compatible, I don't find this behavior shocking: it is a rule of Python 3 to avoid implicit encoding/decoding.

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Wed Mar  3 21:24:59 2010
From: report at bugs.python.org (David Watson)
Date: Wed, 03 Mar 2010 20:24:59 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1267647899.04.0.409102568578.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

I just found that the IPv6 tests don't get skipped when IPv6 is
available but disabled in the build - you can create IPv6
sockets, but not use them :/  This version fixes the problem.

----------
Added file: http://bugs.python.org/file16422/baikie-hwundram-v2.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Mar  3 23:03:49 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 03 Mar 2010 22:03:49 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1267653829.62.0.277206619545.issue7540@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

This change breaks existing uses of Python 2.6.4.

The mechanize library frequently re-initializes the data in the request
without re-using the request.  Applications (including tests) that use
mechanize now break with this TypeError.

The proper response to this issue for Python 2.6 is to make no code
changes (though a documentation enhancement may be in order).

This change should be reverted from all branches.

Python 2.6.5 should be blocked until this is done.

----------
nosy: +fdrake
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Wed Mar  3 23:10:58 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 03 Mar 2010 22:10:58 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1267654258.11.0.270414651022.issue7540@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

To clarify: Multiple calls to add_data on a urllib2 request, when the request isn't being reused, are in no way invalidated by the problem initially reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Wed Mar  3 23:37:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Mar 2010 22:37:13 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1267655833.12.0.570970441214.issue4036@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os.exec*() now accept bytes thanks to the PEP 383: see issue #4035.

I updated my patch: it now includes tests \o/ It works on Linux. Can someone test it on Windows and/or Mac OS X?

----------
resolution:  -> fixed
status: open -> closed
Added file: http://bugs.python.org/file16423/subprocess-bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Thu Mar  4 00:48:25 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Wed, 03 Mar 2010 23:48:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267660105.9.0.96148230136.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I just noticed a cornercase with the newly introduced grapheme matcher \X, if this is used in the character set:

>>> regex.findall("\X", "abc")
['a', 'b', 'c']
>>> regex.findall("[\X]", "abc")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "regex.pyc", line 218, in findall
  File "regex.pyc", line 1435, in _compile
  File "regex.pyc", line 2351, in optimise
  File "regex.pyc", line 2705, in optimise
  File "regex.pyc", line 2798, in optimise
  File "regex.pyc", line 2268, in __hash__
AttributeError: '_Sequence' object has no attribute '_key'

It obviously doesn't make much sense to use this universal literal in the character class (the same with "." in its metacharacter role) and also http://www.regular-expressions.info/refunicode.html doesn't mention this possibility; but the error message might probably be more descriptive, or the pattern might match "X" or "\" and "\X" (?)

I was originally thinking about the possibility to combine the positive and negative character classes, where e.g. \X would be a kind of base; I am not aware of any re engine supporting this, but I eventually found an unicode guidelines for regular expressions, which also covers this:

http://unicode.org/reports/tr18/#Subtraction_and_Intersection

It also surprises a bit, that these are all included in
Basic Unicode Support: Level 1; (even with arbitrary unions, intersections, differences ...) it suggests, that there is probably no implementation available (AFAIK) - even on this basic level, according to this guideline.

Among other features on this level, the section
http://unicode.org/reports/tr18/#Supplementary_Characters
seems useful, especially the handling of the characters beyond \uffff, also in the form of surrogate pairs as single characters.

This might be useful on the narrow python builds, but it is possible, that there would be be an incompatibility with the handling of these data in "narrow" python itself.

Just some suggestions or rather remarks, as you already implemented many advanced features and are also considering some different approaches ...:-)

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Mar  4 01:34:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 00:34:32 +0000
Subject: [issue7494] _lsprof (cProfile): Profiler.clear() keeps references to
	detroyed nodes
In-Reply-To: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>
Message-ID: <1267662872.85.0.102809510523.issue7494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sorry, but I'm unable to write a reliable unit test. You have to trust me: the patch fixes the issue and the issue does exist :-)

Fixed by r78641 (trunk), r78642 (py3k), r78643 (3.1).

Leave this issue open until the fix can be backported to 2.6 (after 2.6.5 release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________

From report at bugs.python.org  Thu Mar  4 01:41:58 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 04 Mar 2010 00:41:58 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267663318.57.0.554650078388.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

\X shouldn't be allowed in a character class because it's equivalent to \P{M}\p{M}*. It's a bug, now fixed in issue2636-20100304.zip.

I'm not convinced about the set intersection and difference stuff. Isn't that overdoing it a little? :-)

----------
Added file: http://bugs.python.org/file16424/issue2636-20100304.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:12:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 01:12:56 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1267665176.62.0.154821572008.issue4036@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I realized that the second test is just useless. The argument is str, not bytes. I wanted to test Popen(bytes, shell=True). What is the right encoding to convert a string to bytes for the file system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:26:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Mar 2010 01:26:36 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1267665996.47.0.937684396742.issue4036@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The list2cmdline function checks spaces, tabs, etc in line 521 of subprocess.py. In your first test case, it ends up checking if a string is contained in a bytes object, which is a TypeError for the str not supporting the buffer API. 

Would it be acceptable to just add "arg = str(arg)" right under the for loop? That fixes it for me, not sure of the preferred way to go about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:31:23 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 04 Mar 2010 01:31:23 +0000
Subject: [issue8051] Python 2.7 alpha 4 show wrong version number on osx
In-Reply-To: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>
Message-ID: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

Python 2.7 alpha 4 (trunk 78643) upon being invoked on terminal shows wrong version number.Since it is no longer alpha 3, it should show 'Python 2.7a4+' as version

Shashwat-Anands-MacBook-Pro:Misc l0nwlf$ python2.7
Python 2.7a3+ (trunk:78643, Mar  4 2010, 06:44:41) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse    # to verify this is python 2.7 alpha 4
>>>

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100368
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: Python 2.7 alpha 4 show wrong version number on osx
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8051>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:34:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Mar 2010 01:34:15 +0000
Subject: [issue8051] Python 2.7 alpha 4 show wrong version number on osx
In-Reply-To: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>
Message-ID: <1267666455.7.0.136505656498.issue8051@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We haven't released 2.7 alpha 4, so I wouldn't expect anything to have that version. The "+" indicates it's after the release.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8051>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:45:28 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 04 Mar 2010 01:45:28 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267667128.79.0.512634683606.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Actually I had that impression too, but I was mainly surprised with these requirements being on the lowest level of the unicode support. Anyway, maybe the relevance of these guidelines for the real libraries is is lower, than I expected.

Probably the simpler cases are adequately handled with lookarounds, e.g. (?:\w(?<!\p{Greek}))+ and the complex examples like symmetric differences seem to be beyond the normal scope of re anyway.

Personally, I would find the surrogate handling more useful, but I see, that it isn't actually the job for the re library, given that the narrow build of python doesn't support indexing, slicing, len  of these characters either...

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Mar  4 02:48:34 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 04 Mar 2010 01:48:34 +0000
Subject: [issue8051] Python 2.7 alpha 4 show wrong version number on osx
In-Reply-To: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>
Message-ID: <1267667314.18.0.878784939823.issue8051@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Python 2.7 alpha 4 will be released on 2010-03-06 according to PEP 0373. The Misc/NEWS (http://svn.python.org/projects/python/trunk/Misc/NEWS) mentions : What's New in Python 2.7 alpha 4? Since this is almost _the python 2.7 alpha 4_, I expected to show latest version number. I guess it'll show correctly after the final release i.e. two days later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8051>
_______________________________________

From report at bugs.python.org  Thu Mar  4 07:18:09 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 04 Mar 2010 06:18:09 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1267675411.87.0.390900172757.issue7540@psf.upfronthosting.co.za>
Message-ID: <9cee7ab81003032217mfeb4667g8b9de12d83ca72b6@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I'd like to hear at least one other say-so (which can be yours if you
agree this is the right thing), so there's more recognized consensus
on the matter.  We also need an explicit go-ahead from Barry as the
release manager.

At this point, the community sees only my assertion that this is a
regression from 2.6.4.

I'd be fine with a documentation improvement going in as well (as a
separate commit), but that's not a requirement to deal with the
release block.  Before the release, it would require a separate
go-ahead from the release manager.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Thu Mar  4 07:43:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Mar 2010 06:43:52 +0000
Subject: [issue4036] Support bytes for subprocess.Popen()
In-Reply-To: <1223077515.41.0.60688229915.issue4036@psf.upfronthosting.co.za>
Message-ID: <1267685032.49.0.540405754228.issue4036@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

On Windows, command lines shouldn't need to be encoded in any encoding. Instead, the unicode string should be passed to the system call as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4036>
_______________________________________

From report at bugs.python.org  Thu Mar  4 08:21:46 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Thu, 04 Mar 2010 07:21:46 +0000
Subject: [issue5277] email message.get_params() and related methods sometimes
	fail.
In-Reply-To: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
Message-ID: <1267687306.58.0.752822137964.issue5277@psf.upfronthosting.co.za>


Ryan Coyner <rcoyner at gmail.com> added the comment:

Okay, bug confirmed:

>>> m = email.message_from_string('Content-Disposition: inline; filename*0="foo \\"test"; filename*1="\\"bar"')
>>> m.get_filename()
'foo "test"; filename*1=""bar'


And here is the result with the patch applied:

>>> m = email.message_from_string('Content-Disposition: inline; filename*0="foo \\"test"; filename*1="\\"bar"')
>>> m.get_filename()
'foo "test"bar'


Attached a patch. Unit test included.

----------
nosy: +rcoyner
Added file: http://bugs.python.org/file16426/issue5277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5277>
_______________________________________

From report at bugs.python.org  Thu Mar  4 08:24:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Mar 2010 07:24:44 +0000
Subject: [issue8053] test_thread fails on Windows
In-Reply-To: <1267687484.02.0.101944239252.issue8053@psf.upfronthosting.co.za>
Message-ID: <1267687484.02.0.101944239252.issue8053@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_thread currently fails, then hangs on Windows with this output:

test_thread
Unhandled exception in thread started by <function thread1 at 0x0182E4F0>
Traceback (most recent call last):
  File "C:\Python26\lib\test\test_thread.py", line 180, in thread1
    pid = os.fork() # fork in a thread
AttributeError: 'module' object has no attribute 'fork'

I believe the logic in r78551 is reverted: the test should be executed if the sys.platform does *not* start with "win". Negating the condition makes test_thread pass on Windows.

----------
assignee: gregory.p.smith
messages: 100378
nosy: barry, gregory.p.smith, loewis
priority: release blocker
severity: normal
status: open
title: test_thread fails on Windows
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8053>
_______________________________________

From report at bugs.python.org  Thu Mar  4 09:16:53 2010
From: report at bugs.python.org (Ryan Arana)
Date: Thu, 04 Mar 2010 08:16:53 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1267690613.95.0.998597261731.issue6538@psf.upfronthosting.co.za>


Ryan Arana <ryan.arana at gmail.com> added the comment:

Added .. class:: MatchObject and .. class:: RegexObject directives.

----------
Added file: http://bugs.python.org/file16427/MatchObjectLinksFix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Thu Mar  4 09:24:55 2010
From: report at bugs.python.org (Dongying Zhang)
Date: Thu, 04 Mar 2010 08:24:55 +0000
Subject: [issue8054] "as_string" method in email's mime objects encode text
	segmentedly
In-Reply-To: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>
Message-ID: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>


New submission from Dongying Zhang <zhangdongying1986 at gmail.com>:

The as_string method in mime classes in module email.mime use base64 to encode the text, but segmentedly while the text contents non-acsii characters and is in type of unicode. This behavior confuse some of the email servers.
For example:
===================================================================
#-*- coding: utf-8 -*-
import base64
from email.mime.text import MIMEText
content = u'''Hello:
    ????????.
   Please remove this message after reading,
   and I hope this won't bother you for a long time
'''
m = MIMEText(content, 'plain', 'utf-8')
print m.as_string()
m = MIMEText(content.encode('utf-8'), 'plain', 'utf-8')
print m.as_string()
print base64.encodestring(content.encode('utf-8'))
===================================================================
The first as_string method gives:
-------------------------------------------------------------------
SGVsbG86CiAgICDov5nmmK/kuIDlsIHmtYvor5Xpgq7ku7YuCiAgIFBsZWFzZSByZW1vdmUgdGhpcyBtZXNzYWdlIGFmdGVyIA==
cmVhZGluZywKICAgYW5kIEkgaG9wZSB0aGlzIHdvbid0IGJvdGhlciB5b3UgZm9yIGEgbG9uZyB0
aW1lCg==
-------------------------------------------------------------------
Please notice that there is a '==' at the end of the first line.
The output of both the second as_string and base64.encodestring method maybe more appropriate, which is:
-------------------------------------------------------------------
SGVsbG86CiAgICDov5nmmK/kuIDlsIHmtYvor5Xpgq7ku7YuCiAgIFBsZWFzZSByZW1vdmUgdGhp
cyBtZXNzYWdlIGFmdGVyIHJlYWRpbmcsCiAgIGFuZCBJIGhvcGUgdGhpcyB3b24ndCBib3RoZXIg
eW91IGZvciBhIGxvbmcgdGltZQo=

----------
components: IO
files: test.py
messages: 100380
nosy: zhangdongying
severity: normal
status: open
title: "as_string" method in email's mime objects encode text segmentedly
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16428/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8054>
_______________________________________

From report at bugs.python.org  Thu Mar  4 09:48:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 08:48:58 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1267692538.79.0.377227899207.issue7805@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thanks Stefan for the analysis.
This patch should fix the issue, and make the buildbots happy.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16429/issue7805_process_is_alive_py3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Thu Mar  4 13:16:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 12:16:55 +0000
Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29
Message-ID: <1267705015.25.0.2118762761.issue1054943@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r78646 (trunk), r78647 (py3k), r78648 (3.1).

Leave the issue open to remember me that I have to backport to 2.6 (after the 2.6.5 release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054943>
_______________________________________

From report at bugs.python.org  Thu Mar  4 13:19:16 2010
From: report at bugs.python.org (Knut Eldhuset)
Date: Thu, 04 Mar 2010 12:19:16 +0000
Subject: [issue8055] Sleeping after acquiring RLock causes acquire to block in
	other thread
In-Reply-To: <1267705156.46.0.257665685005.issue8055@psf.upfronthosting.co.za>
Message-ID: <1267705156.46.0.257665685005.issue8055@psf.upfronthosting.co.za>


New submission from Knut Eldhuset <knut.eldhuset at gmail.com>:

In essence I have the following loop running in thread A:

while True:
    with self.lock:
        time.sleep(0.1)

I then try to acquire the lock in thread B. This blocks forever on Linux, but runs fine on Windows XP.

The following modification makes the code behave as expected on Linux:

while True:
    time.sleep(0.001)
    with self.lock:
        time.sleep(0.1)

See the attached file for the full example. Python versions are:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
[GCC 4.4.1] on linux2

and

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Library (Lib)
files: threadtest.py
messages: 100383
nosy: knutel
severity: normal
status: open
title: Sleeping after acquiring RLock causes acquire to block in other thread
versions: Python 2.6
Added file: http://bugs.python.org/file16430/threadtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8055>
_______________________________________

From report at bugs.python.org  Thu Mar  4 13:30:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Mar 2010 12:30:42 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1267705842.41.0.391543905996.issue7540@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fred, I think your report of observed breakage is sufficient to warrant rolling back the change, especially since this isn't an actual bug fix.  That is, no code that was failing to work before would be enabled to work by this fix.  (Rather, it aims to prevent broken code from being written...which it could be argued is inappropriate for a backport anyway, though you could argue it either way.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Thu Mar  4 13:53:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Mar 2010 12:53:59 +0000
Subject: [issue8054] "as_string" method in email's mime objects encode text
	segmentedly
In-Reply-To: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>
Message-ID: <1267707239.1.0.768207273362.issue8054@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Using python 2.6.4, your first example gives me an error:

UnicodeEncodeError: 'ascii' codec can't encode characters in position 11-18: ordinal not in range(128)

while your second example works, as you indicated.

So, at the moment I can not reproduce the bug.  Are you using something other than the python from python.org?

----------
components: +Library (Lib) -IO
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8054>
_______________________________________

From report at bugs.python.org  Thu Mar  4 16:27:08 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Thu, 04 Mar 2010 15:27:08 +0000
Subject: [issue8056] Piped parent's multiprocessing.Process children cannot
	write to stdout
In-Reply-To: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>
Message-ID: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>


New submission from Vilnis Termanis <vilnis.termanis at googlemail.com>:

Affects Win32 only (tested under Ubuntu 9.10-64 and XP-32 with v2.6.4). If script output is piped, child processes created via multiprocessing.Process cannot write to stdout. Also, trying to call stdout.flush() in child processes causes IOError.

Normal behaviour
----------------
C:\>stdout.py
[Parent] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Parent] message via stdout

[Child] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Child] message via stdout

Piped behaviour (same result if redirecting to file)
---------------
C:\>stdout.py | cat
[Parent] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Parent] message via stdout

[Child] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
Process Process-1:
Traceback (most recent call last):
  File "C:\Python26\lib\multiprocessing\process.py", line 232, in _bootstrap
    self.run()
  File "C:\Python26\lib\multiprocessing\process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "C:\stdout.py", line 18, in child
    stdout.flush()
IOError: [Errno 9] Bad file descriptor

----------
components: Library (Lib), Windows
files: stdout.py
messages: 100390
nosy: vilnis.termanis
severity: normal
status: open
title: Piped parent's multiprocessing.Process children cannot write to stdout
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16432/stdout.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8056>
_______________________________________

From report at bugs.python.org  Thu Mar  4 16:51:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Mar 2010 15:51:33 +0000
Subject: [issue8055] Sleeping after acquiring RLock causes acquire to block in
	other thread
In-Reply-To: <1267705156.46.0.257665685005.issue8055@psf.upfronthosting.co.za>
Message-ID: <1267717893.61.0.355012439121.issue8055@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You are just having wrong expectations. Releasing a lock doesn't guarantee that any other thread waiting on it will be scheduled preemptively. So, if you re-acquire the lock immediately, the other thread will not necessarily have had the opportunity of running at all. Whether or not threads do get switched at that point is highly system-dependent.

There are many synchronisation primitives you can use (locks, events, queues, condition variables...), each for a different purpose. I suggest you post on comp.lang.python if you want more help on the subject.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8055>
_______________________________________

From report at bugs.python.org  Thu Mar  4 17:03:47 2010
From: report at bugs.python.org (Joaquin Cuenca Abela)
Date: Thu, 04 Mar 2010 16:03:47 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267718627.29.0.087836597421.issue7143@psf.upfronthosting.co.za>


Joaquin Cuenca Abela <e98cuenc at gmail.com> added the comment:

Hi,

I've never before made a patch to Python, so take it with care.

A couple of comments, I reused a test where all the attachments contained an ending newline, except for the base64 one (conveniently...)

I think the comment in _bdecode that Andreas quoted before refers to base64.encodestring add an extra \n to de encoded string, but base64.decodestring can work with and without this extra \n:

>>> import base64
>>> base64.decodestring('MTIzCg==')
'123\n'
>>> base64.decodestring('MTIzCg==\n')
'123\n'

So it's not necessary to work around this in _bdecode. Let me know if it looks good to you.

----------
keywords: +patch
Added file: http://bugs.python.org/file16433/b64crlf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Thu Mar  4 17:29:46 2010
From: report at bugs.python.org (Stephen White)
Date: Thu, 04 Mar 2010 16:29:46 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1267720186.84.0.627398479688.issue6792@psf.upfronthosting.co.za>


Stephen White <stephen-python.org at randomstuff.org.uk> added the comment:

32bit apps can query the 64bit registry, using the appropriate security and access rights options such as KEY_WOW64_64KEY (0x0100).

Similarly KEY_WOW64_32KEY can be used for 64bit apps to read/write the 32bit registry without having to have knowledge of how the Wow6432Nodes are arranged .

These mean that a 64bit aware app, whether compiled as 64 or 32 bits, can access the alternative view of the registry.

http://msdn.microsoft.com/en-us/library/ms724897(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx

For example if you have both 64 and 32 bit copies of Python installed then a Python app running under the 32bit copy of Python can query the location of the 64bit copy of Python using code like:
key64 = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "Software\\Python\\PythonCore\\2.6\\PythonPath", 0, _winreg.KEY_READ + 0x0100)
_winreg.QueryValue(key, "")

C code can do similarly.

----------
nosy: +Stephen.White

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Thu Mar  4 17:46:33 2010
From: report at bugs.python.org (Andreas Poisel)
Date: Thu, 04 Mar 2010 16:46:33 +0000
Subject: [issue8057] Impreciseness in bz2 module documentation?
In-Reply-To: <1267721193.52.0.548079190906.issue8057@psf.upfronthosting.co.za>
Message-ID: <1267721193.52.0.548079190906.issue8057@psf.upfronthosting.co.za>


New submission from Andreas Poisel <ap at acat.cc>:

A string in Python 3 is a sequence of unicode characters, right?  The
documentation of the bz2 module says:

8<------------------------------------------------------------------
class bz2.BZ2File(filename, mode='r', buffering=0, compresslevel=9)
[...]
write(data)
    Write string data to file. Note that due to buffering, close() may be
    needed before the file on disk reflects the data written.
[...]
8<------------------------------------------------------------------

So the documentation wants me to pass a "string data" to the write() method:

8<------------------------------------------------------------------
>>> import bz2
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write('Test')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: must be bytes or buffer, not str
8<------------------------------------------------------------------

So what write() really wants is a byte array or an encoded string:

8<------------------------------------------------------------------
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write(bytes('Test', encoding='iso-8859-1'))
... 
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write('Test'.encode('iso-8859-1'))
... 
8<------------------------------------------------------------------

Is this an inaccuracy of the documentation or did I get something wrong?

----------
messages: 100397
nosy: Haudegen
severity: normal
status: open
title: Impreciseness in bz2 module documentation?
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8057>
_______________________________________

From report at bugs.python.org  Thu Mar  4 17:57:09 2010
From: report at bugs.python.org (daz)
Date: Thu, 04 Mar 2010 16:57:09 +0000
Subject: [issue8058] incorrect behavior of get_filename() method in email pkg
In-Reply-To: <1267721829.4.0.200487956077.issue8058@psf.upfronthosting.co.za>
Message-ID: <1267721829.4.0.200487956077.issue8058@psf.upfronthosting.co.za>


New submission from daz <admin at dazadi.com>:

get_filename() does not parse the Content-Type header for a "name" parameter. This is the old-style RFC 1341 header. Example:

Content-Type: application/octet-stream;
 name="somefile.pdf"
Content-Transfer-Encoding: base64

The email package documentation states:

get_filename([failobj])
    Return the value of the filename parameter of the Content-Disposition header of the message. If the header does not have a filename parameter, this method falls back to looking for the name parameter. If neither is found, or the header is missing, then failobj is returned...

As documented, get_filename() falls back to looking for the "name"
parameter in the Content-Disposition header. Instead, it should fall
back to looking for the "name" parameter in the Content-Type header.

----------
components: Library (Lib)
messages: 100399
nosy: daz
severity: normal
status: open
title: incorrect behavior of get_filename() method in email pkg
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8058>
_______________________________________

From report at bugs.python.org  Thu Mar  4 18:34:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Mar 2010 17:34:59 +0000
Subject: [issue8058] incorrect behavior of get_filename() method in email pkg
In-Reply-To: <1267721829.4.0.200487956077.issue8058@psf.upfronthosting.co.za>
Message-ID: <1267724099.65.0.612430795486.issue8058@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duplicate of issue 7082.  However, I fixed the documentation in r78656.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Patch for get_filename in email.message when content-disposition is missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8058>
_______________________________________

From report at bugs.python.org  Thu Mar  4 18:58:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 17:58:52 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1267725532.14.0.612429931179.issue2973@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

On Gentoo buildbots (2.x and 3.x), there's still the same compiler warnings:
http://www.python.org/dev/buildbot/all/builders/x86%20gentoo%20trunk/builds/5899

/home/buildslave/python-trunk/trunk.norwitz-x86/build/Modules/_ssl.c:706: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/home/buildslave/python-trunk/trunk.norwitz-x86/build/Modules/_ssl.c:710: warning: passing arg 2 of pointer to function from incompatible pointer type

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Thu Mar  4 19:02:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Mar 2010 18:02:01 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267725721.8.0.309780243152.issue7143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for working on this.

For the most part your patch looks fine.  Two comments: (1) it concerns me that by co-opting the existing test, we are no longer testing that decoding does not introduce a spurious newline :).  (2) I think we should add a comment in _bdecode that it used to do more and is retained now only for backward compatibility.

I don't particularly like proliferating test files, and I plan to fix that in email6, but for now I think you should just add a new test file based on msg_10, and a test that uses it.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Thu Mar  4 19:12:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 18:12:34 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1267726354.39.0.44961994863.issue1537721@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

according to the buidbots, it hurts some platforms: Windows XP, Windows 7 and sparc Solaris10


 * sparc solaris10

test_writerows (test.test_csv.Test_Csv) ... ok

======================================================================
FAIL: test_write_simple_dict (test.test_csv.TestDictFields)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_csv.py", line 607, in test_write_simple_dict
    self.assertEqual(fileobj.read(), "10,,abc\r\n")
AssertionError: 'f1,f2,f3\r\n' != '10,,abc\r\n'

----------------------------------------------------------------------
Ran 84 tests in 17.335s

FAILED (failures=1)
test test_csv failed -- Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_csv.py", line 607, in test_write_simple_dict
    self.assertEqual(fileobj.read(), "10,,abc\r\n")
AssertionError: 'f1,f2,f3\r\n' != '10,,abc\r\n'

 * x86 XP and x86 Windows7

test_csv
test test_csv failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_csv.py", line 604, in test_write_simple_dict
    writer.writerow({"f1": 10, "f3": "abc"})
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\csv.py", line 148, in writerow
    return self.writer.writerow(self._dict_to_list(rowdict))
IOError: [Errno 0] Error

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Thu Mar  4 19:27:54 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Mar 2010 18:27:54 +0000
Subject: [issue8053] test_thread fails on Windows
In-Reply-To: <1267687484.02.0.101944239252.issue8053@psf.upfronthosting.co.za>
Message-ID: <1267727274.14.0.604412819941.issue8053@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

right that logic is inverted.  my bad.  its fine in trunk already as it uses @unittest.skipIf there.  that decorator doesn't exist in 2.6.

fixed in r78659

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8053>
_______________________________________

From report at bugs.python.org  Thu Mar  4 19:48:24 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 04 Mar 2010 18:48:24 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1267728504.91.0.853497399552.issue1537721@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Testing on Windows with this:

Index: Lib/test/test_csv.py
===================================================================
--- Lib/test/test_csv.py	(revision 78430)
+++ Lib/test/test_csv.py	(working copy)
@@ -9,6 +9,7 @@
 import tempfile
 import csv
 import gc
+import io
 from test import test_support
 
 class Test_Csv(unittest.TestCase):
@@ -595,7 +596,7 @@
     ### "short" means there are fewer elements in the row than fieldnames
     def test_write_simple_dict(self):
         fd, name = tempfile.mkstemp()
-        fileobj = os.fdopen(fd, "w+b")
+        fileobj = io.open(fd, 'w+b')
         try:
             writer = csv.DictWriter(fileobj, fieldnames = ["f1", "f2", "f3"])
             writer.writeheader()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Thu Mar  4 20:14:46 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 04 Mar 2010 19:14:46 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1267730086.94.0.577329977441.issue7540@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Reopening; per discussion on IRC, the change needs to be reverted on the other three branches to which it was applied.

If code changes are needed to make unsupported usage fail early, they need to be considered carefully and only applied as a new feature.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Thu Mar  4 20:23:51 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 04 Mar 2010 19:23:51 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1267730631.67.0.856824487237.issue1537721@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Committed in r78660 after positive comment from briancurtin re Windows. Hopefully this fixes Solaris, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:12:48 2010
From: report at bugs.python.org (steven Michalske)
Date: Thu, 04 Mar 2010 20:12:48 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

I started using the .format() on strings and was surprised that it was lacking an built in format specifier for engineering notation.

For those unfamiliar with engineering notation it puts the exponent of the number in modulo 3 so that it is in alignment with SI prefixes  such as kilo, micro, milli, etc...

11,000 in engineering notation would be 11.000e3

At this time if i want engineering notation I need to use a function to convert it to a string and then print the string.  Most inconvenient for a standard formatting used in the engineering fields.

----------
messages: 100413
nosy: hardkrash
severity: normal
status: open
title: PEP 3101 string formatting missing engineering presentation type for floating point
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:15:11 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Mar 2010 20:15:11 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1267733711.47.0.250694605109.issue7755@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Let's go back to using this file.  It's taken from Python 1.5.1 and it's me saying "My hovercraft is full of eels".  I've already signed the contributor agreement.

----------
Added file: http://bugs.python.org/file16434/audiotest.au

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:24:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Mar 2010 20:24:20 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267734260.59.0.808612061802.issue8060@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This would be a new feature, so it can't be added to 2.6 or 3.2. It's an interesting idea, though.

----------
assignee:  -> eric.smith
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:31:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Mar 2010 20:31:38 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267734698.44.0.983095834585.issue8060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Not likely to make 2.7, either, unless someone comes forward with a patch real quick.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:41:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Mar 2010 20:41:55 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267735315.91.0.0582339466789.issue8060@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Before 2010-04-03, see http://www.python.org/dev/peps/pep-0373/.

New features can be added only in alpha versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Thu Mar  4 21:59:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 20:59:02 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1267736342.85.0.960532632042.issue2777@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I experienced this hang with Linux AMD64.

It occurs in test_send_signal.
It is because signal.SIGINT is not always handled (see #3137).

As a workaround, there's 2 choices: add a delay between Popen and send_signal, or retry SIGINT 2 or 3 times.

Windows should not be affected, because it uses signal SIGTERM in the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2777>
_______________________________________

From report at bugs.python.org  Thu Mar  4 22:46:46 2010
From: report at bugs.python.org (steven Michalske)
Date: Thu, 04 Mar 2010 21:46:46 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

It is a common practice to separate hex digits with a "thousands" separator every 4 hex digits.

0x1234_abcd

Although python does not accept the _ as a thousands separator in hex notation, neither is the thousands separator in base 10


Snippet that prints hex thousands with a _ separator

number = 0xef5678abcd1234

def hex_thousands(number):
    txt="{0:X}".format(number)
    txt_out = ""
    i = range(-4,-1 * (len(txt) + 4), -4)
    ii = i[:]
    ii.insert(0, None)
    for (j, k) in zip(i, ii):
        if txt_out:
            txt_out = "_" + txt_out
        txt_out = txt[j:k] + txt_out
    return txt_out

print hex_thousands(number)

----------
messages: 100422
nosy: hardkrash
severity: normal
status: open
title: PEP 3101 string formatting missing hexadecimal separator _ for every 4 hex digits
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Thu Mar  4 23:00:46 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Thu, 04 Mar 2010 22:00:46 +0000
Subject: [issue8048] doctest assumes sys.displayhook hasn't been touched
In-Reply-To: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>
Message-ID: <1267740046.41.0.0350802273068.issue8048@psf.upfronthosting.co.za>


Noam Yorav-Raphael <noamraph at gmail.com> added the comment:

Ok, here's a patch (against current svn of Python 2) with a test case.

I had to fix three tests which combined pdb and doctest, since now, when run under doctest, pdb steps into the displayhook because it's a Python function and not a built-in function. The fix is just to return from the displayhook.

If you wish, I can prepare a patch for Python 3.

----------
Added file: http://bugs.python.org/file16436/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8048>
_______________________________________

From report at bugs.python.org  Thu Mar  4 23:13:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 22:13:56 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1267740836.43.0.277388526955.issue2777@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Re-enabled on r78662 and r78663.
Buildbots seems happy, except Windows XP + Cygwin buildbot:

======================================================================
FAIL: test_kill (test.test_subprocess.Win32ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_subprocess.py", line 768, in test_kill
    self.assertNotEqual(p.wait(), 0)
AssertionError: 0 == 0

======================================================================
FAIL: test_send_signal (test.test_subprocess.Win32ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_subprocess.py", line 761, in test_send_signal
    self.assertNotEqual(p.wait(), 0)
AssertionError: 0 == 0

======================================================================
FAIL: test_terminate (test.test_subprocess.Win32ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_subprocess.py", line 775, in test_terminate
    self.assertNotEqual(p.wait(), 0)
AssertionError: 0 == 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2777>
_______________________________________

From report at bugs.python.org  Thu Mar  4 23:22:47 2010
From: report at bugs.python.org (Joaquin Cuenca Abela)
Date: Thu, 04 Mar 2010 22:22:47 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267741367.75.0.59767312627.issue7143@psf.upfronthosting.co.za>


Joaquin Cuenca Abela <e98cuenc at gmail.com> added the comment:

I added a new subpart to msg_10.txt, that keeps the previous test and also tests the new behavior. Let me know if it's ok like this or if you still prefer to create a different msg file for testing this.

Thanks,

----------
versions: +Python 2.5
Added file: http://bugs.python.org/file16438/b64crlf-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Thu Mar  4 23:42:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Mar 2010 22:42:37 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1267742557.65.0.551284652775.issue7805@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Sometimes it triggers a different issue, with patch applied (ia64 Ubuntu trunk):

test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_multiprocessing.py", line 1075, in test_pool_worker_lifetime
    while countdown and not all(w.is_alive() for w in p._pool):
  File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_multiprocessing.py", line 1075, in <genexpr>
    while countdown and not all(w.is_alive() for w in p._pool):
  File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/multiprocessing/process.py", line 132, in is_alive
    self._popen.poll()
  File "/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] No child processes

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:09:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 23:09:57 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

_PyGILState_Init() initialize autoInterpreterState variable. This variable have to be set before the first call to PyGILState_Ensure().

The problem is that _PyGILState_Init() is called late: at the end of Py_InitializeEx(). It's called after initsite(), whereas initsite() may need to call _PyGILState_Init().

Example: add the following lines at the end of site.py:
---
import readline
import rlcompleter
readline.parse_and_bind("tab: complete")
raw_input("press TAB")
---
Run an interpreter and press TAB:
---
$ ./python
press TABpython: Python/pystate.c:595: PyGILState_Ensure: Assertion `autoInterpreterState' failed.
Abandon
---

Other example of functiions using _PyGILState_Init(): _PyObject_Dump() (useful for debug), sqlite module, os.popen*(), ctypes Python callbacks, etc.

I don't know the right place for _PyGILState_Init() in Py_InitializeEx(). _PyGILState_Init() calls the following functions:
 - PyThread_get_thread_ident()
 - PyThread_allocate_lock()
 - PyThread_acquire_lock()
 - PyThread_release_lock()
 - Py_FatalError() (on error)

None of these function use Python functions, so _PyGILState_Init() can be called very early. The earliest position is just after the call to PyThreadState_New(), before PyThreadState_Swap(). It tested it and it works correctly.

If _PyGILState_Init() is called before PyThreadState_Swap(), PyThreadState_Swap() can be simplified (it doesn't need to check if GIL is initialized or not). Attached patch implement that.

--

I hit this bug when I was debuging Python: I added a call to _PyObject_Dump() which stopped Python (assertion error) because the GIL was not initialized :-/

I already hitted this bug some weeks ago when I was working on the thread state preallocation when creating a new thread: #7544.

----------
files: gil_state_init-trunk.patch
keywords: patch
messages: 100432
nosy: haypo
severity: normal
status: open
title: Call _PyGILState_Init() earlier in Py_InitializeEx()
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16439/gil_state_init-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:12:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 23:12:08 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

haypo> I already hitted this bug some weeks ago when I was working 
haypo> on the thread state preallocation when creating a new thread:
haypo> #7544.

According to msg97715: it was indirectly the same issue, call _PyObject_Dump() while the GIL is not initialized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:14:46 2010
From: report at bugs.python.org (Oliver Sturm)
Date: Thu, 04 Mar 2010 23:14:46 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>


New submission from Oliver Sturm <oliver at sturmnet.org>:

The code in regextest.py (attached) uses a large regex to analyze a piece of text. I have tried this test program on two Macs, using the standard Python distributions.

On a MacBook, 2.4 GHz dual core, Snow Leopard with Python 2.6.1, it takes 0.08 seconds
On a MacPro, 2.something GHz 8 core, Leopard with Python 2.5.1, it takes 0.09 seconds

Now I've also tried it on several Linux machines, all of them running Ubuntu. They are all extremely slow. The machine I've been testing with now is a 2.0 GHz dual core machine with Python 2.5.2. A test run of the program takes 97.5 (that's not a typo) seconds on this machine, 1200 times as long as on the Macs.

----------
components: Regular Expressions
files: regextest.py
messages: 100434
nosy: michael.foord, olivers
severity: normal
status: open
title: Large regex handling very slow on Linux
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file16440/regextest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:25:35 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Mar 2010 23:25:35 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267745135.94.0.762065745211.issue8064@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I think it's likely that the test program does drastically different things on Linux than it does on OS X:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import regextest
>>> len(regextest.makew())
93455
>>>

Compare to:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import regextest
>>> len(regextest.makew())
47672
>>> 


If I modify it to use 65535 (sys.maxunicode on OS X) and then run it on Linux, it completes quite quickly.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:27:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 23:27:43 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267745263.93.0.388954751256.issue8064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Results on Linux (Debian Sid) with different Python versions:
 * Python 2.4.6: 14112.8 ms
 * Python 2.5.5: 14246.7 ms
 * Python 2.6.4+: 14753.4 ms
 * Python trunk (2.7a3+): 69.3 ms

It looks like re engine was optimized in trunk :-)

Note: I replaced stopwatch by time.time() and used 100 iterations instead of 500 iterations. Values are not important, only the ratio between the different results.

--

exarkun> I think it's likely that the test program does drastically
exarkun> different things on Linux than it does on OS X

sys.maxunicode should be different on the two OS.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:29:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 23:29:04 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267745344.91.0.565272259495.issue8064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, my benchmark was wrong. It looks like the result depends sys.maxunicode:

$ python2.4 -c "import sys; print sys.maxunicode"
1114111
$ python2.5 -c "import sys; print sys.maxunicode"
1114111
$ python2.6 -c "import sys; print sys.maxunicode"
1114111
$ ./python -c "import sys; print sys.maxunicode"
65535

The last on (./python) is Python trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:33:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Mar 2010 23:33:58 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267745638.6.0.110091560376.issue8064@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So is it reasonable / unavoidable that UCS4 builds should be 1200 times slower at regex handling?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 00:37:28 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Mar 2010 23:37:28 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267745848.85.0.501782587141.issue8064@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> So is it reasonable / unavoidable that UCS4 builds should be 1200 times slower at regex handling?

No, but it's probably reasonable / unavoidable that a more complex regex should be some number of times slower than a simpler regex.

On Linux, the regex being constructed is more complex.  On OS X, it's simpler.  The reason for the difference is that the Linux build is UCS4, but that's only because the unicode character width is being used as part of the function that constructs the regular expression.

If you take this variable out of that function, so that it returns the same string regardless of the width of a unicode character, then performance evens out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 01:00:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Mar 2010 00:00:33 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267747233.72.0.378155290676.issue8064@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A workaround could be using [^\W\d], but this includes some extra chars in the categories Pc, Nl, and No that maybe you don't want. Generate a list of chars in these 3 categories and add them in the regex should be cheaper though.
Since this is not a bug of Python I'll close this issue.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 01:21:35 2010
From: report at bugs.python.org (Jan Killian)
Date: Fri, 05 Mar 2010 00:21:35 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1267748495.94.0.602887912766.issue444582@psf.upfronthosting.co.za>


Jan Killian <jan.killian at gmail.com> added the comment:

Adapted Brian Curtin's http://bugs.python.org/file15381/
shutil_which.patch and made another reference implementation as a standalone module including the following fixes:

* uses ``PATHEXT`` on Windows
* searches current directory before ``PATH`` on Windows, but not before an explicitly passed path
* accepts both string or iterable for an explicitly passed path, or pathext
* accepts an explicitly passed empty path, or pathext (either '' or [])
* does not search ``PATH`` for files that have a path specified in their name already

Use any of these changes in the final shutil patch if you like to. The shutil module has availability 'Unix, Windows' after all.

----------
nosy: +iki
Added file: http://bugs.python.org/file16441/which.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Fri Mar  5 02:02:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 01:02:04 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1267750924.63.0.535205045403.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a fix for object.c (object_pyunicode_asstring-py3k.patch):

- PyObject_GenericGetAttr(): Replace PyErr_Format("... %.400s", ..., _PyUnicode_AsString(name)) by PyErr_Format("... %U", ..., name), as done in PyObject_GenericSetAttr(). Note that the string will no more be truncated to 400 bytes
- PyObject_GetAttr(), PyObject_SetAttr(): Catch _PyUnicode_AsString() error

It fixes the crash getattr(1, "\uDAD1\uD51E") (used as a test in the patch).

----------
title: Python 3.1 segfaults when invalid UTF-8 characters are	passed from command line -> Check that _PyUnicode_AsString() result is not NULL
Added file: http://bugs.python.org/file16442/object_pyunicode_asstring-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar  5 02:11:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 01:11:59 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1267751519.28.0.0450804721369.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fix for _ssl module: replace _PyUnicode_AsString() by PyArg_ParseTuple() with PyUnicode_FSConverter. This change fixes also ssl for file system encoding different than utf8. I added a test on surrogates.

The test fails if surrogates can be encoded to the file system encoding (maybe on Windows?).

----------
Added file: http://bugs.python.org/file16443/ssl_rand_egd_unicode-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar  5 03:14:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Mar 2010 02:14:32 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267755272.85.0.0809926883292.issue8064@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a proof that you can have an equivalent regex without including all the 'letter chars' (tested on both narrow and wide builds):
>>> s = u''.join(unichr(c) for c in range(sys.maxunicode))
>>> diff = set(re.findall(u'[^\W\d]', s, re.U)) ^ set(re.findall(u'[%s_-]' % makew(), s, re.U))
>>> diff.remove('-')
>>> re.findall(u'(?:[^\W\d%s]|-)' % ''.join(diff), s, re.U) == re.findall(u'[%s_-]' % makew(), s, re.U)
True

(I don't like the way I included the '-' but I couldn't find anything better.)
It looks however that most of the time is spent during the findall and from a quick benchmark it seems that my regex is slower (even if it's shorter and it compiles faster).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 03:26:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Mar 2010 02:26:43 +0000
Subject: [issue887237] Machine integers
In-Reply-To: <d38f5331003041821q2620ff93m4af12c993712b432@mail.gmail.com>
Message-ID: <20100304212634.7ce45721@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Fri, 05 Mar 2010 02:21:30 +0000,
Alexander Belopolsky <report at bugs.python.org> a ?crit :
> 
> Code duplication is unavoidable because the goal is to give access to
> machine arithmetics which means (# types) x (# operations) of very
> similar looking functions. I considered reducing (perceived) code
> duplication through some pre-processor magic, but doing so would make
> code much harder to understand and almost impossible to debug.

Carefully written macros shouldn't be hard to understand.
At least there wouldn't be the risk of overlooking one of the methods
when making modifications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Fri Mar  5 03:46:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Mar 2010 02:46:29 +0000
Subject: [issue887237] Machine integers
In-Reply-To: <1267756194.38.0.279570235514.issue887237@psf.upfronthosting.co.za>
Message-ID: <d38f5331003041845x78579b23q1b2ee463636679b1@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I would like to hear from Thomas before introducing macros in this
code.  I tried to follow the style of cfield.c which shows similar
code duplication.

There are also some questions that need to be answered before
polishing the code.

1. Should mixed arithmetics be supported?
2. Should we do anything special about floating point operations?
Wrapping them in PyFPE_START/STOP_PROTECT?
3. Should we support in-place operations?
4. Bitwise operations on integers?

On Thu, Mar 4, 2010 at 9:29 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> Look at Modules/operator.c for example of an effective use of macros to minimize code duplication.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue887237>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Fri Mar  5 07:34:15 2010
From: report at bugs.python.org (Dongying Zhang)
Date: Fri, 05 Mar 2010 06:34:15 +0000
Subject: [issue8054] "as_string" method in email's mime objects encode text
	segmentedly
In-Reply-To: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>
Message-ID: <1267770855.36.0.293124175355.issue8054@psf.upfronthosting.co.za>


Dongying Zhang <zhangdongying1986 at gmail.com> added the comment:

Hello R. David Murray:

Thanks for your care.

The examples I given both in message and file is just the same. You got the 'UnicodeEncodeError' because your system default encoding is ascii. The declaration of encoding at the top didn't help with this situation.

To solve this, you can add following lines at the import part of the codes.
=====================================================================
import sys
reload(sys)
sys.setdefaultencoding('utf-8')
=====================================================================
Then it should work by executing it directly or in a terminal (but not in IDLE).

You can try the new file I submit. Thanks!

----------
Added file: http://bugs.python.org/file16446/utf8_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8054>
_______________________________________

From report at bugs.python.org  Fri Mar  5 10:13:36 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 05 Mar 2010 09:13:36 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1267780416.33.0.22165829243.issue1537721@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Both the solaris and windows slaves seem to have succeeded this time.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Fri Mar  5 10:23:14 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 05 Mar 2010 09:23:14 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267780994.24.0.243694488764.issue7670@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Applied in trunk. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Fri Mar  5 10:24:41 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 05 Mar 2010 09:24:41 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1267781081.65.0.502376690839.issue7478@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Fixed in trunk now. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7478>
_______________________________________

From report at bugs.python.org  Fri Mar  5 10:38:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 09:38:49 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267781929.88.0.873811329379.issue8062@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

How common is this 'common practice'?  Could you point to some publicly available examples? Are there other languages that have built-in facilities for dealing with hexadecimal representations of integers in this way?

I think I've seen hex strings separated by spaces every four digits, and by spaces or colons every two digits (though the latter was usually used for something that's better seen as a sequence of bytes rather than a hexadecimal representation of a large integer).  I've rarely seen the underscore separation that you describe, but perhaps that's because I haven't been looking in the right places.

Do you have a concrete proposal for amending the formatting mini-language syntax to support this?  Perhaps you could run this past the python-ideas mailing list to try to get support and to thrash out the details of a possible specification?

To me this seems to be adding yet more complication to an already complicated formatting mini-language for something that few people will ever need, so I'd be -1 on this as it stands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Fri Mar  5 10:50:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 09:50:39 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267782639.5.0.686542346106.issue8062@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this for now;  if you want to pursue this, please take the suggestion to the python-ideas mailing list.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Fri Mar  5 11:06:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 10:06:46 +0000
Subject: [issue8060] PEP 3101 string formatting missing engineering
	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267783606.52.0.493047600087.issue8060@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Before a patch, there needs to be a concrete proposal:  how would this be specified, and what would the precise semantics be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8060>
_______________________________________

From report at bugs.python.org  Fri Mar  5 11:38:58 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 10:38:58 +0000
Subject: [issue8066] OS X installer: readline module breaks when targeting on
	10.5 or 10.6
In-Reply-To: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>
Message-ID: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

2.6.5 release blocker

Changes for Issue6877 to enable the readline module to use the
native OS X editline library instead of GNU readline introduce
a problem for OS X installer builds or other builds using
MACOSX_DEPLOYMENT_TARGET.  The test in setup.py to determine
whether to search for a non-system library is based solely 
on the OS level of the build system and not the minimum
deployment target level.  Without this patch to setup.py,
10.3- or 10.4-targeted installer builds on 10.5 or 10.6
will fail to search for the installer-supplied GNU readline
*and* will be dynamically linked with the crippled
10.4u SDK version of editline, thereby causing the readline
module to crash on all levels of OS X.  (The installer build
needs to continue to supply GNU readline because of the broken
10.4 editline).

Symptoms vary by OS level and arch but include bus errors and
test failures such as:

test_readline failed --  line 29, in testHistoryUpdates
    self.assertEqual(readline.get_current_history_length(), 2)
AssertionError: 8448056 != 2
[10.5]: Python(71826,0xa0c18820) malloc: *** error for object 0x80e994: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
[10.6]: Python(25154,0xa0b73500) malloc: *** error for object 0x80df94: pointer being freed was not allocated
[10.4]: test_readline skipped -- dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/readline.so, 2): Symbol not found: _rl_free_line_state


Patches supplied for 26, trunk(27), and py3k(32), but *not*
31 as the readline changes have not been backported to 31.

The trunk and 2.6 versions of the patch also correct a version
test in setup.py that causes builds on 10.6 to be flooded with
OS X deprecation warnings.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-setup-26.txt
messages: 100463
nosy: barry, ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X installer: readline module breaks when targeting on 10.5 or 10.6
type: crash
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16448/issue-sl-setup-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8066>
_______________________________________

From report at bugs.python.org  Fri Mar  5 12:02:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 11:02:57 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When building on 10.6 with a deployment target of 10.3 or 10.4,
various build errors occur, like:
    warning: 'struct winsize' declared inside parameter list
    error: 'struct rusage' has no member named 'ru_maxrss'

The problem is a test in configure.in that isn't prepared to handle
a two-digit Darwin kernel version: OS X 10.6 is Darwin 10.  The
patches backport the fix from trunk(2.7) to 2.6, 3.1, and py3k(3.2).
(As usual, autoconf needs to be run after applying to update configure.)

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-configure-26.txt
messages: 100465
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X Installer: build errors on 10.6 when targeting 10.4 and earlier
type: compile error
versions: Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16451/issue-sl-configure-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Fri Mar  5 12:35:19 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 11:35:19 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Since the split of Python3, the OS X installer build scripts in the
four active source trees have diverged due to multiple edits at
different times such that most changes can no longer be easily
merged across branches without significant hand editing, even
though the scripts differ only trivially in functionality.

The attached patches for the 26, trunk(27), 31, and py3k(31) trees result in an identical build script across all four with execution
tests for the following python3 differences:
    1. Installer packages "PythonProfileChanges" and
       "PythonSystemFixes" default to "not selected for install"
    2. Include "--with-computed-gotos" on configure.
    3. Do not change Framework/Current link during install.

Also included is another patch which, if applied, would restore the change made to trunk in r77030 to change the default installation
state of the UNIX Tools Package from "selected" to "not selected",
thus by default not installing any symlinks in /usr/local/bin. 
It's not clear why this change should be made and only to trunk,
at that.  If it is applied, it should be accompanied by appropriate
NEWS and Installer README changes as it would affect how many users currently access python on OS X.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-installer-26.txt
messages: 100467
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X Installer: merge python2 and python3 build-installer.py script
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16454/issue-sl-installer-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:13:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 12:13:53 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1267791233.49.0.0382462451905.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MaL> If you want a fail-safe stringified version of a Unicode object,
MaL> your only choice is to create a new API that does error checking,
MaL> properly clears the error and then returns a reference to a constant
MaL> string, e.g. "<repr-error>".

I wrote a function _PyUnicode_AsStringOrDefault(unicode, default_str) which call _PyUnicode_AsStringAndSize() and return the default_str on error. It can be used in error handler (places where you don't really like to reraise new error) or if you don't care about (unicode) errors.

----------
Added file: http://bugs.python.org/file16458/pyunicode_asstringordefault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:38:57 2010
From: report at bugs.python.org (Jan Killian)
Date: Fri, 05 Mar 2010 12:38:57 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1267792737.55.0.716123768471.issue444582@psf.upfronthosting.co.za>


Jan Killian <jan.killian at gmail.com> added the comment:

Updated version of reference implementation as a standalone module
    * changed interface: which_files() returns generator, which() returns first match,
      or raises IOError(errno.ENOENT)
    * updated doctest

Made this to more closely resemble the 'which' command behavior, and to make the typical use case simpler. The generator interface is still a good idea imho, so it's kept as which_files(). I'm already using the reference implementation module flawlessly, so I don't see any other changes needed on my side. Your ideas are welcome of course.

----------
Added file: http://bugs.python.org/file16459/which.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:44:46 2010
From: report at bugs.python.org (Jeremy Sanders)
Date: Fri, 05 Mar 2010 12:44:46 +0000
Subject: [issue8069] struct documentation problem and suggestion to add fixed
	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>


New submission from Jeremy Sanders <jeremy at jeremysanders.net>:

The struct documentation at http://docs.python.org/library/struct.html says:

Standard size and alignment are as follows: no alignment is required for any type (so you have to use pad bytes); short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and double are 32-bit and 64-bit IEEE floating point numbers, respectively. _Bool is 1 byte.

long on linux x86-64 is not 4 bytes. It is 8 bytes long:

xpc1:~:$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57) 
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.calcsize('L')
8
>>> struct.calcsize('l')
8

It is 4 bytes on i386, however. The documentation should say that long is 8 bytes on linux x86-64.

Also, would it not be a good idea to add struct sizes with specific data sizes, e.g. 1 byte, 2 bytes, 4 bytes, 8 bytes, so that it is easier to write cross-platform code?

----------
components: Library (Lib)
messages: 100470
nosy: jeremysanders
severity: normal
status: open
title: struct documentation problem and suggestion to add fixed size formats
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8069>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:53:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 12:53:13 +0000
Subject: [issue8069] struct documentation problem and suggestion to add fixed
	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267793593.35.0.187857030013.issue8069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Please note that the docs distinguish 'standard size and alignment' from 'native size and alignment'.  The standard size (which is what you get if your struct format string doesn't start with '<', '>', '=' or '!') does exactly what you suggest:  it gives struct codes a fixed size that's independent of platform.

>>> import struct
>>> struct.calcsize('L')   # native size and alignment
8
>>> struct.calcsize('<L')  # standard size and alignment
4

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8069>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:55:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 12:55:34 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1267793734.04.0.685554937344.issue8070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyRun_InteractiveLoop() doesn't specify the possible return value. It's maybe because it's always zero and that the error are not handled :-)
http://docs.python.org/c-api/veryhigh.html#PyRun_InteractiveLoop

PyRun_InteractiveOneFlags() documentation is also wrong: the result can only be: 0 (succes), -1 (exception raised) or E_EOF (=11, end of file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:56:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 12:56:17 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1267793777.34.0.337116244426.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch for pythonrun.c:
 - catch _PyUnicode_AsString() error in get_codeset(): very unlikely, codeset is the result of nl_langinfo() and is ASCII only
 - catch _PyUnicode_AsString(sys.stdin.encoding) error in PyRun_InteractiveOneFlags()
 - use _PyUnicode_AsStringOrDefault() for ps1 and ps2: use ps1="" and/or ps2="" on unicode error. I don't know if it's the best option. Display the error is maybe a better idea.

It's possible to raise to test the error on sys.stdin.encoding by adding the following lines to site.py:

class Stdin: pass
sys.stdin = Stdin()
sys.stdin = "\xdc80"

See also #8070: PyRun_InteractiveLoopFlags() doesn't handle errors :-/

----------
Added file: http://bugs.python.org/file16461/pythonrun-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar  5 13:57:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 12:57:56 +0000
Subject: [issue8069] struct documentation problem and suggestion to add fixed
	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267793876.45.0.234308787646.issue8069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Oops.  In "... struct format string doesn't start with.. " in my comment above, replace "doesn't start with" with "starts with".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8069>
_______________________________________

From report at bugs.python.org  Fri Mar  5 14:00:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Mar 2010 13:00:35 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1267794035.18.0.0329795930606.issue6697@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

About the _PyUnicode_AsStringOrDefault() patch:

Since the _PyUnicode_AsString*() APIs are scheduled to be removed, it would be better to not introduce yet another way to use them.

If that's not easily possible now, then please fix the indentation (Tabs vs. spaces) before adding the API.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar  5 14:03:05 2010
From: report at bugs.python.org (Jeremy Sanders)
Date: Fri, 05 Mar 2010 13:03:05 +0000
Subject: [issue8069] struct documentation problem and suggestion to add fixed
	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267794185.84.0.449260675961.issue8069@psf.upfronthosting.co.za>


Jeremy Sanders <jeremy at jeremysanders.net> added the comment:

Sorry - I didn't read the docs clearly enough. This probably isn't a bug then. Can you mark it invalid?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8069>
_______________________________________

From report at bugs.python.org  Fri Mar  5 14:12:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Mar 2010 13:12:42 +0000
Subject: [issue8069] struct documentation problem and suggestion to add fixed
	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267794762.77.0.511289826991.issue8069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, it's a bug inasmuch as the docs aren't as clear as they could be.    I've got issue 7355 open to remind me to do something about that, though, so this one can probably be closed.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8069>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:14:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Mar 2010 14:14:08 +0000
Subject: [issue8054] "as_string" method in email's mime objects encode text
	segmentedly
In-Reply-To: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>
Message-ID: <1267798448.27.0.454729164431.issue8054@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We don't fully support setting defaultencoding to anything other than ASCII.  The test suite doesn't fully pass, for example, if defaultencoding is set to 'utf-8' in site.py.

But that aside, the documentation for MIMEText says: "No guessing or encoding is performed on the text data.".  In your first example you are passing it unicode, which is un-encoded.  It might be helpful if it threw a ValueError when passed unicode, but it isn't technically a bug that it doesn't, since it does throw an error if you haven't changed defaultencoding.  The behavior also can't be changed, since existing code may be depending on being able to pass ascii-only unicode strings in and having them auto-coerced to ascii.

Note that the cause of the problem is the fact that the email transport encoder is assuming that the input is binary data and is breaking it up into appropriately sized lines by counting bytes.  You've fed it a unicode string, which it then winds up breaking up by *unicode* character count, then passing the lines to binascii.b2a_base64, which given the non-standard defaultencoding then coerces it to utf-8, which contains a number of bytes different from the original character count, which are then encoded in base64, giving you the uneven length lines in the final output.

In Python3 this isn't a problem, since you can't accidentally mix up unicode and bytes in Python3.

----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8054>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:22:52 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 14:22:52 +0000
Subject: [issue8071] test message
In-Reply-To: <19345.5047.713471.759783@montanaro.dyndns.org>
Message-ID: <19345.5047.713471.759783@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

I don't know where this will go given that it's not a response to an
existing bug report.  I'm looking to see if the SpamBayes instance on
mail.python.org processes this message.

Someone please respond to let me know if this address is working properly
again w.r.t. spam filtering.

Thanks,

Skip

----------
messages: 100480
nosy: skip.montanaro
severity: normal
status: open
title: test message

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8071>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:26:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Mar 2010 14:26:11 +0000
Subject: [issue8071] test message
In-Reply-To: <19345.5047.713471.759783@montanaro.dyndns.org>
Message-ID: <1267799171.68.0.242588925452.issue8071@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It seems it went in the right place.
This message has a SpamBayes Score of 0.00451466.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8071>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:47:09 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 14:47:09 +0000
Subject: [issue8072] Test #2
In-Reply-To: <19345.6502.784963.115969@montanaro.dyndns.org>
Message-ID: <19345.6502.784963.115969@montanaro.dyndns.org>


New submission from Skip Montanaro <skip at pobox.com>:

After training a bunch of mail held for python-bugs-list I'm trying another
post to see how well SpamBayes likes it.

Skip

----------
messages: 100482
nosy: skip.montanaro
severity: normal
status: open
title: Test #2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8072>
_______________________________________

From report at bugs.python.org  Fri Mar  5 15:54:38 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 14:54:38 +0000
Subject: [issue8072] Test #2
In-Reply-To: <19345.6502.784963.115969@montanaro.dyndns.org>
Message-ID: <1267800878.56.0.638802932501.issue8072@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Test successful...

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8072>
_______________________________________

From report at bugs.python.org  Fri Mar  5 16:11:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Mar 2010 15:11:01 +0000
Subject: [issue8071] test message
In-Reply-To: <19345.5047.713471.759783@montanaro.dyndns.org>
Message-ID: <1267801861.5.0.123957964685.issue8071@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Does this mean you think you've fixed whatever was causing metatracker bug 320? (http://psf.upfronthosting.co.za/roundup/meta/issue320).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8071>
_______________________________________

From report at bugs.python.org  Fri Mar  5 16:16:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Mar 2010 15:16:24 +0000
Subject: [issue8064] Large regex handling very slow on Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267802184.2.0.613009657593.issue8064@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Interestingly, the code olivers is using was originally written by Martin v. Loewis:

http://www.velocityreviews.com/forums/t646421-unicode-regex-and-hindi-language.html

In response to a still open bug report on \w in the Python re module:

http://bugs.python.org/issue1693050

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8064>
_______________________________________

From report at bugs.python.org  Fri Mar  5 16:37:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 15:37:50 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1267803470.17.0.160999722028.issue1693050@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Fri Mar  5 16:38:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 15:38:00 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1267803480.95.0.910762880323.issue7774@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Fri Mar  5 16:56:25 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 05 Mar 2010 15:56:25 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267804585.79.0.244776297028.issue7670@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Now also fixed in 2.6 and 3.1 maintenance branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Fri Mar  5 17:01:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 16:01:33 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267804893.65.0.325780402974.issue7670@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commit numbers: r78688 (trunk), r78698 (py3k), r78699 (2.6), r78700 (3.1).

2.6 branch is froze because 2.6.5RC1 was released and 2.6.5 final is planned for next week. Ask barry if you should revert your commit or not r78699.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Fri Mar  5 17:07:35 2010
From: report at bugs.python.org (Chris Lieb)
Date: Fri, 05 Mar 2010 16:07:35 +0000
Subject: [issue8073] Test fail for sha512
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>


New submission from Chris Lieb <chris.lieb.hotmail+python at gmail.com>:

I am building Python 2.6.4 with GCC 4.2.1 (SUSE Linux, kernel  2.6.22.19-0.4-default) on a shared server and am encountering test
failures in test_hashlib.py and test_hmac.py, specifically concerning
sha512.  I recompiled Python with --with-pydebug and CLFAGS=CPPFLAGS="-
g" and ran the tests in GDB and got the following results:

---------------------------------------------------------------------

GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run test_hashlib.py
Starting program: /export/users1/chris.lieb/packages/python/bin/
python2.6 test_hashlib.py
test_case_md5_0 (__main__.HashLibTestCase) ... ok
test_case_md5_1 (__main__.HashLibTestCase) ... ok
test_case_md5_2 (__main__.HashLibTestCase) ... ok
test_case_md5_huge (__main__.HashLibTestCase) ... ok
test_case_md5_uintmax (__main__.HashLibTestCase) ... ok
test_case_sha1_0 (__main__.HashLibTestCase) ... ok
test_case_sha1_1 (__main__.HashLibTestCase) ... ok
test_case_sha1_2 (__main__.HashLibTestCase) ... ok
test_case_sha1_3 (__main__.HashLibTestCase) ... ok
test_case_sha224_0 (__main__.HashLibTestCase) ... ok
test_case_sha224_1 (__main__.HashLibTestCase) ... ok
test_case_sha224_2 (__main__.HashLibTestCase) ... ok
test_case_sha224_3 (__main__.HashLibTestCase) ... ok
test_case_sha256_0 (__main__.HashLibTestCase) ... ok
test_case_sha256_1 (__main__.HashLibTestCase) ... ok
test_case_sha256_2 (__main__.HashLibTestCase) ... ok
test_case_sha256_3 (__main__.HashLibTestCase) ... ok
test_case_sha384_0 (__main__.HashLibTestCase) ... ok
test_case_sha384_1 (__main__.HashLibTestCase) ... ok
test_case_sha384_2 (__main__.HashLibTestCase) ... ok
test_case_sha384_3 (__main__.HashLibTestCase) ... ok
test_case_sha512_0 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_1 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_2 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_3 (__main__.HashLibTestCase) ... FAIL
test_hexdigest (__main__.HashLibTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00002ba86ffbb463 in ?? ()
(gdb) bt
#0  0x00002ba86ffbb463 in ?? ()
#1  0x000000000046993d in PyString_FromStringAndSize (
    str=0x7fff71c67800 " \203 5~? T(P m\200\a \005\vW
\025 \203 ! l G <]
\205                                                    5
\203\030 \207~ /c 1 GAz\201 82z ' > x q \177",
size=1054484473)
    at Objects/stringobject.c:90
#2  0x00002ba87030d59a in ?? ()
#3  0x0000000000000000 in ?? ()

---------------------------------------------------------------------

GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run test_hmac.py
Starting program: /export/users1/chris.lieb/packages/python/bin/
python2.6 test_hmac.py
test_legacy_block_size_warnings (__main__.TestVectorsTestCase) ... ok
test_md5_vectors (__main__.TestVectorsTestCase) ... ok
test_sha224_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha256_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha384_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha512_rfc4231 (__main__.TestVectorsTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00002b483844e4c7 in ?? ()
(gdb) bt
#0  0x00002b483844e4c7 in ?? ()
#1  0x000000000046993d in PyString_FromStringAndSize (
    str=0x7ffff84f6730 "\026C3D \235D\t \025 [ G
\032bG? ~ \235\t\233aP",
    size=4108309188) at Objects/stringobject.c:90
#2  0x00002b48387e159a in ?? ()
#3  0x0000000000000000 in ?? ()

--------------------------------------------------------------------

In the case of test_hashlib.py, it segfaulted on the first sha512 test
when I didn't have the debugging options enabled.  Only after enabling
debugging did I get FAIL's for the sha512 tests.

Does anyone know what is causing these failures? 

---------------------------------------------------------------------

CPUINFO

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 246
stepping        : 8
cpu MHz         : 1992.106
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 3988.23
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 246
stepping        : 8
cpu MHz         : 1992.106
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 3990.71
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp

----------
components: Tests
messages: 100488
nosy: frohman
severity: normal
status: open
title: Test fail for sha512
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Fri Mar  5 17:18:27 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 16:18:27 +0000
Subject: [issue8071] test message
In-Reply-To: <19345.5047.713471.759783@montanaro.dyndns.org>
Message-ID: <1267805907.09.0.890858933577.issue8071@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I don't know, but it's quite possible.  Lots of messages were held for
moderation.  It's possible that some were rejected as spam.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8071>
_______________________________________

From report at bugs.python.org  Fri Mar  5 17:27:12 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 05 Mar 2010 16:27:12 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267806432.74.0.251759204736.issue7670@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

As requested per Barry, marking this as release blocker for 2.6.

----------
keywords: +26backport
priority:  -> release blocker
stage: patch review -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Fri Mar  5 17:44:32 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Mar 2010 16:44:32 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267807472.27.0.762716537765.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

(I faxed in my contributor agreement to the PSF on 2010-03-03)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Fri Mar  5 18:06:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Mar 2010 17:06:40 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1267808800.04.0.987736248845.issue8065@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Note the following comment elsewhere in Modules/readline.c:

           /* the history docs don't say so, but the address of state                                                                   
              changes each time history_get_history_state is called                                                                      
              which makes me think it's freshly malloc'd memory...                                                                       
              on the other hand, the address of the last line stays the                                                                  
              same as long as history isn't extended, so it appears to                                                                   
              be malloc'd but managed by the history package... */
           free(state);


It is indeed not documented that state is malloced, but the implementation of history_get_history_state () is as follows:

/* Return the current HISTORY_STATE of the history. */
HISTORY_STATE *
history_get_history_state ()
{
  HISTORY_STATE *state;

  state = (HISTORY_STATE *)xmalloc (sizeof (HISTORY_STATE));
  state->entries = the_history;
  state->offset = history_offset;
  state->length = history_length;
  state->size = history_size;
  state->flags = 0;
  if (history_stifled)
    state->flags |= HS_STIFLED;

  return (state);
}

xmalloc () is an error checking wrapper around malloc, so free () can be used to deallocate the memory.

On the other hand it seems wasteful to request full state in a function that only needs history_length which is directly exported by the readline library.  I am attaching a patch that reads history_length directly.

----------
keywords: +patch
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file16462/issue8065.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Fri Mar  5 18:32:24 2010
From: report at bugs.python.org (Cliff Dyer)
Date: Fri, 05 Mar 2010 17:32:24 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>


New submission from Cliff Dyer <jcd at sdf.lonestar.org>:

When a long suite of tests is running, it would be nice to be able to exit out early to see the results of the tests that have run so far.  

I would like to see a couple of features included in `unittest` to this effect that have recently been implemented in django's test runner.  The first exits gracefully on `^C`, the second allows the user to specify a `--failfast` option, which causes the test runner to exit after the first failure or error, rather than proceeding with the 

If you hit `^C`, rather than exit with a stack trace of whatever was happening at the time, `unittest` should complete the current test, and then exit with the results to that point.  A second `^C` would be treated as a normal `KeyboardInterrupt`, in case that last test were somehow running on too long.

{{{
  $ python test_module.py
..F.s.^C <Test run halted by Ctrl-C> x
======================================================================
FAIL: test_multiline_equal (__main__.MyTest)
Unicode objects return diffs on failure
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_test.py", line 39, in test_multiline_equal
    self.assertEqual(original, revised)
AssertionError: 
- Lorem ipsum dolor sit amet, 
?             ^
+ Lorem ipsum color sit amet, 
?             ^
              consectetur adipisicing elit, 
+             that's the way the cookie crumbles,
              sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

----------------------------------------------------------------------
Ran 7 tests in 12.010s

FAILED (failures=1, skipped=1, expected failures=1)
}}}

A `failfast` option could be specified as a keyword argument to `unittest.main()`, or `unittest.main()` could read it off the command line, according to the same mechanism used by, e.g., the `verbosity` option.

----------
components: Library (Lib)
messages: 100493
nosy: jcd
severity: normal
status: open
title: Fail-fast behavior for unittest
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Fri Mar  5 18:37:30 2010
From: report at bugs.python.org (Cliff Dyer)
Date: Fri, 05 Mar 2010 17:37:30 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1267810650.91.0.441634361419.issue8074@psf.upfronthosting.co.za>


Cliff Dyer <jcd at sdf.lonestar.org> added the comment:

This feature was implemented in the django test runner as [r12034](http://code.djangoproject.com/changeset/12034) (^C override) and [r11843](http://code.djangoproject.com/changeset/11843) (failfast option)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Fri Mar  5 18:43:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Mar 2010 17:43:49 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1267811029.07.0.917627040293.issue8074@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> michael.foord
nosy: +michael.foord
priority:  -> normal
stage:  -> needs patch
versions:  -Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Fri Mar  5 18:59:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Mar 2010 17:59:43 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1267811983.72.0.534150223745.issue8065@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Not directly related to the issue at hand, but I've noticed that while readline.get_current_history_length() is tested in the unittests, readline.get_history_length() is not.  Attached patch adds tests for reading and writing history files.

Also, I find it confusing that readline module static variable _history_length is named almost the same as readline library exported variable history_length.  Maybe _history_length could be renamed to max_history_file_length.

----------
Added file: http://bugs.python.org/file16463/issue8065-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Fri Mar  5 20:17:55 2010
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 05 Mar 2010 19:17:55 +0000
Subject: [issue887237] Machine integers
In-Reply-To: <d38f5331003041845x78579b23q1b2ee463636679b1@mail.gmail.com>
Message-ID: <4B9158DC.1000606@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

>> Code duplication is unavoidable because the goal is to give access to
>> machine arithmetics which means (# types) x (# operations) of very
>> similar looking functions. I considered reducing (perceived) code
>> duplication through some pre-processor magic, but doing so would make
>> code much harder to understand and almost impossible to debug.
> 
> Carefully written macros shouldn't be hard to understand.
> At least there wouldn't be the risk of overlooking one of the methods
> when making modifications.

The code duplication in Alex's patch is indeed enormous.  I can see
two solutions to avoid (or work around) them.  Use of macros, or writing
a Python script that generates the C-code.  Anyway, I guess his patch
is some example code, not more.  (Using C++ overloaded functions or even
templates would be another - but only theoretical - possibility).

> I would like to hear from Thomas before introducing macros in this
> code.  I tried to follow the style of cfield.c which shows similar
> code duplication.
> 
> There are also some questions that need to be answered before
> polishing the code.
> 
> 1. Should mixed arithmetics be supported?
> 2. Should we do anything special about floating point operations?
> Wrapping them in PyFPE_START/STOP_PROTECT?
> 3. Should we support in-place operations?
> 4. Bitwise operations on integers?

I would answer 1, 3, and 4, with 'yes'. However, this grows the code size
by another dimension since we now have #types * #operation * #types.

My answer for question 3 is 'I don't know'.

Before I forget:  It may be possible to implement ctypes number methods
as a third-party module by implementing a mixin class, and replacing the
c_... type definitions in Lib/ctypes/__init__.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Fri Mar  5 20:45:49 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Fri, 05 Mar 2010 19:45:49 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267818349.45.0.896992859838.issue7449@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

Uploaded a new version of the patch, nothreads_3.patch.

@r.david.murray - Good point about unittest.skipUnless, I didn't know about that function.  I removed my decorator and used skipUnless() instead.

@haypo:
test_xmlrpc.py - Modified the URL changes so that now the tests should run exactly as before in the multithreaded case.
test_macostools.py - The TESTFN changes are unrelated to the work I am doing.  I removed them and will file as a separate item in Roundup.

The skip_if_no decorator has been removed and replaced with unittest.skipUnless().

test_errno.py - You mentioned that only half the tests use threads.  The file has two test methods, both of which use threads.
test_sqlite.py - Fixed so that only tests that require threading are skipped.  Thank you for the reminder about class decorators.
test_urllib2_localnet.py - I will create an issue in the bug tracker to fix the usage of BaseTestCase.  From the svn revision lot it appears the functionality in BaseTestCase is there for a reason and I think it should be fixed.
test_support.py:
  - The thread module is now imported once at the top of test_support.
  - The reap_threads() function decorates with a thread cleanup function if thread is available, or with a no-op function if thread is not available.  Added a docstring.
  - Removed "import thread" calls in threading_setup() and threading_cleanup().  Replaced with "if thread" statements.
fork_wait.py - I removed the decorator and use import_module() instead.
test_bz2.py - Modified the import so all but one of the tests run when threading is disabled.

test_multiprocessing.py - Modified to use the try: import threading method of importing the module.  It's kind of a moot point because the multiprocessing module does not exist when python is built without threading.
test_capi.py - test_pendingcalls_non_threaded eventually makes a call to testcapi._pending_threadfunc().  testcapi._pending_threadfunc() does not exist when python is built without threading.  What I'm trying to say is that both tests rely on threading.  I added the skipUnless decorator to both test methods.
test_hashlib.py - Switched to use skipUnless instead.

----------
Added file: http://bugs.python.org/file16464/nothreads_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Fri Mar  5 21:00:54 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 20:00:54 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1267819254.17.0.8406933179.issue8068@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also note that these patches effectively take care of backporting to py3k and 31 the most recent installer script changes that were made to 2.6 and trunk in support of 10.6 and the newer universal build options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar  5 21:08:17 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Fri, 05 Mar 2010 20:08:17 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267819697.22.0.416838885017.issue7449@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

I think this issue is going to reoccur every time someone adds a unit test that relies on threading.  What do you think about using a buildbot slave to run the tests with a non-multithreaded build of python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Fri Mar  5 21:10:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Mar 2010 20:10:42 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267819842.47.0.459660796499.issue7449@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think it is a good idea, but someone has to set one up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Fri Mar  5 22:46:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Mar 2010 21:46:04 +0000
Subject: [issue7460] extended slicing not sufficiently covered in docs
In-Reply-To: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>
Message-ID: <1267825564.96.0.174154498473.issue7460@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This may be duplicative of #1446619,
but I have not looked at that enough.
I agree that revision is needed and will try to develop patch suggestions.

----------
nosy: +tjreedy
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7460>
_______________________________________

From report at bugs.python.org  Fri Mar  5 22:58:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Mar 2010 21:58:32 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267826312.13.0.169666872696.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+1 to setup a buildbot, but only after all bugs are fixed :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Fri Mar  5 23:10:34 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 05 Mar 2010 22:10:34 +0000
Subject: [issue7460] extended slicing not sufficiently covered in docs
In-Reply-To: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>
Message-ID: <1267827034.47.0.628578908758.issue7460@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

When I wrote this bug report I was mainly thinking about the C-API documentation which doesn't mention extended slicing at all.
Since the C-API isn't mentioned in the other bug I don't think it's a duplicate but they could maybe be merged if you see any advantage in that.

And thanks for looking into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7460>
_______________________________________

From report at bugs.python.org  Sat Mar  6 00:43:42 2010
From: report at bugs.python.org (Eugene Baranov)
Date: Fri, 05 Mar 2010 23:43:42 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
	.py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>


New submission from Eugene Baranov <eug.baranov at gmail.com>:

I tried installing Python 2.6.4 into Program Files in Windows 7 and choose to compile .py files after install.

Installer correctly asks for a elevation and copies all fixes but it looks like compile batch are being started from initial, unelevated context. (It displays access denied messages)

The issues does not appear when starting installer from already elevated command prompt.

----------
components: Installation
messages: 100504
nosy: Regent
severity: normal
status: open
title: Windows (Vista/7) install error when choosing to compile .py files
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Sat Mar  6 00:45:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Mar 2010 23:45:42 +0000
Subject: [issue5604] imp.find_module() mixes UTF8 and MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1267832742.37.0.687642301937.issue5604@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I fixed all the things listed in the previous message in r78689, but that just enabled the test on several Linux buildbots and some started to fail too.
In r78696 (and r78697) I tried to use sys.getfilesystemencoding() instead of locale.getpreferredencoding() and that turned at least the Windows buildbots green, but there are still a few linux bots that fail:
http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%203.x/builds/545/steps/test/logs/stdio
http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%203.x/builds/561/steps/test/logs/stdio
http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%203.x/builds/525/steps/test/logs/stdio
http://www.python.org/dev/buildbot/builders/amd64%20gentoo%203.x/builds/513/steps/test/logs/stdio

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5604>
_______________________________________

From report at bugs.python.org  Sat Mar  6 00:46:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Mar 2010 23:46:38 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
	.py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1267832798.61.0.430188878018.issue8075@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#6716 is a related issue, but isn't exactly a duplicate.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Sat Mar  6 00:47:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Mar 2010 23:47:05 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
	.py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1267832825.81.0.860448615728.issue8075@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
priority:  -> high
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Sat Mar  6 01:47:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 00:47:15 +0000
Subject: [issue8076] sys.setfilesystemencoding('foo') causes segmentation fault
In-Reply-To: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>
Message-ID: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> import sys
>>> sys.setfilesystemencoding('foo')
>>> open('something')
Segmentation Fault

----------
components: Interpreter Core
messages: 100507
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: sys.setfilesystemencoding('foo') causes segmentation fault
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8076>
_______________________________________

From report at bugs.python.org  Sat Mar  6 02:32:14 2010
From: report at bugs.python.org (steven Michalske)
Date: Sat, 06 Mar 2010 01:32:14 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267839134.66.0.055314579843.issue8062@psf.upfronthosting.co.za>


steven Michalske <smichalske at gmail.com> added the comment:

I'll work on a proposal for the ideas list.

Other language examples to keep this in a thread though.

perl -e 'print 0x1234_abcd; print "\n";'

C/C++ seems to not support the underscore.
Lua unsupported.

Data sheets from micro controllers and other digital circuits.

Bottom of page 21 on http://www.atmel.com/dyn/resources/prod_documents/32058S.pdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Sat Mar  6 02:43:41 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 06 Mar 2010 01:43:41 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I am reluctant to post this because (a) I might have made some dumb mistake in my code, simple as it is, and (b) the problem might be well-known or even hopeless because the cgi module may not be WSGI compliant, but if this isn't going to be fixed then at least the problem should be described in the cgi module documentation.

I run an HTTPServer with a CGIHTTPRequestHandler.
I open an HTML file with a trivial form that simply POSTs an upload of a single file.
I browse, select a file, and click submit.
The web request never completes -- the browser just waits for a response.
Interrupting the server with ^C^C produces a backtrace that indicates it is stuck trying to decode the file contents.

The attached zip file contains:
    cgi-server.py
    cgi-post.html
    cgi-bin/cgi-test.py
    exception.txt
The latter is the backtrace output from when I interrupt the server.

This is on OS X 10.5 with either Python3.1 or Python3.2 from the repository.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
files: cgi-post-broken.zip
messages: 100509
nosy: MLModel, georg.brandl
severity: normal
status: open
title: cgi handling of POSTed files is broken
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16465/cgi-post-broken.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Sat Mar  6 03:04:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 02:04:54 +0000
Subject: [issue8076] sys.setfilesystemencoding('foo') causes segmentation fault
In-Reply-To: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>
Message-ID: <1267841094.43.0.771254351984.issue8076@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On 3.2 on Linux and 3.1 on Windows I get:
  [...]
  File "C:\Programmi\Python31\lib\encodings\__init__.py", line 98, in search_fun
ction
    level=0)
  File "C:\Programmi\Python31\lib\encodings\__init__.py", line 98, in search_fun
ction
    level=0)
  File "C:\Programmi\Python31\lib\encodings\__init__.py", line 83, in search_fun
ction
    norm_encoding = normalize_encoding(encoding)
  File "C:\Programmi\Python31\lib\encodings\__init__.py", line 55, in normalize_
encoding
    if isinstance(encoding, bytes):
RuntimeError: maximum recursion depth exceeded while calling a Python object

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8076>
_______________________________________

From report at bugs.python.org  Sat Mar  6 03:17:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 02:17:00 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1267841820.48.0.166653529434.issue6509@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch looks OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Mar  6 03:50:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Mar 2010 02:50:46 +0000
Subject: [issue887237] Machine integers
Message-ID: <1267843846.42.0.0414676151032.issue887237@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Attaching a patch that is equivalent toissue887237.diff, but uses preprocessor to generate repetitive code.

----------
Added file: http://bugs.python.org/file16466/issue887237-macro.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Sat Mar  6 03:57:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Mar 2010 02:57:42 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267844262.02.0.449541091834.issue8047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know what compatibility you are talking about. Py3k deliberately breaks compatibility with many 2.x behaviours that were considered defective or suboptimal.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sat Mar  6 03:59:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Mar 2010 02:59:36 +0000
Subject: [issue8073] Test fail for sha512
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1267844376.88.0.616746319587.issue8073@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Extension Modules -Tests
nosy: +gps
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Sat Mar  6 04:32:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Mar 2010 03:32:10 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267846330.77.0.0614616414207.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm applying fixes one by one in my local git-svn repository. I will commit them (in one huge patch \o/) when I'm done, or maybe post a new version of the patch (if I'm too scared of the patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sat Mar  6 04:35:45 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Mar 2010 03:35:45 +0000
Subject: [issue8073] Test fail for sha512
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1267846545.7.0.725051627953.issue8073@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith -gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Sat Mar  6 05:26:42 2010
From: report at bugs.python.org (Jon Smirl)
Date: Sat, 06 Mar 2010 04:26:42 +0000
Subject: [issue8078] add more baud constants to termios
In-Reply-To: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>
Message-ID: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>


New submission from Jon Smirl <jonsmirl at gmail.com>:

termios doesn't have the constants defined for higher baud rates on Linux.

According to my bits/termios.h:
#define  B57600   0010001
#define  B115200  0010002
#define  B230400  0010003
#define  B460800  0010004
#define  B500000  0010005
#define  B576000  0010006
#define  B921600  0010007
#define  B1000000 0010010
#define  B1152000 0010011
#define  B1500000 0010012
#define  B2000000 0010013
#define  B2500000 0010014
#define  B3000000 0010015
#define  B3500000 0010016
#define  B4000000 0010017

----------
messages: 100515
nosy: jonsmirl
severity: normal
status: open
title: add more baud constants to termios
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8078>
_______________________________________

From report at bugs.python.org  Sat Mar  6 05:29:02 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 06 Mar 2010 04:29:02 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267849742.66.0.499779473604.issue7449@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

I think the latest (v3) patch is in pretty good shape.  You and David have been through the changes and the result is a much improved set of changes.  If you want (and you're okay with it), I can commit the changes from here and take the beating if it makes the buildbots fall over. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sat Mar  6 05:35:39 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 06 Mar 2010 04:35:39 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267850139.94.0.823787673169.issue7449@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

I'll break up the patch into multiple files as well.  It will make it easier to deal with if I cause a regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sat Mar  6 07:40:30 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 06 Mar 2010 06:40:30 +0000
Subject: [issue8079] make install fails with -j8 with python2.6/config on
	FreeBSD
In-Reply-To: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>
Message-ID: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

When attempting to install and deinstall lang/python26 to run some unit tests for a change I was going to provide to the maintainer, I ran into this issue:

install -o root -g wheel -m 444 ./../Include/ucnhash.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/unicodeobject.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/warnings.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/weakrefobject.h /usr/local/include/python2.6
install  -o root -g wheel -m 444 pyconfig.h /usr/local/include/python2.6/pyconfig.h
Creating directory /usr/local/lib/python2.6/config
install: /usr/local/lib/python2.6/config exists but is not a directory
*** Error code 71

Stop in /scratch/freebsd/ports/lang/python26/work/Python-2.6.4/portbld.static.
*** Error code 1

Stop in /scratch/freebsd/ports/lang/python26.
*** Error code 1

The problem was caused by an incomplete install into ${prefix} [which I will take up with the FreeBSD project], but manifests itself because the -j value I specified, was too high. I say this because of another comment placed in a top-level Makefile at a previous job about compiling Python 2.4.2 with this particular goal (installing the modules) and race conditions.

I would provide a patch but I'm not sure what the issue could stem from, other than a race conditions with a busted install-sh and incomplete dependencies specified in Makefile.pre.in.

I'll provide more info if needed.

Reproducible via the following on FreeBSD, given a fast enough machine:

cd lang/python26; make deinstall clean; make -j8 all; make -j8 install

[gcooper at bayonetta /scratch/freebsd/ports/lang/python26]$ uname -a
FreeBSD bayonetta.localdomain 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Thu Mar  4 13:16:39 PST 2010     gcooper at bayonetta.localdomain:/usr/obj/usr/src/sys/BAYONETTA  amd64
[gcooper at bayonetta /scratch/freebsd/ports/lang/python26]$ sysctl -a hw.model
hw.model: Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz

[From top(1)]

Mem: 43M Active, 10G Inact, 870M Wired, 76M Cache, 1237M Buf, 537M Free
Swap: 20G Total, 108K Used, 20G Free

----------
components: Build
messages: 100518
nosy: yaneurabeya
severity: normal
status: open
title: make install fails with -j8 with python2.6/config on FreeBSD
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8079>
_______________________________________

From report at bugs.python.org  Sat Mar  6 08:01:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 07:01:05 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
	.py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1267858865.24.0.194405440421.issue8075@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This will be difficult to fix. Contributions are welcome.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Sat Mar  6 08:01:39 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 06 Mar 2010 07:01:39 +0000
Subject: [issue8079] make install fails with -j8 with python2.6/config on
	FreeBSD
In-Reply-To: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>
Message-ID: <1267858899.47.0.378471404265.issue8079@psf.upfronthosting.co.za>


Changes by Garrett Cooper <yanegomi at gmail.com>:


Added file: http://bugs.python.org/file16467/all.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8079>
_______________________________________

From report at bugs.python.org  Sat Mar  6 08:02:07 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 06 Mar 2010 07:02:07 +0000
Subject: [issue8079] make install fails with -j8 with python2.6/config on
	FreeBSD
In-Reply-To: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>
Message-ID: <1267858927.11.0.787775869633.issue8079@psf.upfronthosting.co.za>


Changes by Garrett Cooper <yanegomi at gmail.com>:


Added file: http://bugs.python.org/file16468/clean.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8079>
_______________________________________

From report at bugs.python.org  Sat Mar  6 08:37:13 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Mar 2010 07:37:13 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267861033.94.0.855536485538.issue8045@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

See trunk r78718 for my proposed fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:10:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Mar 2010 09:10:32 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267866632.9.0.19295092654.issue8062@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm confused:  are you talking about producing underscores when formatting an integer for hexadecimal output, or allowing numeric literals to contain underscores?

Your perl example produces:

305441741

with not an underscore in sight.  I'm failing to understand the relevance of this example to your request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:38:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 09:38:05 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1267868285.4.0.816025684032.issue7319@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The -Qwarn/-Qwarnall options are unexpectedly silenced in 2.7.

----------
nosy: +flox
stage:  -> commit review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Sat Mar  6 10:42:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 09:42:17 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1267868537.0.0.729157323851.issue1731717@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Sometimes IA64 Ubuntu bot fails on this one.
http://www.python.org/dev/buildbot/all/builders/ia64%20Ubuntu%20trunk/builds/571

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Sat Mar  6 11:17:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 10:17:45 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1267870665.51.0.950685854277.issue6906@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

confirmed on Win7 buildbot, when the tcl or tk test is run before test_wsgiref:

======================================================================
FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\trunk.bolen-windows7\build\lib\test\test_wsgiref.py", line 159, in test_simple_validation_error
    "AssertionError: Headers (('Content-Type', 'text/plain')) must"
AssertionError: "AssertionError: Environmental variable TCL_LIBRARY is not a string: <type 'unicode'> (value: u'D:\\\\cygwin\\\\home\\\\db3l\\\\buildarea\\\\trunk.bolen-windows7\\\\tcltk\\\\lib\\\\tcl8.5')" != "AssertionError: Headers (('Content-Type', 'text/plain')) must be of type list: <type 'tuple'>"


http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%20trunk/builds/171

This error was introduced with patch for #3881.

----------
keywords: +buildbot
nosy: +flox
stage: test needed -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:17:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Mar 2010 11:17:43 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1267874263.31.0.905683860848.issue4180@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 for Benjamin's patch, having just been bitten by this exact problem.

I'm trying to do unit testing, checking both that a piece of code produces a DeprecationWarning and that it gives the correct result, with something like:

    with warnings.catch_warnings():
        warnings.filterwarnings("ignore", category=DeprecationWarning)
        self.assertEqual(my_func(my_args), expected_result)

    with warnings.catch_warnings():
        warnings.filterwarnings("error", category=DeprecationWarning)
        self.assertRaises(DeprecationWarning, my_func, *my_args)

The first call still registers the warning, even though it's ignored, so the second assertRaises fails.  Benjamin's patch would seem to provide a way to fix this.

Perhaps I'm missing an obvious better way to do this.

N.B. The above is a too simple version of the real problem: it actually works as intended, for fragile reasons:  the "ignore"d warning is registered on __name__, while the "always"d warning ends up being registered on unittest.case, so there's no conflict.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:20:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 11:20:23 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1267874423.39.0.67597754107.issue4180@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +Interpreter Core
nosy: +flox
stage:  -> patch review
versions: +Python 2.7 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:31:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Mar 2010 11:31:44 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1267875104.07.0.08756023532.issue7849@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is somewhat orthogonal, but it might also be nice to have some way to tell check_warnings not to touch __warningregistry__.  See also issue 4180.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Sat Mar  6 12:41:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Mar 2010 11:41:21 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267875681.56.0.395729287875.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think the latest (v3) patch is in pretty good shape. (...)
> I'll break up the patch into multiple files as well.
> It will make it easier to deal with if I cause a regression.

I'm already doing that (apply the patch file by file). The patch v3 is not perfect, some tests are still disabled whereas they can be executed without tests. Give me a few days to work on a new version of the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:50:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 14:50:30 +0000
Subject: [issue5604] imp.find_module() mixes UTF8 and MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1267887030.12.0.780873315737.issue5604@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Thanks for fixing this. Now Win7 buildbot is green on trunk.

----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5604>
_______________________________________

From report at bugs.python.org  Sat Mar  6 15:54:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 14:54:20 +0000
Subject: [issue5604] imp.find_module() mixes UTF8 and MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1267887260.61.0.467778230347.issue5604@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The Linux buildbots were running the tests using ./python ./Lib/test/regrtest.py instead of ./python -m test.regrtest and '' was missing from sys.path, so imp.find_module couldn't find the module.
This is now fixed in r78711 and backported r78716.
Thanks to Florent that noticed that those buildbots were using a different command to run the tests.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5604>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:06:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 15:06:33 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1267887993.14.0.136855170532.issue6906@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r78722 on trunk. Pending backport to 2.6.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:08:30 2010
From: report at bugs.python.org (Stuart Axon)
Date: Sat, 06 Mar 2010 15:08:30 +0000
Subject: [issue8080] os.uname failing in windows
In-Reply-To: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>
Message-ID: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>


New submission from Stuart Axon <stu.axon at gmail.com>:

I'm not sure why this is happening, but os.uname() is failing on my computer in XP Home 32bit.  Tested in the normal shell and MSys

The code in platform.py looks like it should work to me.


[C:\usr\Python26\Lib]python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.uname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'uname'
>>>

----------
components: Library (Lib), Windows
messages: 100531
nosy: stuaxo
severity: normal
status: open
title: os.uname failing in windows
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8080>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:14:15 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Mar 2010 15:14:15 +0000
Subject: [issue8080] os.uname failing in windows
In-Reply-To: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>
Message-ID: <1267888455.1.0.551766287198.issue8080@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

As documented, this is not supported on Windows.

http://docs.python.org/dev/library/os#os.uname
os.uname is generated in Modules/posixmodule.c, not in platform.py

----------
nosy: +brian.curtin
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8080>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:15:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 15:15:23 +0000
Subject: [issue8080] os.uname failing in windows
In-Reply-To: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>
Message-ID: <1267888523.92.0.728886317397.issue8080@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Use platform.uname(), it is available on all platforms.

----------
nosy: +flox
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8080>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:30:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 15:30:21 +0000
Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29
Message-ID: <1267889421.52.0.449532234428.issue1054943@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
resolution:  -> remind
stage: test needed -> committed/rejected
status: open -> pending
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054943>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:33:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 15:33:33 +0000
Subject: [issue6509] re.py - <compiled byte-object regular expr> encounter
	unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1267889613.37.0.766075137928.issue6509@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78729 (py3k) and r78730 (release31-maint). I also added a test for callbacks.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________

From report at bugs.python.org  Sat Mar  6 16:54:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 15:54:05 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1267890845.14.0.832499150036.issue6815@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a shorter snippet to reproduce the issue:
import os
os.environ['TEST'] = u'??'.encode('iso-8859-1')
os.path.expandvars(u'%TEST%a')

If the var is a non-ASCII byte string, and the string passed to expandvars() is Unicode, the var is decoded implicitly using the ASCII codec and the decoding fails.

On Python 3 the situation looks even worse:
import os
os.environ['TEST'] = '??'.encode('iso-8859-1');
os.path.expandvars('%TEST%a')

This snippet returns "b'\\xe4\\xf6'a".

----------
priority: normal -> high
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________

From report at bugs.python.org  Sat Mar  6 17:09:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 16:09:20 +0000
Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29
Message-ID: <1267891760.39.0.0400438847183.issue1054943@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054943>
_______________________________________

From report at bugs.python.org  Sat Mar  6 17:26:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Mar 2010 16:26:29 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1267892789.74.0.468004149593.issue6815@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

FWIW, _winreg.ExpandEnvironmentStrings does the right thing.

D:\python-dev\trunk>PCbuild\amd64\python.exe
Python 2.7a3+ (trunk, Feb 23 2010, 20:22:24) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, _winreg
>>> os.environ["TEST"] = u"jalape\xf1o".encode(sys.getfilesystemencoding())
>>> print(os.path.expandvars(u"C:\\%TEST%"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\python-dev\trunk\lib\ntpath.py", line 354, in expandvars
    res = res + os.environ[var]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 6: ordinal
not in range(128)
>>> print(_winreg.ExpandEnvironmentStrings(u"C:\\%TEST%"))
C:\jalape?o

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________

From report at bugs.python.org  Sat Mar  6 18:28:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 17:28:39 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267896519.72.0.369543489389.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Maybe I'm using it incorrectly, but my first attempt to use it failed:

gdb) b PyEval_EvalCodeEx
Breakpoint 1 at 0x80fc51d: file Python/ceval.c, line 3020.
(gdb) c
Continuing.
1+2

Breakpoint 1, PyEval_EvalCodeEx (co=0xb7d86928, globals=Traceback (most recent call last):
  File "/home/martin/work/27/python-gdb.py", line 574, in to_string
    return stringify(proxyval)
  File "/home/martin/work/27/python-gdb.py", line 526, in stringify
    return repr(val)
  File "/home/martin/work/27/python-gdb.py", line 271, in __repr__
    for arg, val in self.attrdict.iteritems()])
AttributeError: 'FakeRepr' object has no attribute 'iteritems'
, locals=<unknown at remote 0x0>, args=0xb7d7eb00, argcount=1, kws=0x0, kwcount=0, defs=0x827c9b0, defcount=1, closure=<unknown at remote 0x0>)
    at Python/ceval.c:3020
3020            register PyObject *retval = NULL;

This was with the Python 2.7 trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Sat Mar  6 18:32:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 17:32:18 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267896738.35.0.897796612046.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Attribution question: would it be ok if all mentioning of your name in the patch was removed accept for the one in Misc/ACKS? I'm concerned that statements of authorship may become incorrect over time (if people start contributing to it), yet nobody will dare to remove your copyright notice (for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Sat Mar  6 18:49:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Mar 2010 17:49:47 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1267897787.3.0.103536639311.issue6815@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch for trunk.
It works for me, but my Unicode knowledge isn't the strongest. I believe sys.getfilesystemencoding() is what we want here. Can anyone confirm?

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file16469/issue6815.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________

From report at bugs.python.org  Sat Mar  6 19:07:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Mar 2010 18:07:17 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1267898837.52.0.853385829349.issue6953@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Sat Mar  6 19:12:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 18:12:54 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1267899174.01.0.801016823094.issue6815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the patch is incorrect. It shouldn't do any encoding conversion, but perform the expanding completely in Unicode strings.

For 2.x, I recommend to close this as "won't fix". Expanding a Unicode strings is just not supported. If it was supported, it should be supported correctly, i.e. allowing both environment variable names and environment variable values to have non-ASCII characters in them, and, on Windows, even non-MBCS characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________

From report at bugs.python.org  Sat Mar  6 19:13:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Mar 2010 18:13:09 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1267899189.03.0.639900360009.issue6815@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:19:34 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Mar 2010 19:19:34 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1267903174.28.0.411089293195.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So it isn't really unexpected as -Q uses DeprecationWarning which is being silenced by default.

So either -Q has to turn DeprecationWarning back on or a new subclass of DeprecationWarning (say IntegerDivisionWarning) needs to be introduced that -Q uses and adds to the warnings filter.

And FYI, I did backport the patch but forgot to close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:20:33 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 06 Mar 2010 19:20:33 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1267903233.41.0.624379901509.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Another version of the patch is attached ( I think, I fixed all the remaining style issues).

I'll answer the testing question in a separate post

----------
Added file: http://bugs.python.org/file16470/sig.patch.v3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:27:44 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 06 Mar 2010 19:27:44 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <00163616467b44cf79048126d3b4@google.com>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

new version of the patch is uploaded to bugs.python.org

http://codereview.appspot.com/216067/diff/2001/2002
File Lib/pdb.py (right):

http://codereview.appspot.com/216067/diff/2001/2002#newcode63
Lib/pdb.py:63: def sigint_handler(self, signum, frame):
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> Please move this below the __init__ definition.  It makes classes odd
to read
> when __init__ isn't the first method defined when people are looking
for the
> constructor to see how to use it.

Done.

http://codereview.appspot.com/216067/diff/2001/2002#newcode64
Lib/pdb.py:64: if self.allow_kbdint:
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> Initialize self.allow_kdbint in __init__ so that a SIGINT coming in
before
> _cmdloop has run doesn't cause an AttributeError.

Done.

http://codereview.appspot.com/216067/diff/2001/2002#newcode215
Lib/pdb.py:215: # keyboard interrupts allow for an easy way to interrupt
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> "to cancel the current command"

I changed the wording a bit, should be ok now.

http://codereview.appspot.com/216067/diff/2001/2002#newcode356
Lib/pdb.py:356: #it appears that that when pdb is reading input from a
pipe
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> Space after the # please.

this code
> is?

particular
> interrupted command from the list of commands to run at the current
breakpoint
> but I may be misreading things as I haven't spent much time in pdb.py.

Done. I've also added a comment to explain what's going on.

http://codereview.appspot.com/216067/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:35:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Mar 2010 19:35:20 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267904120.28.0.359436020938.issue7670@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Sat Mar  6 20:44:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Mar 2010 19:44:02 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1267904642.77.0.314577827461.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Posted to python-dev to solicit feedback on how to handle this.

----------
stage: commit review -> needs patch
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Sat Mar  6 21:01:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Mar 2010 20:01:40 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1267905700.13.0.877416460137.issue6953@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Sat Mar  6 21:04:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Mar 2010 20:04:47 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1267905887.52.0.193338102859.issue7712@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

One advice against using __file__: http://lists.debian.org/debian-python/2010/01/msg00172.html

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Mar  6 21:35:21 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Mar 2010 20:35:21 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267907721.49.0.979800167385.issue8045@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Ported Gregory's fix to py3k and 3.1.

----------
nosy: +benjamin.peterson
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Sat Mar  6 21:40:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Mar 2010 20:40:14 +0000
Subject: [issue8078] add more baud constants to termios
In-Reply-To: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>
Message-ID: <1267908014.01.0.374023266263.issue8078@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib)
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8078>
_______________________________________

From report at bugs.python.org  Sat Mar  6 22:14:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Mar 2010 21:14:56 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267910096.29.0.974980395356.issue8045@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Moving the test to a child process does avoid the problem.
(BTW, so far I've only seen the failure when Tkinter is linked with the Apple-supplied Tk 8.5 in 10.6, not with Tk 8.4.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Sat Mar  6 23:26:16 2010
From: report at bugs.python.org (hamish farrant)
Date: Sat, 06 Mar 2010 22:26:16 +0000
Subject: [issue8081] a.append appends reference , causing unexpected behaviour
In-Reply-To: <1267914376.13.0.68612661566.issue8081@psf.upfronthosting.co.za>
Message-ID: <1267914376.13.0.68612661566.issue8081@psf.upfronthosting.co.za>


New submission from hamish farrant <farrantino at gmail.com>:

Causes modification of an list object to change the values of the object already inside the list.

Example code :

import random
a  =[]
b = [1 , 2 , 3 , 4]
for i in range (15):
    random.shuffle(b)
    a.append(b)
for j in a:
    print j

Expected Behaviour : the list referenced by b , should be appended to a , creating a list of random permutations of b.

----------
components: Interpreter Core
messages: 100548
nosy: hamish.farrant
severity: normal
status: open
title: a.append appends reference , causing unexpected behaviour
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8081>
_______________________________________

From report at bugs.python.org  Sat Mar  6 23:31:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Mar 2010 22:31:57 +0000
Subject: [issue8081] a.append appends reference , causing unexpected behaviour
In-Reply-To: <1267914376.13.0.68612661566.issue8081@psf.upfronthosting.co.za>
Message-ID: <1267914717.62.0.945313518015.issue8081@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Sorry, this is the expected behavior. Copy the list if you want a different one.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8081>
_______________________________________

From report at bugs.python.org  Sat Mar  6 23:45:27 2010
From: report at bugs.python.org (Peter Kleiweg)
Date: Sat, 06 Mar 2010 22:45:27 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1267915527.53.0.454689315113.issue1685453@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

In Python 3.1.1, email.mime.text.MIMEText accepts an 8-bit charset, but not utf-8.

I think you should not have to specify a charset. All strings are unicode now, so I think the package should choose an appropriate charset based on the characters in the text, us-ascii, some iso-8859 charset, or utf-8, whatever fits.


Python 3.1.1 (r311:74480, Oct  2 2009, 11:50:52)                                                                                              
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2                                                                                 
Type "help", "copyright", "credits" or "license" for more information.                                                                        
>>> from email.mime.text import MIMEText                                                                                                      
>>> text = 'H\u00e9'                                                                                                                          
>>> msg = MIMEText(text, 'plain', 'iso-8859-1')                                                                                               
>>> print(msg.as_string())                                                                                                                    
Content-Type: text/plain; charset="iso-8859-1"                                                                                                
MIME-Version: 1.0                                                                                                                             
Content-Transfer-Encoding: quoted-printable                                                                                                   
                                                                                                                                              
H=E9                                                                                                                                          
>>> msg = MIMEText(text, 'plain', 'utf-8')                                                                                                    
Traceback (most recent call last):                                                                                                            
  File "/my/opt/Python-3/lib/python3.1/email/message.py", line 269, in set_charset                                                            
    cte(self)                                                                                                                                 
TypeError: 'str' object is not callable                                                                                                       
                                                                                                                                              
During handling of the above exception, another exception occurred:                                                                           
                                                                                                                                              
Traceback (most recent call last):                                                                                                            
  File "<stdin>", line 1, in <module>                                                                                                         
  File "/my/opt/Python-3/lib/python3.1/email/mime/text.py", line 30, in __init__                                                              
    self.set_payload(_text, _charset)                                                                                                         
  File "/my/opt/Python-3/lib/python3.1/email/message.py", line 234, in set_payload                                                            
    self.set_charset(charset)                                                                                                                 
  File "/my/opt/Python-3/lib/python3.1/email/message.py", line 271, in set_charset                                                            
    self._payload = charset.body_encode(self._payload)                                                                                        
  File "/my/opt/Python-3/lib/python3.1/email/charset.py", line 380, in body_encode                                                            
    return email.base64mime.body_encode(string)                                                                                               
  File "/my/opt/Python-3/lib/python3.1/email/base64mime.py", line 94, in body_encode                                                          
    enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")                                                                                  
TypeError: must be bytes or buffer, not str                                                                                                   
>>>

----------
nosy: +pebbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685453>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:31:36 2010
From: report at bugs.python.org (Daniel Eloff)
Date: Sat, 06 Mar 2010 23:31:36 +0000
Subject: [issue8082] Misleading exception when raising an object
In-Reply-To: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>
Message-ID: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>


New submission from Daniel Eloff <dan.eloff at gmail.com>:

>>> class Foo(object):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: exceptions must be classes or instances, not Foo
>>> class Foo(Exception):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
Foo
>>> class Foo(BaseException):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
Foo

It seems exceptions can only be subclasses of BaseException, the error message is confusing and false.

----------
messages: 100551
nosy: Daniel.Eloff
severity: normal
status: open
title: Misleading exception when raising an object
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8082>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:34:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Mar 2010 23:34:07 +0000
Subject: [issue8059] @unittest.skip on a test method should prevent setUp from
	running
In-Reply-To: <1267733102.38.0.63862334356.issue8059@psf.upfronthosting.co.za>
Message-ID: <1267918447.53.0.662343082316.issue8059@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8059>
_______________________________________

From report at bugs.python.org  Sun Mar  7 00:56:52 2010
From: report at bugs.python.org (steven Michalske)
Date: Sat, 06 Mar 2010 23:56:52 +0000
Subject: [issue8062] PEP 3101 string formatting missing hexadecimal separator
	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267919812.64.0.109923342027.issue8062@psf.upfronthosting.co.za>


steven Michalske <smichalske at gmail.com> added the comment:

Sorry my request is for output,  I am not requesting input.  The examples were for showing the use in other contexts of using an underscore as a word (4 hex digits) seperaror.

My assertions are from another area aside from computer languages,  but from documentation for components.  So I showed a documentation example and software examples that used or would not accept underscores.

the common pratice of using a space is not good for computer output to be used for parsing in following applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8062>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:12:39 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 07 Mar 2010 00:12:39 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1267920759.18.0.862454038055.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

> Also, can you take a look at how the pdb unittests work and see if you
can come up with a way to unittest the KeyboardInterrupt behavior?

Yes, this is doable. In fact, I already have such tests written (unix only though). The tests are assert based but it should not be difficult to convert them to unittest. Moreover, I have many more tests for pdb written in the same style. 

However, these tests are not easily (and possibly not at all) integratable with existing test_pdb.py module. (See below for the problems). So would it be acceptable to have these tests as a separate module (test_pdb2.py or some such)? (I might also need some help with integrating the module)

Background
----------

Here is the basic problem: testing/debugging a debugger is hard by itself (you need to deal with 2 programs at once: the one being debugged and the debugger which run intermittently), now throw in doctest and it becomes much harder (as everything you do now gets covered by another layer). And now we need to test signals and some of the tests will likely be platform specific which makes it even worse. 

In contrast, in my tests the snippets of code are written into a tmp file and then are fed into debugger, the debugger itself is run as a subprocess. So if a test fails, it can be easily rerun under debugger manually and you can  test for things like pdb exits and stalls.

Here is a snippet from my pdb tests (just to give an idea how they would look like: essentially, send a command to pdb, check the response).


  pdb=PdbTester("pdb_t_hello","""\
  import time
  for i in xrange(100000000):
     time.sleep(0.05)
  """)

  pdb.pdbHandle.stdin.write("c\n")
  time.sleep(0.01)
  #pdb_t_hello running, try to interrupt it
  pdb.pdbHandle.send_signal(signal.SIGINT)
  pdb.waitForPrompt()
  pdb.queryAndMatch("p i", "0")
  pdb.query("n")
  pdb.query("n")
  pdb.queryAndMatch("p i", "1")
  pdb.query("s")
  pdb.query("s")
  pdb.queryAndMatch("p i","2")
  pdb.pdbHandle.stdin.write("c\n")
  time.sleep(0.03)
  pdb.pdbHandle.send_signal(signal.SIGINT)
  pdb.waitForPrompt()
  pdb.queryAndMatch("p i","3")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sun Mar  7 02:04:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Mar 2010 01:04:27 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1267923867.0.0.630393597646.issue7849@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16120/issue7849_check_warnings_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Sun Mar  7 02:07:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Mar 2010 01:07:43 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1267924063.69.0.329246670547.issue7849@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch updated.

----------
assignee:  -> flox
resolution:  -> accepted
versions: +Python 3.2
Added file: http://bugs.python.org/file16471/issue7849_check_warnings_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:02:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 07 Mar 2010 00:02:37 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1267920157.57.0.648400731244.issue8065@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

It appears that the tests that I attached fail when libedit is used.  This is clearly due to bugs in libedits readline emulation:

1. read_history does not update history_length

2. history_truncate_file does not preserver the history cookie ("_HiStOrY_V2_").

Does anyone know where libedit bugs should be reported?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Sun Mar  7 01:02:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Mar 2010 00:02:53 +0000
Subject: [issue8082] Misleading exception when raising an object
In-Reply-To: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>
Message-ID: <1267920173.91.0.558796050459.issue8082@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done in r78746.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8082>
_______________________________________

From report at bugs.python.org  Sun Mar  7 02:22:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Mar 2010 01:22:35 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1267924955.11.0.827718055237.issue7564@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> flox
priority: low -> normal
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:19:46 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:19:46 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267931986.94.0.220204408.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16473/queues.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:19:12 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:19:12 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267931952.46.0.261297350095.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Updated patch to include new test (now against release26-maint branch). Verified test_multiprocessing suite passes before (apart from new test) & after change. (Tested under Ubuntu 9.10 64-bit)

----------
Added file: http://bugs.python.org/file16473/queues.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:22:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 03:22:46 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267932166.07.0.369256589352.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello again

And now for something completely different: more builtin/built-in/built in fixes. I hope it?s okay to edit Misc/HISTORY and old Misc/NEWS entries.

Note that I fixed two unrelated typos that I noticed near ?builtin? uses.

Some day I?ll do something more useful for Python.

Cheers

----------
Added file: http://bugs.python.org/file16474/moreboredom.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:10:12 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:10:12 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267931412.37.0.129304470081.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16415/pickle_suggestion_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:17:10 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:17:10 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267931830.82.0.00462102242805.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Updated patch to include new test (now against release26-maint branch). Verified test_multiprocessing suite passes before (apart from new test) & after change. (Tested under Ubuntu 9.10 64-bit)

----------
Added file: http://bugs.python.org/file16472/queues.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:37:46 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:37:46 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267933066.38.0.289221546412.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Removed file: http://bugs.python.org/file16472/queues.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 04:37:55 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 07 Mar 2010 03:37:55 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267933075.7.0.88932545835.issue8037@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Added file: http://bugs.python.org/file16475/queues.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:05:40 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 07 Mar 2010 04:05:40 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267934740.91.0.529978366311.issue1530559@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> If anyone's interested in submitting a patch, it would be welcome.

Sure.  I saw where this was partly addressed in r78690.  The attached patch adds support for the '__index__' conversion that Mark
suggested.  

At first glance, the patch may seem more than what is needed.  However, most of the diffs are due to pulling parts of the C
implementation into a Python veneer.  This will make preprocessing work (like what was needs for this fix) easier now and in the future.  In addition, it will lay a small amount of groundwork for the changes that are needed for resolving issue 3132.  As that work will be simplified by having the veneer as well.

----------
nosy: +minge
Added file: http://bugs.python.org/file16476/issue-1530559.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:12:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 04:12:00 +0000
Subject: [issue1410680] Add 'surgical editing' to ConfigParser
Message-ID: <1267935120.95.0.865772105712.issue1410680@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1410680>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:39:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Mar 2010 04:39:14 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1267936754.68.0.631085459474.issue7540@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Change is reverted from other branches too. Discussed in IRC, that changes made to an existing API like add_data,may break some existing applications, even if its done to prevent unsupported usage. 

Specifically, in mechanize's case, it was not reusing req object, but using add_data method more than once before req was getting submitted. This is under scenarios wherein code as in zope.testbrowser) is centered on the browser controls; any twiddle to a control could update the req object before its submitted. This could be changed in mechanize, but in general agreed to fact that changes to existing API should not result in breaking of apps.

We can address the non-reusablity of request by adding a boolean that signifies if a request has been used and throw an exception if one is used a second time ( benji's suggestion). And of course clarify the supported and intended scenarios via documentation.

----------
resolution: fixed -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Sun Mar  7 07:30:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 06:30:19 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267943419.09.0.91655721641.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here is the path that rewraps lines longer than 80 characters.

Note that it is possible than some lines were unnecessarily rewrapped; I?m not really sure whether my editor displays the characters count or the index of the next character. Sorry about that.

I?ve noticed that some parts were wrapped to 72 characters and other to 80. PEP?8 tells to wrap text to 72 characters in Python files; is there a similar guideline for the doc anywhere?

If anyone know of a tool that can report lines longer that a certain length (preferably encoding-aware, i.e. counting characters and not bytes), I?d be glad to hear of it.

Cheers

----------
Added file: http://bugs.python.org/file16479/some-rewrapping.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 06:54:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 05:54:54 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267941294.61.0.57692877639.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I grepped for ?built-in? in Doc and found very few misuses. Patch attached.

Some lines needed rewrapping, I made another patch for this to ease reviewing.

Cheers

----------
Added file: http://bugs.python.org/file16478/doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 07:02:14 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Mar 2010 06:02:14 +0000
Subject: [issue8045] test_tcl aborts on OS X 10.6 with "The application with
	bundle ID org.python.python is running setugid(),
	which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267941734.96.0.698852540314.issue8045@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

merged into release26-maint r78754.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8045>
_______________________________________

From report at bugs.python.org  Sun Mar  7 05:54:52 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 07 Mar 2010 04:54:52 +0000
Subject: [issue8039] precedence rules for ternary operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267937692.96.0.318994422085.issue8039@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

It seems to me from the grammar (http://docs.python.org/reference/expressions.html#grammar-token-conditional_expression) that the precedence for conditional expressions fall in between that of 'lambda' and 'or' expressions.

----------
keywords: +patch
nosy: +minge
versions: +Python 2.7
Added file: http://bugs.python.org/file16477/issue-8039.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8039>
_______________________________________

From report at bugs.python.org  Sun Mar  7 08:22:52 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 07:22:52 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267920157.57.0.648400731244.issue8065@psf.upfronthosting.co.za>
Message-ID: <3D10CA0A-CDA9-4875-B208-46BADF2BB462@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 7 Mar, 2010, at 1:02, Alexander Belopolsky wrote:
> 
> 
> Does anyone know where libedit bugs should be reported?

Apple's bugreporter. (bugreport.apple.com, you need an ADC account to report bugs).

----------
Added file: http://bugs.python.org/file16480/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100307/d10c42d5/attachment.bin>

From report at bugs.python.org  Sun Mar  7 10:14:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 09:14:22 +0000
Subject: [issue7998] MacPython 2.7a3 posix_spawn error for build using
	--with-framework-name
In-Reply-To: <1266910189.84.0.492306912925.issue7998@psf.upfronthosting.co.za>
Message-ID: <1267953262.34.0.984108669734.issue7998@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fix in r78755 (2.7) and r78756 (3.2)


(the issue doesn't affect 2.6 or 3.1 because those have another implementation of the python/pythonw command)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7998>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:23:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 09:23:36 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1267953816.19.0.392186452335.issue8067@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Barry and Benjamin: IMHO this should be fixed before 2.6.5 and 3.1.2 are released, the patch is safe and works (and is already in the trunk).

----------
nosy: +barry, benjamin.peterson
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:27:13 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 09:27:13 +0000
Subject: [issue8066] OS X installer: readline module breaks when targeting on
	10.5 or 10.6
In-Reply-To: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>
Message-ID: <1267954033.39.0.988515362444.issue8066@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Barry: this definitely needs to be applied before 2.6.5 is released, without the patch I cannot build the mac installers.

The patch disables support for libedit when targetting 10.4, which is IMHO correct because as Ned notes libedit's readline emulation is totally broken in 10.4.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8066>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:35:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 09:35:48 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1267954548.73.0.27056463306.issue7995@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've removed 2.5 and added 3.2 because there won't be further bugfix releases of 2.5 and the issue also affects 3.2.

IMHO changing this behavior is not a bugfix and is therefore out of scope for 2.6.x, in particular because this change might break code that runs fine on OSX and assumes the current behavior.

The documntation is not entirely clear on the behavior of the accept method, the best I could find is the documentation of the setblocking method: that says that all sockets are blocking by default, that would mean that the result of accept should be a blocking socket.

I'm therefore +1 for this change. I'm setting the 'needs review' flag because I'd like some input from other developers as well.

----------
keywords: +needs review
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Mar  7 10:40:11 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 09:40:11 +0000
Subject: [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1267954811.89.0.243870833414.issue5262@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I propose to at least change the code in pythonlauncher to warn if it is the default association for python files, that is to reverse the test that it currently does.

That way users can still set pythonlauncher as the launcher for a specific files, but would get a warning when they make pythonlauncher the default action for python files.

BTW. I still think that pythonlauncher is unsafe and should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5262>
_______________________________________

From report at bugs.python.org  Sun Mar  7 11:56:44 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 07 Mar 2010 10:56:44 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267959404.63.0.797557496434.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

It has been brought up several times that ET is special in the stdlib in that it is an externally maintained package. Correct me if I'm wrong, but the rules seem to be: features come outside, adaptation to Py3 can happen inside. What we are talking about here is a new feature that makes sense for both Py2 and Py3. We are not talking about a bug fix, neither is this an adaptation to Py3. It is a new feature that was added inside of the standard library and that is not compatible with the external libraries that are supposed to implement the same interface, namely, ElementTree and lxml.etree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sun Mar  7 12:22:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 11:22:54 +0000
Subject: [issue8083] urllib proxy interface is too limited
In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za>
Message-ID: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The proxy support code in urllib is imho too specific and cannot easily support dynamic proxy configuration using a proxy.pac file.

That is, the code assumes that there is at most one proxy per protocol, while this is not quite true in practice.  A proxy.pac can refer different URLs to different proxies (or exclude some from proxying).

This could be solved by adding a new proxy hook to urllib, something like:

def getproxies_for_url(url) -> [info, ...]

That is, the argument is the string for an URL, the result is a list of proxies that can be used to fetch the URL.

This hook would allow us to provide a hook on OSX that enables python scripts to use the system proxy settings, even when those are complex (such as by using proxy autoconfiguration).

----------
components: Library (Lib)
messages: 100573
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: urllib proxy interface is too limited
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8083>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:08:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 12:08:05 +0000
Subject: [issue8002] on OSX the file creation date not available in os.stat
In-Reply-To: <1266938492.4.0.0671883953878.issue8002@psf.upfronthosting.co.za>
Message-ID: <1267963685.47.0.466914555027.issue8002@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've done some research: the st_birthtime field is available when the python executable is build using MACOSX_DEPLOYMENT_TARGET=10.5 (or later), not for 10.4.

Adding support for st_birthtime for MACOSX_DEPLOYMENT_TARGET=10.4 is possible but requires significant code duplication in posixmodule.c. 

IMO it adding this support is not worth the effort or the additional code complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8002>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:10:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 12:10:47 +0000
Subject: [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1267963847.75.0.373646123937.issue7072@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a patch that fixes the issue and enables all test_locale tests on OSX 10.6. 

(I will test if the tests can also be enabled on 10.5 when applying the patch).

----------
keywords: +needs review, patch
resolution:  -> accepted
Added file: http://bugs.python.org/file16481/issue7072.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7072>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:22:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2010 12:22:56 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267964576.65.0.754954897344.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch to restore the old usage of __int__ to convert non-integer arguments;  it also produces a DeprecationWarning whenever __int__ is used in this way.  For consistency and simplicity, __int__ will be tried for *any* non-integer argument when packing with an integer format;  this goes beyond the conversions that 2.6 allows. (In 2.6, the behaviour is somewhat random: it works only for 'bBhHil' in native mode and 'bhil' in non-native mode.)

It doesn't seem worth deliberately trying __long__ as well, so I've left that out.  So there's still some possibility for breakage relative to 2.6, when (1) packing using 'Q' or 'q', *and* (2) the object to be packed defines __long__ but not __int__, or defines both __long__ and __int__ in inconsistent ways.  The likelihood of (2) seems small enough that this isn't worth worrying about in practice (and the workaround is easy, too).

Andreas, are you in a position to test this patch?

Supporting conversions to integer via __index__ is orthogonal to this;  I'll take a look at Meador's patch shortly.

----------
Added file: http://bugs.python.org/file16482/issue1530559__int__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:29:11 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 12:29:11 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The implementation of pep-0370 treats OSX like any other unix platform. 

This is problemantic for two reasons: first of all OSX already had a per-user directory before pep-0370 was implement: ~/Library/Python/X.Y, which means there are now two per-user directories on OSX. Secondly the pep-0370  per-user directory does not honor platform conventions.

I therefore propose to change pep-0370 behavior on OSX: 
* remove ~/.local as the user-base
* upgrade ~/Library/Python/X.Y to a pep-0370 compatible directory
  (that is: introduce the additional subdirectories that are used
   in pep-0370)
* upgrade /Library/Python/X.Y to the same structure

----------
assignee: ronaldoussoren
components: Installation, Library (Lib), Macintosh
keywords: needs review
messages: 100577
nosy: ronaldoussoren
severity: normal
status: open
title: pep-0370 on osx duplicates existing functionality
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sun Mar  7 13:33:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 12:33:48 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1267965228.57.0.843985104128.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch is untested an implements the proposed behavior for framework builds, unix builds would keep the unix-style behavior (and would lose access to ~/Library/Python).

The patch is slightly complicated by adding support for --with-framework-name as well, but that shouldn't make the patch harder to read.

BTW. The "needs review" part is more for the proposed change in behavior that for the actual patch, I'm confident that I can create a correct patch but I'm not sure if the change is behavior is uncontroversial.

----------
keywords: +patch
Added file: http://bugs.python.org/file16483/issue8084.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:25:02 2010
From: report at bugs.python.org (Floris van Manen)
Date: Sun, 07 Mar 2010 13:25:02 +0000
Subject: [issue8002] on OSX the file creation date not available in os.stat
In-Reply-To: <1267963685.47.0.466914555027.issue8002@psf.upfronthosting.co.za>
Message-ID: <2AE24F23-88BD-4BFF-8F2A-E9DB721B39C5@klankschap.nl>


Floris van Manen <vm at klankschap.nl> added the comment:

On Mar 7, 2010, at 13:08, Ronald Oussoren wrote:

> IMO it adding this support is not worth the effort or the additional code complexity.

I do agree.
We have to look forwards ...

F

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8002>
_______________________________________

From report at bugs.python.org  Sun Mar  7 14:29:51 2010
From: report at bugs.python.org (Florian Weimer)
Date: Sun, 07 Mar 2010 13:29:51 +0000
Subject: [issue8085] PyObject_GC_VarNew should be PyObject_GC_NewVar
In-Reply-To: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>
Message-ID: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>


New submission from Florian Weimer <fw at deneb.enyo.de>:

The manual mentions the wrong C function (Var and New are transposed).

----------
assignee: georg.brandl
components: Documentation
messages: 100580
nosy: fw, georg.brandl
severity: normal
status: open
title: PyObject_GC_VarNew should be PyObject_GC_NewVar
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8085>
_______________________________________

From report at bugs.python.org  Sun Mar  7 15:14:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2010 14:14:48 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267971288.1.0.715408675514.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch, with slightly saner warnings checks.

----------
Added file: http://bugs.python.org/file16484/issue1530559__int__2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 15:41:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Mar 2010 14:41:09 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267972869.88.0.936112865053.issue8047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Florent said, it is a rule of py3k to avoid implicit encoding/decoding. The fact that it could have made sense for 2.x as well is not relevant, since the change was only done in py3k (and for good reason: we normally try not to break compatibility without prior notice).

In any case, I have trouble understanding your concern here. Do you think the change is bad? Is it really that difficult to support it in lxml?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:11:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 15:11:25 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267974685.33.0.797477915709.issue5341@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Georg can correct me if I'm wrong, but I believe we generally only rewrap lines when we change the text for some other reason.  My observation was that Georg re-wraps doc text to 79 chars, so that's what I've been doing.  PEP 8 really only applies to source files, the docs are (at least currently) Georg's demesne.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:24:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Mar 2010 15:24:10 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267975450.14.0.917824221816.issue5341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

David is correct, rewrapping while editing is intrusive enough.

The docs should be wrapped at 79/80 characters.  The reason that most files have longer lines is that the latex to rest converter tool had a flaw in the wrapping code that I didn't notice until after the conversion.

Applied the two other patches in r78760.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:25:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 15:25:57 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1267974685.33.0.797477915709.issue5341@psf.upfronthosting.co.za>
Message-ID: <4B93C582.1030301@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> rewrap lines when we change the text for some other reason.
Doesn?t that make harder to review the real changes when they are mixed 
with rewrapping?

 > PEP 8 really only applies to source files, the docs are (at least
 > currently) Georg's demesne.
(domain?) I was only citing PEP 8 as a reference, since there are some 
indications about line length of text paragraphs.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:28:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Mar 2010 15:28:20 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267975700.78.0.532824268905.issue5341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> > rewrap lines when we change the text for some other reason.
> Doesn?t that make harder to review the real changes when they are mixed 
> with rewrapping?

That's true. I wouldn't do it in patches I mean someone else to review. But many times it's the other way round: I apply doc changes from some patch, and then rewrap before committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:40:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 15:40:56 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1267976456.75.0.248441565561.issue5341@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, I meant demense (I even looked up the spelling).  The word is related to domain, but has a somewhat more precise shading of meaning :)

     A lord's chief manor place, with that part of the lands
     belonging thereto which has not been granted out in tenancy;
     a house, and the land adjoining, kept for the proprietor's
     own use. [Written also {demain}.] --Wharton's Law Dict.

In other words, Georg is lord of this particular manor, unless he assigns a piece to someone else...it seemed in keeping with the Python tradition of having a BDFL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 16:51:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Mar 2010 15:51:36 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1267976456.75.0.248441565561.issue5341@psf.upfronthosting.co.za>
Message-ID: <4B93CB81.5030004@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the new word. (I checked with my local dictd but not on the 
Intertubes, should have).

Having designated active maintainers for modules and areas is indeed great.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:20:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Mar 2010 16:20:06 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267953816.19.0.392186452335.issue8067@psf.upfronthosting.co.za>
Message-ID: <1afaf6161003070820o474673f8g7836d54ce710f1db@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/3/7 Ronald Oussoren <report at bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> Barry and Benjamin: IMHO this should be fixed before 2.6.5 and 3.1.2 are released, the patch is safe and works (and is already in the trunk).

Ok. Would you mind merging it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:32:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2010 16:32:25 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267979545.95.0.218533698721.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Restored use of __int__ for all integer conversion codes in r78762.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:51:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2010 16:51:59 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267980719.1.0.531737465331.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Recent checkins messed up Meador Inge's __index__ patch;  here's a regenerated version.

----------
Added file: http://bugs.python.org/file16485/issue-1530559__index__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 17:58:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 16:58:18 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267981098.82.0.378387609199.issue7143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your patch looks good, thank you.

I just realized that Barry isn't nosy on this issue.  I've checked, and the code in question dates back to email version 1.0...code of that long standing that exists specifically to implement the behavior we propose to change makes me wonder what we will break if we fix it.  Yet the current behavior seems clearly contrary to the RFCs to me.

Barry?  Any memory of why _bdecode exists and what will break if we fix it?

In any case I suspect that backporting this fix might be a bad idea, since existing code may be compensating for the current behavior and break if the behavior is fixed.

----------
nosy: +barry
versions:  -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:11:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Mar 2010 17:11:08 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1267981868.98.0.0843760183513.issue7173@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r78766.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:20:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Mar 2010 17:20:00 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1267982400.42.0.796704959189.issue1530559@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Comments and thoughts on the __index__ patch:

(1) Thank you for a remarkably complete patch!

(2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer on top of the C layer.  Partly I'm worried about accidentally breaking something (it's not 100% clear to me whether there might be hidden side-effects to such a change), but I also notice that this seems to have a significant impact on performance.  In fact, I seem to recall that the previously existing Python component of the struct module was absorbed into Modules/_struct.c precisely for performance reasons.

A quick, unscientific benchmark:  the time taken to run test_struct with this patch (excluding the changes to test_struct itself) on my machine (OS X 10.6, 64-bit non-framework non-debug build of Python) is around 1.52--1.53 seconds;  without the patch it's around 1.02--1.03 seconds.

(3) For 3.x, and for the issue 3132 work, I agree it might make sense to have a fatter Python layer;  this would also help other Python implementations that are trying to keep up with CPython.  I'm still a bit worried about performance, though.

(4) For 2.x, perhaps we don't need the extra __index__ functionality anyway, now that the previous use of __int__ has been restored.  That would give us a bit more time to think about this for 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Sun Mar  7 18:56:30 2010
From: report at bugs.python.org (Chris)
Date: Sun, 07 Mar 2010 17:56:30 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>


New submission from Chris <chris0wj at gmail.com>:

I'm using ssl.get_server_certificate function. It returns a pem string. For each server I try, I get the string, but it is missing a newline "\n" before the -----END CERTIFICATE----- text. Any subsequent use of the string makes openssl throw up with a "bad end line" error.

ssl.PEM_cert_to_DER_cert can be used, and, subsequently the der string can be used elsewhere.

Example:
>>> fncert = ssl.get_server_certificate(("freenode.net", 443), 3)
>>> fncert
'-----BEGIN CERTIFICATE-----\nMIICFTCCAX6gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMRswGQYDVQQKExJBcGFj\naGUgSFRUUCBTZXJ2ZXIxIjAgBgNVBAsTGUZvciB0ZXN0aW5nIHB1cnBvc2VzIG9u\nbHkxEjAQBgNVBAMTCWxvY2FsaG9zdDAeFw0wNzA1MDkxODM2MjVaFw0wODA1MDgx\nODM2MjVaMEwxGzAZBgNVBAoTEkFwYWNoZSBIVFRQIFNlcnZlcjEZMBcGA1UECxMQ\nVGVzdCBDZXJ0aWZpY2F0ZTESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3\nDQEBAQUAA4GNADCBiQKBgQDYqJO6X9uwU0AyJ6H1WgYCZOqpZvdI96/LaDumT4Tl\nD6QvmXzAbM4okSHU3FEuSqR/tNv+eT5IZJKHVsXh0CiDduIYkLdqkLhEAbixjX/1\nfdCtGL4X0l42LqhK4TMFT5AxxsP1qFDXDvzl/yjxo9juVuZhCeqFr1YDKBffCIAn\ncwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAG0zi/KyzHxSsLHfrwTFh9330TaGj/3H\nuvhmBUPC3FOxbIH2y5CG/Ddg46756cfaxKKiqJV3I4dAgatQybE65ELc3wOWgs4v\n4VDGsFKbkmBLuCgnFaY+p4xvr2XL+bJmpm8+IQqW5Ob/OUSl7Vj4btHhF6VK29CI\n+DexDLRI0KqZ-----END CERTIFICATE-----\n'

Notice no "\n" before -----END CERTIFICATE-----\n

Platform: 
Linux x64
python 2.6.4

----------
messages: 100595
nosy: offero
severity: normal
status: open
title: ssl.get_server_certificate new line missing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:04:03 2010
From: report at bugs.python.org (Joaquin Cuenca Abela)
Date: Sun, 07 Mar 2010 18:04:03 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267985043.76.0.273788296801.issue7143@psf.upfronthosting.co.za>


Joaquin Cuenca Abela <e98cuenc at gmail.com> added the comment:

Unfortunately the only way that I can see to reliably work around this is to bypass entirely get_payload, in this case fixing this bug will not affect people that do that negatively.

Some people may have more control over their attachments and they are unconditionally adding a \n to certain type of attachments. In this case they will get an extra \n after this patch.

If they are doing this, they certainly realized there was a bug, because this is only necessary for base64 encoded attachments and not for any other encoding. In this case I guess it's reasonable to expect that this bug will be fixed one day.

But you're right that the change is risky, an that we (at least I) are not sure why the code is the way it is.

Cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:17:52 2010
From: report at bugs.python.org (Chris)
Date: Sun, 07 Mar 2010 18:17:52 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267985872.08.0.394416002746.issue8086@psf.upfronthosting.co.za>


Chris <chris0wj at gmail.com> added the comment:

Did some more research and found this as the culprit:

in Lib/ssl.py

#############################
...
def get_server_certificate(addr, ssl_version=PROTOCOL_SSLv3, ca_certs=None):
...
    return DER_cert_to_PEM_cert(dercert)

def DER_cert_to_PEM_cert(der_cert_bytes):

    """Takes a certificate in binary DER format and returns the
    PEM version of it as a string."""

    if hasattr(base64, 'standard_b64encode'):
        # preferred because older API gets line-length wrong
        f = base64.standard_b64encode(der_cert_bytes)
        return (PEM_HEADER + '\n' +
                textwrap.fill(f, 64) +
                PEM_FOOTER + '\n')
    else:
        return (PEM_HEADER + '\n' +
                base64.encodestring(der_cert_bytes) +
                PEM_FOOTER + '\n')

############################

Notice no '\n' before the PEM_FOOTER

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:21:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 07 Mar 2010 18:21:03 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1267986063.2.0.164073290109.issue7162@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unfortunately this patch would also replace legitimate uses of a "file" function.

----------
assignee:  -> benjamin.peterson
nosy: +amaury.forgeotdarc, benjamin.peterson
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:27:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 18:27:08 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267986428.27.0.776611899349.issue8086@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think that's because encodestring tacks a 'courtesy newline' on to the end of the output it returns.  textwrap.fill does't, and I'm guessing that's the code path that your installation is taking.

----------
components: +Library (Lib)
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:27:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 18:27:20 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267986440.69.0.063968503466.issue8086@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sun Mar  7 19:30:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Mar 2010 18:30:48 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267986648.93.0.893625586028.issue8086@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sun Mar  7 20:40:09 2010
From: report at bugs.python.org (Diego Mascialino)
Date: Sun, 07 Mar 2010 19:40:09 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>


New submission from Diego Mascialino <dmascialino at gmail.com>:

Example:

---------------- mod.py ----------------
def f():
    a,b,c = 1,2
    print b
----------------------------------------

If i do:

>>> import mod
>>> mod.f()

I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f
    a,b,c = 1,2
ValueError: need more than 2 values to unpack


If i fix the source:

---------------- mod.py ----------------
def f():
    a,b,c = 1,2,3
    print b
----------------------------------------

And do:

>>> mod.f()

I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f
    a,b,c = 1,2,3
ValueError: need more than 2 values to unpack

The problem is that the source shown is updated, but the executed code is old, because it wasn't reloaded.

Feature request:

If the source code shown was modified after import time and it wasn't reloaded, a warning message should be shown.

Example:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f      WARNING: Modified after import!
    a,b,c = 1,2,3
ValueError: need more than 2 values to unpack

or something like that. Maybe "use reload()" might appear.

----------
components: Interpreter Core
messages: 100600
nosy: dmascialino, jjconti
severity: normal
status: open
title: Unupdated source file in traceback
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Sun Mar  7 20:50:39 2010
From: report at bugs.python.org (Luciano Bello)
Date: Sun, 07 Mar 2010 19:50:39 +0000
Subject: [issue8085] PyObject_GC_VarNew should be PyObject_GC_NewVar
In-Reply-To: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>
Message-ID: <1267991439.18.0.928504161864.issue8085@psf.upfronthosting.co.za>


Luciano Bello <lbello at gmail.com> added the comment:

patch added

----------
keywords: +patch
nosy: +Luciano.Bello
Added file: http://bugs.python.org/file16486/PyObject_GC_VarNew_type.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8085>
_______________________________________

From report at bugs.python.org  Sun Mar  7 20:53:59 2010
From: report at bugs.python.org (Luciano Bello)
Date: Sun, 07 Mar 2010 19:53:59 +0000
Subject: [issue8085] PyObject_GC_VarNew should be PyObject_GC_NewVar
In-Reply-To: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>
Message-ID: <1267991639.56.0.500890892039.issue8085@psf.upfronthosting.co.za>


Changes by Luciano Bello <lbello at gmail.com>:


----------
nosy: +jjconti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8085>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:23:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Mar 2010 20:23:46 +0000
Subject: [issue8059] @unittest.skip on a test method should prevent setUp from
	running
In-Reply-To: <1267733102.38.0.63862334356.issue8059@psf.upfronthosting.co.za>
Message-ID: <1267993426.68.0.709825286077.issue8059@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Fixed revision 78770.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8059>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:24:38 2010
From: report at bugs.python.org (Tom Loredo)
Date: Sun, 07 Mar 2010 20:24:38 +0000
Subject: [issue7998] MacPython 2.7a3 posix_spawn error for build using
	--with-framework-name
In-Reply-To: <1267953262.34.0.984108669734.issue7998@psf.upfronthosting.co.za>
Message-ID: <1267993474.4b940b82b0bb5@astrosun2.astro.cornell.edu>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> Fix in r78755 (2.7) and r78756 (3.2)

Thanks for your attention to this, Ronald---and all the hard
work on the OS X support.

-Tom

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7998>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:39:51 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Mar 2010 20:39:51 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1267994391.01.0.730552614332.issue7670@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm going to let this one stay for 2.6.5 since we need another rc anyway.  Thanks for the fix!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7670>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:42:10 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Mar 2010 20:42:10 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1267994530.99.0.479482027913.issue8067@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Ned, thanks for the fix.  Ronald, please apply it to release26-maint for 2.6.5 rc 2.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:45:00 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Mar 2010 20:45:00 +0000
Subject: [issue8066] OS X installer: readline module breaks when targeting on
	10.5 or 10.6
In-Reply-To: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>
Message-ID: <1267994700.24.0.379733898408.issue8066@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Ned, thanks again for another great OS X fix.  Ronald, please apply this to release26-maint for 2.6.5 rc 2.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8066>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:48:45 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Mar 2010 20:48:45 +0000
Subject: [issue8082] Misleading exception when raising an object
In-Reply-To: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>
Message-ID: <1267994925.11.0.0287981779699.issue8082@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Minor nit: it's questionable whether this should have gone in between 2.6.5 rc1 and rc2.  It doesn't seem like a critical fix.  OTOH, it also seems harmless enough so I'm gonna let it slide.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8082>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:53:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 07 Mar 2010 20:53:12 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1267995192.15.0.620514267133.issue8087@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Displaying a warning whenever the code has changed on disk is clearly unacceptable - it is both expensive to check (and also, how frequent would you check?), and it would be annoying if you have long-running Python applications so this would just clutter the log files.

-1 on this request; users should just learn this aspect of Python. Also, it is not possible to get this perfect for many reasons, e.g. when you change a class, it will be impossible to update the code of existing instances even with reload.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Sun Mar  7 21:58:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Mar 2010 20:58:41 +0000
Subject: [issue8085] PyObject_GC_VarNew should be PyObject_GC_NewVar
In-Reply-To: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>
Message-ID: <1267995521.87.0.721232406409.issue8085@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r78771.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8085>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:10:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Mar 2010 21:10:36 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267996236.29.0.848611475409.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, here is my patch "version 4", based on jerry's nothreads_3.patch. Changes between version 3 and 4:

 - test_support: threading_setup() returns (1,) instead of None; reap_threads()
   simply returns the function instead of a dummy decorator
 - regrtest.py: display an error if -j/--multiprocess option is used
 - ctypes/test/test_errno.py, test_smtplib, test_socket, test_asynchat: skip
   some tests, not the whole file
 - test_logging, test_xmlrpc, test_file2k: move decorator from setUp() method
   to the class
 - test_capi: test threading variable value instead of the presence of the
   _test_thread_state function
 - test_capi, test_contextlib: move the decorator from methods to the class
 - test_multiprocessing: import threading (without try/except) after
   _multiprocessing because _multiprocessing depends on threading and so it
   will fail

All tests pass on both builds: with and without threads.

I'm not sure that my changes moving decorators from the setUp() method or other methods to the class is the right thing to do.

FYI tests skipped because of the missing thread module are listed in "xx skips unexped on linux2: ...". I don't think that it's a problem. We discuss about that on IRC and bitdancer suggested to leave regrtest.py unchanged:

"bitdancer> You should *definitely* not disable the skip message just because the threading module is missing, that would defeat the whole purpose of the message."

----------
Added file: http://bugs.python.org/file16487/nothreads_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:13:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Mar 2010 21:13:25 +0000
Subject: [issue8039] precedence rules for ternary operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267996405.47.0.669199731611.issue8039@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

if-else actually was already documented, under "boolean expressions".  It was merely missing from the precendence table.

I've now given it its own section, to make it stand out a bit better.  See r78772.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8039>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:24:34 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Sun, 07 Mar 2010 21:24:34 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1267997074.93.0.37789531215.issue7162@psf.upfronthosting.co.za>


Ryan Coyner <rcoyner at gmail.com> added the comment:

I thought the whole point was that file[1] was removed in 3.0[2]? Or, are you saying that if somebody overloaded file with def file(...)? If that is the case would it be reasonable to check like this?

>>> file in list(__builtins__.__dict__.values())
True
>>> def file():
...     pass
... 
>>> file in list(__builtins__.__dict__.values())
False
>>> 


[1] - http://docs.python.org/library/functions.html?highlight=file#file
[2] - http://docs.python.org/3.1/whatsnew/3.0.html#builtins

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:32:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Mar 2010 21:32:21 +0000
Subject: [issue8044] Py_EnterRecursiveCall and Py_LeaveRecursiveCall are
	undocumented
In-Reply-To: <1267582984.0.0.0717168026591.issue8044@psf.upfronthosting.co.za>
Message-ID: <1267997541.11.0.674315510625.issue8044@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks! I've added documentation in r78773.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8044>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:32:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Mar 2010 21:32:49 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1267997569.81.0.819193446976.issue7300@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Sun Mar  7 22:46:10 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Mar 2010 21:46:10 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1267998370.0.0.241901831286.issue7143@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for adding me to the nosy list.  Yep, this code is pretty old so it doesn't surprise me that its implementation isn't quite right.  Of course, I hate get_payload(decode=True) anyway and hope that goes away in email 6.

Having said that, I don't think this can be changed in Python 2.6.  It's pretty common for people to have workarounds for the devil they know and I'd bet that changing this behavior in 2.6.x would break people's code.  I'm okay for doing the sensible thing in Python 2.7 (though we should probably bump the email package's micro version).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Sun Mar  7 23:46:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Mar 2010 22:46:14 +0000
Subject: [issue8082] Misleading exception when raising an object
In-Reply-To: <1267994925.11.0.0287981779699.issue8082@psf.upfronthosting.co.za>
Message-ID: <1afaf6161003071446h2e2e364cmac908d2eaed52606@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/3/7 Barry A. Warsaw <report at bugs.python.org>:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Minor nit: it's questionable whether this should have gone in between 2.6.5 rc1 and rc2. ?It doesn't seem like a critical fix. ?OTOH, it also seems harmless enough so I'm gonna let it slide.

Thank you. My apologies for forgetting the state of that tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8082>
_______________________________________

From report at bugs.python.org  Mon Mar  8 00:02:41 2010
From: report at bugs.python.org (Ryszard Szopa)
Date: Sun, 07 Mar 2010 23:02:41 +0000
Subject: [issue8038] Not all the new assert* unittest.TestCase methods have
	negative (not) equivalents
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1268002961.89.0.395109157698.issue8038@psf.upfronthosting.co.za>


Ryszard Szopa <ryszard.szopa at gmail.com> added the comment:

Hi,

I am the original reporter of the bug. Please forgive me if this is not the place for discussing the issue. 

I've thought about it, and stuff like assertDictNotEqual or assertSequenceNotEqual aren't really necessary - it is much easier (and shorter) to use assertNotEqual, and there's no need for any special formatting needed to say that something is equal when it shouldn't.

This is not the case for assertNotRegexpMatches, though. assertNot(re.match(...)) tells me only that False is not True. I'd like it to say *how* the text matches the regex (the matching part that is). (Sorry for repeating myself, I try to be clearer this time.)

So, this issue could be renamed to "Implement assertNotRegexpMatches."

----------
nosy: +Ryszard.Szopa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Mon Mar  8 00:15:16 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Mar 2010 23:15:16 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1268003716.64.0.0122038733576.issue8038@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
title: Not all the new assert* unittest.TestCase methods have negative (not) equivalents -> Provide unittest.TestCase.assertNotRegexpMatches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:10:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 00:10:20 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268007020.8.0.826021466374.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think initsite() should be atomic: if any kind of error occurs, Python should print it and exit directly (exit code 1 to notice the error). If initsite() fails, Python is not complelty initialized.

site is responsible to initialiaze a lot of things:

 - Set all module' __file__ attribute to an absolute path
 - Remove duplicate entries from sys.path along with making them absolute
 - Add a per user site-package to sys.path
 - Add site-packages (and possibly site-python) to sys.path
 - Define new built-ins 'quit' and 'exit'.
 - Set 'copyright' and 'credits' in __builtin__"
 - Create builtin help() function
 - On Windows, some default encodings are not provided by Python, while they are always available as "mbcs" in each locale. Make them usable by aliasing to "mbcs" in such a case.
 - import sitecustomize
 - import usercustomize
 - del sys.setdefaultencoding
 - etc.

Be able to ignore the site initializations might be a security vulnerability.

Attached patch consider any exception as fatal: display the error and exit. I moved the call to _PyGILState_Init() before initsite() to avoid a crash in Py_Finalize() => see #8063.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16488/initsite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:10:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 00:10:52 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268007052.35.0.153570041861.issue8063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #3137.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:36:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 00:36:31 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268008591.83.0.861771803844.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using "valgrind --log-file=/tmp/trace ./python" to slow down Python, I found another bug in the interactive interpreter: if you press CTRL+c just after the initialization of the site module the exception will be ignored.

When a signal is catched, it's stored in a table, and the real handler is called later (by Py_MakePendingCalls()). Py_AddPendingCall() is called to ensure that the signal will be handled before the next Python instruction. In my case, the next Python instruction is "decode the string written by the user using the terminal encoding" called by the tokenizer... but the tokenizer ignores all errors (not only unicode errors): see tok_stdin_decode().

Recipe to catch the code responsible to ignore the keyboard interrupt exception (using gdb):
---------------------
$ gdb ./python
(gdb) b initsite
Breakpoint 1, initsite ()
(gdb) run
...
Breakpoint 1, initsite ()
(gdb) next
<execution of the site module>
(gdb) b signal_default_int_handler
Breakpoint 2
(gdb) signal SIGINT
Breakpoint 2, signal_default_int_handler
(gdb) b PyErr_Clear
Breakpoint 3
(gdb) cont
...
Breakpoint 3, PyErr_Clear ()
(gdb) where
<HERE YOU HAVE>
---------------------

Attached patch calls Py_MakePendingCalls() before PyRun_AnyFileExFlags() to avoid the tokenizer bug. It's just a workaround, not a real bugfix.

----------
Added file: http://bugs.python.org/file16489/main_pending_calls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:38:19 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Mar 2010 00:38:19 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268008699.33.0.655971120784.issue8063@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I would keep the call to PyThreadState_Swap() next to PyThreadState_New(): create the thread state and install it. _PyGILState_Init() may come after.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:39:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 00:39:56 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268008796.41.0.692482920259.issue8063@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:40:50 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Mar 2010 00:40:50 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1268008850.02.0.47081324121.issue7449@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did someone notice that on Windows, subprocess imports threading, and use threads for the communicate() method?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:44:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Mar 2010 00:44:10 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268009050.92.0.0522015365011.issue8063@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

haypo, it seems you removed the initial message...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 01:45:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 00:45:46 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268009146.51.0.72046028732.issue8063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> haypo, it seems you removed the initial message...

I know... My mouse clicked on [remove] button, it wasn't me! I don't know how to restore it. The message: msg100432.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:02:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 01:02:28 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268010148.85.0.351918278312.issue8063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I found the following issue in Roundup tracker to restore a deleted message:
http://psf.upfronthosting.co.za/roundup/meta/issue267

I tried to write the URL, but it doesn't work:
http://bugs.python.org/issue8063?@action=edit&@add at messages=100432

I tried also using Poster Firefox extension (to post a POST request, not a GET request), but it doesn't work. My URL should be wrong :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:10:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 01:10:14 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1268010614.72.0.302959765113.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Did someone notice that on Windows, subprocess imports threading, 
> and use threads for the communicate() method?

No, I didn't ran the tests on Windows. I can expect that someone build Python on Linux without threads, but is Python used in embedded systems with Windows but without threads?

Since the patch is already huge, I would suggest to open a new issue (fix tests for Windows without threads).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Mon Mar  8 02:18:41 2010
From: report at bugs.python.org (Pablo Mouzo)
Date: Mon, 08 Mar 2010 01:18:41 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1268011121.59.0.767733257849.issue7300@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


----------
nosy: +pablomouzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Mon Mar  8 03:23:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Mar 2010 02:23:36 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1268015016.13.0.337693459521.issue7143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, patch (with comment tweaks to refer to this issue), and email minor version bump, applied to trunk in r78778.  It turns out that bdecode was already deleted in email 5 in py3k.  I did port the test in r78780.

Thanks Joaquin Cuenca Abela, and you now have the interesting distinction of being the first name listed in Misc/ACKS (because we've been maintaining it in sorted order by last name....)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Mon Mar  8 03:26:12 2010
From: report at bugs.python.org (Joe Amenta)
Date: Mon, 08 Mar 2010 02:26:12 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1268015172.77.0.998176151083.issue7162@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

Yes, the idea was that it doesn't seem outlandish for someone to do:
def file(something):
    do_stuff()

You can use lib2to3.fixer_util.is_probably_builtin for this... modified the patch and attached.

----------
Added file: http://bugs.python.org/file16490/issue7162-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Mon Mar  8 06:29:00 2010
From: report at bugs.python.org (Diego Mascialino)
Date: Mon, 08 Mar 2010 05:29:00 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1268026140.47.0.774697834811.issue8087@psf.upfronthosting.co.za>


Diego Mascialino <dmascialino at gmail.com> added the comment:

Martin, I am not talking about a loop checking source file changes.

I think the check could be done only when the traceback is printed.

The function PyErr_Display() calls PyTracBack_Print() and so on until _Py_DisplaySourceLine() is called. The latter reads the source file and prints the line. I don't know which is the best way to know if the source file was updated. But i think that it's possible to check it there.

I think this could apply only when using the interactive console.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Mon Mar  8 08:03:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Mar 2010 07:03:37 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268031817.37.0.25240411447.issue8067@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r78781 (2.6), r78782 (3.2) and r78783 (3.1)

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Mon Mar  8 08:10:25 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Mar 2010 07:10:25 +0000
Subject: [issue8066] OS X installer: readline module breaks when targeting on
	10.5 or 10.6
In-Reply-To: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>
Message-ID: <1268032225.92.0.168591010375.issue8066@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r78784 (trunk), r78785 (2.6) and r78786 (3.2)

(BTW. I applied the patch to the trunk then used svnmerge to merge the patch into the other branches)

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8066>
_______________________________________

From report at bugs.python.org  Mon Mar  8 09:14:49 2010
From: report at bugs.python.org (Joaquin Cuenca Abela)
Date: Mon, 08 Mar 2010 08:14:49 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline in base64
	encoded payload
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1268036089.04.0.565713741382.issue7143@psf.upfronthosting.co.za>


Joaquin Cuenca Abela <e98cuenc at gmail.com> added the comment:

Thanks David and Barry!

As much as it flatters my ego to be in the first place is MISC/ACK, I have to confess that my family name is "Cuenca Abela", Cuenca is not a middle name.

Cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7143>
_______________________________________

From report at bugs.python.org  Mon Mar  8 09:59:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Mar 2010 08:59:09 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268038749.08.0.996826080144.issue8067@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It looks like the patches were not applied correctly.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Mon Mar  8 10:01:18 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 08 Mar 2010 09:01:18 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268038878.95.0.129268603057.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Antoine, in the same comment, you say that it was not backported to Py2 in order to prevent breaking existing code, and then you ask if it's difficult to support in lxml. ;-)

Supporting the same behaviour in lxml would either mean that it breaks existing code in Py2 (when making the API consistent), or that you can safely (and correctly) write the return value to a file in Py2, but that you can't do the same in Py3 (when adopting the change only in Py3).

Previously, in ElementTree, serialising without an explicit encoding was a way to get a byte encoded serialisation without an XML declaration header, so I expect there to be code that depends on this. Since ElementTree 1.3 uses the same keyword argument as lxml for this feature, I assume that Florent's patches provide at least an alternative here, even if it requires users to adapt their code.

I just wish this backwards incompatible feature had been advertised at the time, or at least *documented* in any way. Even the latest 3.2-dev docs still state that the default encoding of the serialiser is US-ASCII, not a word about *ever* returning a unicode string, especially not by default, and totally not the required big fat warning that writing to a file will fail with mysterious errors if no encoding is specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar  8 10:19:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 09:19:13 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268039953.77.0.386935486295.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With ET 1.3, you should have an explicit keyword argument "xml_declaration":

# ----
        if xml_declaration or (xml_declaration is None and
                               encoding not in ("utf-8", "us-ascii")):
            if method == "xml":
                write("<?xml version='1.0' encoding='%s'?>\n" % encoding)
# ----

In ET 1.2.6, the same snippet looks like:
# ----
        if encoding != "utf-8" and encoding != "us-ascii":
            file.write("<?xml version='1.0' encoding='%s'?>\n" % encoding)
# ----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar  8 12:22:11 2010
From: report at bugs.python.org (=?utf-8?q?P=C3=A1draig_Brady?=)
Date: Mon, 08 Mar 2010 11:22:11 +0000
Subject: [issue1052827] filelist.findall should use os.lstat
Message-ID: <1268047331.91.0.863533834714.issue1052827@psf.upfronthosting.co.za>


P?draig Brady <P at draigBrady.com> added the comment:

Packaging dangling symlinks is often required, so this is a problem.
For e.g. in my package I want to install this symlink:
/etc/apache2/sites-enabled/000-default -> ../sites-available/myapp.conf

----------
nosy: +pixelbeat
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1052827>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:05:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:05:01 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268049901.47.0.153314956098.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyImport_Import() clears errors if a module has no globals, whereas PyEval_GetGlobals() doesn't set any exception on failure. => import_no_global.patch removes this unnecessary PyErr_Clear().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:10:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:10:27 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268050227.77.0.544050997157.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Py_InitializeEx() calls PyErr_Clear() if PyCodec_Encoder() fails without checking for the exception type.

Attached initiliaze_pycodec_error.patch checks for error type: if the error is not an LookupError, display the error and exit (as done for initsite() iny my initsite.patch).

----------
Added file: http://bugs.python.org/file16491/initiliaze_pycodec_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:21:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:21:51 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268050911.3.0.00561379729323.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

tok_stdin_decode() clears error without check for the type. 

tokenizer_error.patch stops the tokenizer with an E_ERROR if the exception is not an UnicodeDecodeError. Fix also err_input() to support E_ERROR: leave the global exception (PyErr_*) unchanged.

----------
Added file: http://bugs.python.org/file16492/tokenizer_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:23:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:23:10 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268050990.88.0.736569651254.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16489/main_pending_calls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:23:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:23:16 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268050996.41.0.674855349614.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Remove main_pending_calls.patch hack: replaced by tokenizer_error.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 13:25:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 12:25:28 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268051128.9.0.124130018298.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file16493/import_no_global.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:00:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 13:00:18 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268053218.12.0.702928817633.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Remove main_pending_calls.patch hack: replaced by tokenizer_error.patch.

With extra tests, I realized that this patchs is still useful to process a SIGINT emitted between Py_Initialize() and PyRun_AnyFileExFlags(). Without the patch, if a SIGINT is emitted just after Py_Initialize(): it's only proceed when the user press enter in the interactive interpreter (when the tokenizer decodes the input string to the terminal charset).

----------
Added file: http://bugs.python.org/file16494/main_pending_calls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 14:46:44 2010
From: report at bugs.python.org (Allison Vollmann)
Date: Mon, 08 Mar 2010 13:46:44 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1268056004.98.0.939875831084.issue8050@psf.upfronthosting.co.za>


Allison Vollmann <allisonvoll at gmail.com> added the comment:

i believe which the parameter "msg" must be referenced as a string type when called "sendmail" nor as an MIME[Message, Multipart, Text, Base, Audio] 

and this is obvious way to do it. but i'm not Dutch :-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8050>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:11:34 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 08 Mar 2010 14:11:34 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1268057494.32.0.481232329062.issue1530559@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer 
> on top of the C layer.  Partly I'm worried about accidentally breaking 
> something (it's not 100% clear to me whether there might be hidden 
> side-effects to such a change),

I understand.  I am worried about that as well. The main area that 
concerns me is the interface for the 'Struct' class.  I did my best to 
match the methods and functions from the C implementation.  I need to 
look into this in more detail, though.  One quirk I currently know 
about is that the following methods:

   '__delattr__', '__getattribute__', '__setattr__', '__new__'

show up in 'help' for the C implementation, but not the Python one.  
Although, the implementations do exist in both places. 

> but I also notice that this seems to have a significant impact on performance.
> In fact, I seem to recall that the previously existing Python component of 
> the struct module was absorbed into Modules/_struct.c precisely for 
> performance reasons.
>
> A quick, unscientific benchmark:  the time taken to run test_struct with this
> patch (excluding the changes to test_struct itself) on my machine (OS X 10.6,
> 64-bit non-framework non-debug build of Python) is around 1.52--1.53 seconds; > without the patch it's around 1.02--1.03 seconds.

Agreed that this is not a really scientific benchmark.  I did 
experiment with this idea a little further though on my machine (OS X 
10.5 32-bit):

==============================================
| Configuration                    | Seconds |
==============================================
| Original                         | 1.26    |
----------------------------------------------
| __index__ patch v1               | 1.88    |
----------------------------------------------
| Hoisted imports out of functions | 1.53    |
----------------------------------------------
| Hoisted imports and no __index__ | 1.34    |
----------------------------------------------

So with this simple experiment pulling the 'imports' out of the function
wrappers made quite a difference.  And, of course, removing the 
'__index__' transform brought the times down even more.  So, the 
wrapper overhead does not look to be terrible for this simple test.

However, as you alluded to, we should find a better benchmark.  Any 
ideas on a good one?
 
> (4) For 2.x, perhaps we don't need the extra __index__ functionality anyway, 
> now that the previous use of __int__ has been restored.  That would give us 
> a bit more time to think about this for 3.x.

Agreed.  Thanks for taking the time to look at the patch anyway!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:19:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 14:19:00 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268057940.33.0.576277921788.issue1731717@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Previous buildbot failures were in test_multiprocessing:
http://bugs.python.org/issue1731717#msg100430

Now it should be fixed:
 - r78777, r78787, r78790 on 2.x
 - r78798 on 3.x

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:20:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 14:20:57 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1268058057.53.0.547304346811.issue7805@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This last bug is fixed, too.
http://bugs.python.org/issue1731717#msg100643

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:26:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 14:26:08 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1268058368.53.0.937595535095.issue2777@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

All this flakiness is fixed:
 - r78736, r78759, r78761, r78767, r78788, r78789 on 2.x
 - r78797 on 3.x


Note: because of #3137, the send_signal(SIGINT) is retried 2 times on some platforms.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2777>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:30:51 2010
From: report at bugs.python.org (Yonas)
Date: Mon, 08 Mar 2010 14:30:51 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268058651.72.0.278513223051.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Florent,

Have you tested any of the sample test programs mentioned in this bug report? For example, the one by Joel Martin (kanaka).

I'd suggest to test those first before marking this issue as fixed.

- Yonas

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:52:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 14:52:39 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268059959.05.0.204867433295.issue1731717@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

>>> import subprocess, signal
>>> signal.signal(signal.SIGCLD, signal.SIG_IGN)
0
>>> subprocess.Popen(['echo','foo']).wait()
foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./Lib/subprocess.py", line 1229, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "./Lib/subprocess.py", line 482, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes


You're right, I fixed something giving the same ECHILD error in multiprocessing. But it was not related.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 15:53:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 14:53:34 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268060014.71.0.580249637447.issue1731717@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords:  -buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:02:35 2010
From: report at bugs.python.org (Yonas)
Date: Mon, 08 Mar 2010 15:02:35 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268060555.9.0.970865521333.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/9a853d0308c8e55a


"I'm also glad to see a test case that causes exactly the same error with or without the presence of a ?daemon.DaemonContext?.

Further research shows that handling of ?SIGCLD? (or ?SIGCLD?) is fairly
OS-specific, with ?ignore it? or ?handle it specifically? being correct
on different systems. I think Python's default handling of this signal
is already good (modulo bug #1731717 to be addressed in ?subprocess?).

So I will apply a change similar to Joel Martin's suggestion, to default
to avoid touching the ?SIGCLD? signal at all, and with extra notes in
the documentation that anyone using child processes needs to be wary of
signal handling.

This causes the above test case to succeed; the output file contains:: 
=====
Child process via os.system.
Child process via 'subprocess.Popen'.
Parent daemon process.
Parent daemon process done.
====="

  -- By Ben Finney

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:05:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Mar 2010 15:05:49 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1268038878.95.0.129268603057.issue8047@psf.upfronthosting.co.za>
Message-ID: <20100308100535.26ef1993@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Mon, 08 Mar 2010 09:01:19 +0000,
Stefan Behnel <report at bugs.python.org> a ?crit :
> 
> Antoine, in the same comment, you say that it was not backported to
> Py2 in order to prevent breaking existing code, and then you ask if
> it's difficult to support in lxml. ;-)

I meant breaking existing *user* code. Besides, the fact that
compatibility is broken doesn't mean third-party code difficult to fix;
hence my question.

> Supporting the same behaviour in lxml would either mean that it
> breaks existing code in Py2 (when making the API consistent), or that
> you can safely (and correctly) write the return value to a file in
> Py2, but that you can't do the same in Py3 (when adopting the change
> only in Py3).

Sorry, I don't understand this. Are you saying it's impossible
for you to define two different behaviours based on the current Python
version? What's bad with
"""if sys.version_info() >= (3, 0, 0): # blah"""

> Previously, in ElementTree, serialising without an explicit encoding
> was a way to get a byte encoded serialisation without an XML
> declaration header, so I expect there to be code that depends on
> this.

This doesn't seem to be documented. The doc simply says
"""encoding is the output encoding (default is US-ASCII)""".

In other words, undocumented (and untested) behaviour has been "broken"
when porting to 3.0, which is the version which deliberately broke
compatibility for documented things. I guess we can live with it ;)

> Even the latest
> 3.2-dev docs still state that the default encoding of the serialiser
> is US-ASCII, not a word about *ever* returning a unicode string,
> especially not by default, and totally not the required big fat
> warning that writing to a file will fail with mysterious errors if no
> encoding is specified.

Ok, perhaps some documentation changes are in order :-)
(I wonder why the default was US-ASCII, though. Sounds a bit braindead)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:06:27 2010
From: report at bugs.python.org (Yonas)
Date: Mon, 08 Mar 2010 15:06:27 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268060787.72.0.467267937865.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Ben Finney's comment suggests to me that this bug is being ignored. Am I wrong?

"with extra notes in the documentation that anyone using child processes needs to be wary of signal handling."

Why should they be wary? We should just fix this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:07:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Mar 2010 15:07:44 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268060864.3.0.565531430628.issue8047@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:08:06 2010
From: report at bugs.python.org (Yonas)
Date: Mon, 08 Mar 2010 15:08:06 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268060886.56.0.409184859098.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

By the way, in three months from today, this bug will be 3 years old.....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:35:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 15:35:45 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class instances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1268062545.95.0.764624426315.issue7624@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in r78800.
Additional tests backported to 3.x.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
title: isinstance(... ,collections.Callable) fails with oldstyle class i nstances -> isinstance(... ,collections.Callable) fails with oldstyle class instances

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Mon Mar  8 16:48:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Mar 2010 15:48:40 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1268063320.06.0.0293354945976.issue8050@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On the other hand, having a facility somewhere in the stdlib to pass a Message object to SMTP sendmail would be handy.  I've made a note of this in my working notes for email6 to see if there's something we want to do about it.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8050>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:36:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Mar 2010 16:36:41 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

assertSameElements fails with sequences that contain unorderable types such as [2j, 5j, set(), frozenset()].

See also msg98744 in #7837.

----------
assignee: flox
messages: 100654
nosy: ezio.melotti, flox, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: assertSameElements fails with sequences that contain unorderable types
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:37:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Mar 2010 16:37:35 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066255.07.0.447962979288.issue8088@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib)
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:38:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 16:38:39 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066319.06.0.776974207056.issue8088@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +patch
resolution:  -> accepted
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16495/issue8088_unordered_elements.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:39:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 16:39:12 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066352.79.0.113253956352.issue8088@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch against trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:39:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Mar 2010 16:39:26 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066366.41.0.831168545809.issue8088@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 17:40:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Mar 2010 16:40:59 +0000
Subject: [issue7837] assertSameElements doesn't filter enough py3k warnings
In-Reply-To: <1265106776.19.0.232903733304.issue7837@psf.upfronthosting.co.za>
Message-ID: <1268066459.04.0.0335625690286.issue7837@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78757 (trunk). I opened #8088 for the unorderable types problem.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7837>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:12:53 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Mar 2010 17:12:53 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268068373.02.0.841571747297.issue1731717@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I really don't care about the age of a bug.  This bug is young.  I've fixed many bugs over twice its age in the past.

Regardless, I've got some serious subprocess internal refactoring changes coming in the very near future to explicitly deal with thread safety issues.  I'm adding this one to my list of things to tackle.

----------
assignee: astrand -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 18:46:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 17:46:37 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1268070397.95.0.902213125109.issue7723@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

So we keep buffer() as the standard way to create BLOBs for 2.x?

It is the only use of "py3k deprecated" buffer() which cannot be replaced in 2.x.

Set to "release blocker" until a decision is made.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:03:19 2010
From: report at bugs.python.org (Yonas)
Date: Mon, 08 Mar 2010 18:03:19 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1268071399.94.0.150373512416.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Gregory,

Awesome! Approx. how long until we hear back from you in this report?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:18:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 18:18:35 +0000
Subject: [issue1530559] struct.pack raises TypeError where it used to convert
Message-ID: <1268072315.27.0.461255640052.issue1530559@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I would suggest to raise a py3k warning instead of a plain warning.
AFAIU the implicit conversion is OK in 2.7, and it is removed in 3.x.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1530559>
_______________________________________

From report at bugs.python.org  Mon Mar  8 19:22:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Mar 2010 18:22:42 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268072562.18.0.791568204444.issue8067@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

2.6 should be fixed in r78805.  I won't have time to merge the fix into the other branches until at best later tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:20:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 08 Mar 2010 20:20:26 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1268079626.51.0.640370335465.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Martin: thanks for reviewing this.

Re msg100537: sorry about the inauspicious start.  I've added some bulletproofing for the case you discovered, and added two new unit tests.

Re msg100538: OK.  I've removed my name and the copyright notice in all places apart from the Misc/ACKS file.  There are still some comments in the code where I use the first person singular.

I'm attaching an updated patch against trunk

----------
Added file: http://bugs.python.org/file16496/add-gdb7-python-hooks-to-trunk-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:20:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Mar 2010 20:20:44 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

2.6.5 release blocker
3.1.2 release blocker

For 10.6, new universal build options were added to reflect the dropping of support in 10.6 for the ppc64 arch.  The new options:

  --universal-archs=3-way -> -arch {i386,x86_64,ppc)
  --universal-archs=intel -> -arch {i386,x86_64}

however do not add the executables and symlinks to select a "-32" or
"-64" variant like the existing "--universal-archs=all" does and so
these new build variants always run in 64-bit with no way to override
it. A simple test in configure.in needs to be changed to recognize
these new options.

Trunk (2.7) and py3k (3.2) use a new execution-time mechanism to select 32- vs 64-bit execution and so do not exhibit this problem.

(Ronald and I agree this should be a release-blocker. Patch to follow.)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100663
nosy: barry, benjamin.peterson, ned.deily, ronaldoussoren
severity: normal
status: open
title: 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:23:02 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 08 Mar 2010 20:23:02 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1268079782.63.0.43348596965.issue8032@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file16497/diff-of-gdb7-hooks-v2-relative-to-v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Mon Mar  8 21:53:50 2010
From: report at bugs.python.org (Ryszard Szopa)
Date: Mon, 08 Mar 2010 20:53:50 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1268081630.62.0.815395897195.issue8038@psf.upfronthosting.co.za>


Ryszard Szopa <ryszard.szopa at gmail.com> added the comment:

Here's the patch against unittest2 that implements assertNotRegexpMatches.

----------
keywords: +patch
Added file: http://bugs.python.org/file16498/assertNotRegexpMatches.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:10:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 21:10:23 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268082623.13.0.63021710129.issue8089@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:11:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 21:11:46 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <20100308161142.215c1f32@heresy.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 08, 2010, at 08:20 PM, Ned Deily wrote:

>(Ronald and I agree this should be a release-blocker. Patch to follow.)

BTW, the right thing to do in this case (for 2.6 anyway) is to set the issue
to be a release blocker, so it gets my attention.  I can always knock it down
if I don't agree.

In this case I do, so I've set the priority for you.  Please try to fix this
asap so we can get rc2 out.

-Barry

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:18:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 21:18:33 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268083113.95.0.00599312896165.issue8088@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It could be fixed as part of #7832.

----------
superseder:  -> assertSameElements([0, 1, 1], [0, 0, 1]) does not fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:18:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 21:18:48 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268083128.29.0.194537927283.issue8088@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:19:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 21:19:44 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268083184.85.0.82825936621.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

SIGINT.patch is the sum of all patches, it should be easier to review it.

----------
Added file: http://bugs.python.org/file16499/SIGINT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:21:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 21:21:15 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744328.52.0.261311702115.issue8063@psf.upfronthosting.co.za>
Message-ID: <1268083275.56.0.59919828119.issue8063@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My SIGINT.patch for #3137 moves the call to _PyGILState_Init() just before initsite(), so it doesn't change too much Py_InitializeEx() and it's enough for me :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:44:38 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 08 Mar 2010 21:44:38 +0000
Subject: [issue5228] multiprocessing not compatible with functools.partial
In-Reply-To: <1234448790.05.0.305625917638.issue5228@psf.upfronthosting.co.za>
Message-ID: <1268084678.5.0.632818856072.issue5228@psf.upfronthosting.co.za>


joseph.h.garvin <joseph.h.garvin at gmail.com> added the comment:

I think this bug still exists in Python 2.6.4, and I haven't tested 2.6.5, but since 2.6.4 was released 6 months after this bug was closed I assume it's still an issue. Running ndbecker's test program as is produces the following output on Solaris 10:

Process PoolWorker-1:
Process PoolWorker-2:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 232, in _bootstrap
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-3:
Traceback (most recent call last):
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 232, in _bootstrap
    self.run()
    self.run()
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 88, in run
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/pool.py", line 57, in worker
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/pool.py", line 57, in worker
    self.run()
    task = get()
    task = get()
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/queues.py", line 352, in get
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/process.py", line 88, in run
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/queues.py", line 352, in get
    self._target(*self._args, **self._kwargs)
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/pool.py", line 57, in worker
    return recv()
    return recv()
TypeError: type 'partial' takes at least one argument
TypeError: type 'partial' takes at least one argument
    task = get()
  File "/opt/app/g++lib6/python-2.6/lib/python2.6/multiprocessing/queues.py", line 352, in get
    return recv()
TypeError: type 'partial' takes at least one argument

----------
nosy: +joseph.h.garvin
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5228>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:46:47 2010
From: report at bugs.python.org (Sjoerd Mullender)
Date: Mon, 08 Mar 2010 21:46:47 +0000
Subject: [issue7966] mhlib does not emit deprecation warning
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1268084807.74.0.4764340389.issue7966@psf.upfronthosting.co.za>


Sjoerd Mullender <sjoerd at acm.org> added the comment:

mhlib is not officially deprecated, if I may believe PEP 4.
Therefore I do not agree with the change that was made to this bug report.
As far as I am concerned, the bug remains that mhlib uses a deprecated module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:51:36 2010
From: report at bugs.python.org (Sjoerd Mullender)
Date: Mon, 08 Mar 2010 21:51:36 +0000
Subject: [issue8090] PEP 4 should say something about the standard library
In-Reply-To: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>
Message-ID: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>


New submission from Sjoerd Mullender <sjoerd at acm.org>:

When a module or feature is deprecated, all uses of the deprecated module/feature should be removed from the non-deprecated part of the distribution (and, I would argue, also from the other deprecated modules).
I think PEP 4 should say something to this effect.

I suggest adding a sentence to the section "Procedure for declaring a module deprecated", something like:  "The proposal MUST include patches to remove any use of the deprecated module from the standard library."

----------
assignee: georg.brandl
components: Documentation
messages: 100671
nosy: georg.brandl, sjoerd
severity: normal
status: open
title: PEP 4 should say something about the standard library

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8090>
_______________________________________

From report at bugs.python.org  Mon Mar  8 22:56:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Mar 2010 21:56:09 +0000
Subject: [issue8090] PEP 4 should say something about the standard library
In-Reply-To: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>
Message-ID: <1268085369.91.0.615729431945.issue8090@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't really think this is a documentation bug, more of an issue you have with the policy, in which case this is better being discussed on python-dev.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8090>
_______________________________________

From report at bugs.python.org  Mon Mar  8 23:04:34 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 22:04:34 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1268085874.86.0.32772058336.issue7804@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I see this in 2.6 also, Ubuntu 9.10 and 10.04 (alpha).  Marking this a release blocker for now, though I'll check to see if it's a regression or not.

----------
nosy: +barry
priority: normal -> release blocker
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Mon Mar  8 23:08:16 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 22:08:16 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

'make test' on Ubuntu 10.04 alpha produces:

328 tests OK.
1 test failed:
    test_readline
37 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gl test_imageop test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_normalization
    test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
    test_smtpnet test_socketserver test_startfile test_sunaudiodev
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_zipfile64
1 skip unexpected on linux2:
    test_bsddb
Exception TypeError: TypeError("'NoneType' object is not callable",) in <bound method Popen.__del__ of <subprocess.Popen object at 0x5d63650>> ignored
make: *** [test] Error 1

The readline failure is reported elsewhere.  It's the TypeError at the end that's the problem here.  I think this does not happen on Ubuntu 9.10.

----------
messages: 100674
nosy: barry
priority: release blocker
severity: normal
status: open
title: TypeError at the end of 'make test'
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Mon Mar  8 23:24:11 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Mon, 08 Mar 2010 22:24:11 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1268087051.04.0.22844845015.issue8065@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


----------
nosy: +zvezdan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Mon Mar  8 23:44:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 22:44:02 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268088242.16.0.55278512312.issue8091@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

<flox> barry, Taggnostr: all the tests using subprocess  [17:42]
<flox> "test_bz2 test_cmd_line test_platform test_popen2 test_popen test_pydoc
       test_quopri test_signal test_subprocess test_sys test_threading
       test_unicodedata test_winsound"
<flox> you may test with this list as parameter, then shorten the list to find
       the culprit  [17:43]
<flox> (if it is repeatable)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Mon Mar  8 23:45:07 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 22:45:07 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268088307.32.0.0942267385559.issue8091@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Does not error on Ubuntu 9.10 as far as I can tell.  Seems to be only 10.04 (alpha) for some reason.  I've only tested on 64 bit.

This is probably not a release blocker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:11:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 23:11:45 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268089905.67.0.160002103223.issue7832@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16087/issue7832_assertItemsEqual.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:14:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Mar 2010 23:14:30 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268090070.66.0.0304352108748.issue7832@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch with documentation, tests, Misc/NEWS, following a discussion with Michael, Ezio and JP.

----------
priority: low -> normal
Added file: http://bugs.python.org/file16500/issue7832_assertSameElements_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:21:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:21:07 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

utf8 encoder doesn't work in backslashreplace error handler:

>>> "\uDC80".encode("utf8", "backslashreplace")
TypeError: error handler should have returned bytes

----------
components: Unicode
messages: 100678
nosy: haypo
severity: normal
status: open
title: utf8, backslashreplace and surrogates
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:21:31 2010
From: report at bugs.python.org (paul stadfeld)
Date: Mon, 08 Mar 2010 23:21:31 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>


New submission from paul stadfeld <mensanator at aol.com>:

So I started 3.1.2...

Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 

And monitored Windows Task Manager (XP):

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    11,120 K
pythonw.exe   paul_stadfeld   00    16,816 K

I assume this is normal.

I deliberately do something stupid:

>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b

Ok, that will run for a while, long enough for me to watch the Task Manager:

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld  ~55   ~30,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,828 K

So I do [Restart Shell] from IDLE's [Shell] menu:

>>> ================================ RESTART ================================

And try it again.

>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b

But now it's different:

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    13,716
pythonw.exe   paul_stadfeld  ~50   ~30,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~48   ~45,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,892 K

Looks like the previous process was never stopped.

Trying to Restart Shell again and running same creates a 5th instance
of pythonw.exe.

>>> ================================ RESTART ================================
>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b


Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    13,716
pythonw.exe   paul_stadfeld  ~50   ~54,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~25   ~42,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~25   ~54,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,892 K


Only this time I got an error trying to re-start.

    IDLE's subprocess didn't make connection. Either IDLE can't start a 
    subprocess or personal firewall software is blocking the connection

Now I'm stuck, so I close the "Python Shell" window.

But closing the window only stopped one of the pythonw.exe instances.
The three active processes are still running full tilt (the one quiescent
process remains quiescent.)

This appears to be a process leak in addition to it being a memory leak.

Also, had one of the processes that won't stop opened a script from a USB
port, then Windows would refuse to eject the USB drive as it correctly 
thinks some process is still using it. Of course, since the application 
is closed, there's not suppoed to be any such process, so it's
not obvious where the problem is unless you look at the process table
in Windows Task Manager and manually halt all the renegade pythonw.exe
processes that are still running. At which point Windows will allow the 
USB to be ejected.

----------
components: IDLE
messages: 100679
nosy: mensanator
severity: normal
status: open
title: IDLE processes don't close
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:23:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:23:14 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1268090594.24.0.114442569244.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8092.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:23:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:23:26 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268090606.2.0.510950297743.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #6697.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:31 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090971.88.0.397043225824.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As requested by Guido, here is a new patch including the fix for the site module: catch errors in execsitecustomize() and execusercustomize().

----------
Added file: http://bugs.python.org/file16501/SIGINT-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:38 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090978.5.0.126175961787.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16488/initsite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:41 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090981.74.0.965084065292.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16491/initiliaze_pycodec_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:45 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090985.28.0.12003397408.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16492/tokenizer_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:49 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090989.84.0.992885771853.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16493/import_no_global.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:53 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090993.28.0.0273489932316.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16494/main_pending_calls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:29:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:29:57 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268090997.55.0.899366375262.issue3137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16499/SIGINT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:36:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:36:46 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1268091406.19.0.416104672075.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

unicode_fromformat_U.patch: replace PyUnicode_FromFormat("..%s...", ..., _PyUnicode_AsString(obj)) by PyUnicode_FromFormat("...%U...", ..., obj). It replaces also "%.200s" by "%U", so the output is no more truncated.

----------
Added file: http://bugs.python.org/file16502/unicode_fromformat_U.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Mar  9 00:53:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Mar 2010 23:53:30 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1268092410.83.0.548723775923.issue8093@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:20:16 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Tue, 09 Mar 2010 00:20:16 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268094016.04.0.25929367655.issue6538@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Hey Ryan,

I took a look at the diff you attached here. It looks like you did 

There are some whitespace-only changes -- for example, you remove and then re-insert the line beginning with "The name of the last matched capturing group".

Can you re-submit your most recent patch without the unneeded whitespace-only changes?

There's a light at the end of the tunnel!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:35:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Mar 2010 00:35:30 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268094930.06.0.0569409620633.issue7832@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

To summarize, the possible behaviors are:
1) check  order, check  duplicates (i.e. assertSequenceEqual);
2) check  order, ignore duplicates (probably useless);
3) ignore order, check  duplicates (useful but missing);
4) ignore order, ignore duplicates (i.e. assertSameElements now);

The possible solutions are:
a) change assertSameElements to match behavior 3 (see Florent patch):
   pros: implements 3 (i.e. the expected behavior); 4 can be replaced easily *; shorter function call for common use;
   cons: breaks compatibility; the name is still kind of confusing;
b) add check_order to assertSequenceEqual, leave assertSameElements unchanged:
   pros: covers 1, 3 and 4; backward compatible;
   cons: assertSameElements is still confusing;
c) add check_order to assertSequenceEqual, deprecate and then remove assertSameElements:
   pros: covers 1 and 3; removes a confusing function; 4 can be replaced easily *;
   cons: deprecates a quite new function;
d) add check_duplicates to assertSameElements:
   pros: covers 1, 3 and 4; backward compatible (with default == False);
   cons: assertSameElements would be even more confusing;

* assertSameElements can be replaced by assert[Set]Equal(set(a), set(b)), but this doesn't work with unhashable elements (they worked with assertSameElements).

I like c) because it removes a confusing function, and simplifies the API of unittest that IMHO it's already growing too complex (even if it would be handy to have a function that does 3 directly without having to write check_order=False).

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 01:45:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Mar 2010 00:45:31 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1268095531.44.0.319382460583.issue4180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It sounds like it would be cleaner to apply Brett's idea in msg75122, rather than have the user override (and alternate implementations implement) another obscure hook. We have enough hooks that nobody knows about, IMHO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:12:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2010 01:12:00 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268097120.16.0.950101613769.issue8092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a regression introduced by r72208 to fix the issue #3672.

Attached patch fixes PyUnicode_EncodeUTF8() if unicode_encode_call_errorhandler() returns an unicode string (eg. backslackreplace error handler). I don't know unicodeobject.c code (very well), and my patch should be far from being perfect.

I suppose that the maximum length of an escaped characters is 8 bytes (xmlcharrefreplace error error for U+DFFFF). When the first lone surrogate is found, reallocate the buffer to size*8 bytes. The escaped character have to be an ASCII character or an UnicodeEncodeError is raised.

Note: unicode_encode_ucs1() doesn't have hardcoded for the maximum length ot escaped string. Its code might be reused in PyUnicode_EncodeUTF8() to remove the hardcoded limits.

----------
keywords: +patch
Added file: http://bugs.python.org/file16503/utf8_surrogate_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:16:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Mar 2010 01:16:24 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268097384.26.0.018990719241.issue6538@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I've reviewed the patch and do not see any unnecessary whitespace changes in his patch.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:37:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Mar 2010 01:37:20 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268098640.83.0.0414489207717.issue8092@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg, loewis
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:39:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Mar 2010 01:39:29 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268098769.9.0.0637011991072.issue8091@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably a duplicate of issue5099.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:41:19 2010
From: report at bugs.python.org (Ryan Arana)
Date: Tue, 09 Mar 2010 01:41:19 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268098879.67.0.729363260371.issue6538@psf.upfronthosting.co.za>


Changes by Ryan Arana <ryan.arana at gmail.com>:


Removed file: http://bugs.python.org/file16274/MatchObjectLinksFix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:44:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Mar 2010 01:44:07 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1268099047.54.0.451287082268.issue5099@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, stderr will contain "[XXX refs]" as the last line with Python compiled in debug mode. The remove_stderr_debug_decorations() function will help you ignore this line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:44:36 2010
From: report at bugs.python.org (Ryan Arana)
Date: Tue, 09 Mar 2010 01:44:36 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268099076.68.0.837926756436.issue6538@psf.upfronthosting.co.za>


Ryan Arana <ryan.arana at gmail.com> added the comment:

I tried to format the methods of the class(es) as they are formatted in other files, which is why I added the whitespace. 

I can go back and remove that if that's what would be preferred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 02:46:46 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 09 Mar 2010 01:46:46 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268099206.6.0.414752032989.issue7832@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Looking through the thousands of uses of assertSameElements in our internal code base at work I see many uses of it that are likely not hashable items in the sequences being compared.

The largest use of course is with lists and tuples of hashables where another assert method may have even made more sense, but that is not the only use.

As documented in Python 3.1 I think the behavior of assertSameElements is accurate and makes sense.  We should add an extra note to the documentation to explicitly mention that it does not care how many of a given element occur in either sequence.  [0, 1, 1] and [0, 0, 1] do in fact have the same elements.

If you want a different behavior please add that as a feature.  As such, Ezio's option (b) and (d) are the only ones I'm in favor of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:07:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:07:22 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268100442.22.0.187130472113.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patches fix the problem for 2.6 and 3.1:
1. configure(.in) is changed to invoke the existing "4way" build targets for --with-universal-archs values of 3-way and intel as well as all.
2. configure(.in) passes the necessary lipo -extract arch values into the Mac/Makefile for building Python-32 and Python-64.  (Note, the solution here is simpler than what was required for trunk and py3k because the use of lipo is isolated to the "4way" build targets which can only be used for universal builds on 10.5+.)
3. a typo in the 2.6 Mac/README file is corrected and the previous updates are copied over from 2.6 to the 3.1 Mac/README.

Since configure.in is updated, it is necessary to run autoconf on both 2.6 and 3.1 after applying these patches.

----------
Added file: http://bugs.python.org/file16504/issue-sl-configure-32-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:07:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:07:36 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268100457.0.0.133076706635.issue8089@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file16505/issue-sl-configure-32-31.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:22:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Mar 2010 02:22:09 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268101329.03.0.627978341816.issue6538@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:27:28 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 02:27:28 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268101648.36.0.91050262242.issue8091@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not a release blocker.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:32:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 02:32:46 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268101966.42.0.641683567476.issue8067@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It sounds like this is fixed for 2.6.5 now.  I'm bumping the priority down and removing 2.6 from the Versions.

----------
priority: release blocker -> high
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:35:24 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:35:24 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268102124.77.0.677087967636.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Correct inadvertent deletion in the 3.1 Mac/README.

----------
Added file: http://bugs.python.org/file16506/issue-sl-configure-32-31-rev1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:35:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:35:33 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268102133.49.0.748904902297.issue8089@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file16505/issue-sl-configure-32-31.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:44:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 02:44:14 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1268102654.24.0.415947438758.issue7804@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:55:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:55:10 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1268103310.56.0.233789615734.issue6877@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also note that this feature has not been backported to 3.1 which means it will not be in the upcoming 3.1.2 release.  (It will not be an issue for the python.org 3.1.2 installer which will be built with GNU readline as usual to support older systems.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________

From report at bugs.python.org  Tue Mar  9 03:58:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 02:58:38 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268103518.6.0.9173552654.issue8067@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fix verified for 2.6.
It should still be considered a release blocker for 3.1.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 04:57:21 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Mar 2010 03:57:21 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268107041.47.0.641314292793.issue8067@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 06:48:08 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 09 Mar 2010 05:48:08 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1268113688.52.0.97184235011.issue8036@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

In case it matters, 3.0.1 does NOT crash.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:28:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 06:28:05 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268116085.66.0.926907932927.issue7832@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Gregory P. Smith wrote:
> Looking through the thousands of uses of assertSameElements in our internal
> code base at work I see many uses of it that are likely not hashable items
> in the sequences being compared.

The method assertSameElements will still support unhashable elements.
In this case the fixed behaviour will be harmless for your code base,
like for many other users. Example with unhashable entries:

    assertSameElements(list([3], [None], [3]), tuple([None], [3], [3]))
    ==> pass

    assertSameElements(list([3], [None], [3]), tuple([None], [None], [3]))
    ==> fails

The patch only fix the 2nd case here. Before the patch it didn't fail on
this case.


I still don't see real cases where we need that [0, 0, 1] and [0, 1, 1]
compare equal.

And this enhancement will be less surprising for the user.

Currently, if someone uses "assertSameElements" it could expect that it
fails when the count of elements is not the same. And it will never notice
that he's wrong and that his unittest have a flaw.
In a sense, it is not helpful for the end user to preserve the current
behaviour. There's a risk that tests will not fail when they should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:39:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 06:39:02 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268116742.25.0.198756979256.issue7832@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 07:42:21 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 06:42:21 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268116941.2.0.635311479194.issue8067@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

3.2 and 3.1 should now also be fixed (in r78808 and r78809)

Please test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:01:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 07:01:40 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268118100.94.0.00618513411959.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16075/issue7092_py3k_warnings_args_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:01:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 07:01:45 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268118105.23.0.908674693896.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16076/issue7092_py3k_warnings_noargs_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:01:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 07:01:51 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268118111.04.0.886339110274.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16113/issue7092_test_support_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:08:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 07:08:31 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268118511.38.0.596821614374.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Silence the last warnings, using check_py3k_warnings.

But we could provide a smaller patch, if #7832 is fixed before.

----------
dependencies: +assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
Added file: http://bugs.python.org/file16507/issue7092_without_7832.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:18:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 07:18:13 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1268119093.56.0.791670611394.issue7832@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Some real use case for the fixed behavior:
 - the patch for #7092 has a workaround to fix the comparison locally,
   both in test_decimal and test_set
 - test_cgi was changed, before noticing that SameElements has a flaw:
http://svn.python.org/view/python/trunk/Lib/test/test_cgi.py?r1=77871&r2=77870


But there's many snippets in the test suite which look like:

  expected.sort()
  actual.sort()
  self.assertEqual(expected, actual)

Since sorting heterogeneous sequence is no longer supported in 3.x, it is painful to workaround this in each test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:35:39 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 09 Mar 2010 07:35:39 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1268120139.91.0.593316011845.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Wrapping select in (taken from twisted sources) can help:
def untilConcludes(f, *a, **kw):
    while True:
        try:
            return f(*a, **kw)
        except (IOError, OSError), e:
            if e.args[0] == errno.EINTR:
                continue
            raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Tue Mar  9 08:49:23 2010
From: report at bugs.python.org (Sjoerd Mullender)
Date: Tue, 09 Mar 2010 07:49:23 +0000
Subject: [issue8090] PEP 4 should say something about the standard library
In-Reply-To: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>
Message-ID: <1268120963.44.0.0518077012316.issue8090@psf.upfronthosting.co.za>


Sjoerd Mullender <sjoerd at acm.org> added the comment:

It was discussed on python-dev.  It was suggested to submit a bug report on PEP 4.  See http://mail.python.org/pipermail/python-dev/2010-February/097772.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8090>
_______________________________________

From report at bugs.python.org  Tue Mar  9 09:42:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 08:42:47 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268124167.06.0.267449647305.issue8067@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fix verified for 3.1 and py3k(3.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:00:50 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 09:00:50 +0000
Subject: [issue8067] OS X Installer: build errors on 10.6 when targeting 10.4
	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1268125250.49.0.371904425642.issue8067@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8067>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:01:54 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Tue, 09 Mar 2010 09:01:54 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

The following code results in an infinite loop -->

# ----
import multiprocessing

def f(m):
	print(m)

p = multiprocessing.Process(target=f, args=('pouet',))
p.start()
# ----

I've firstly think about an issue in my code when Python loads this module so I've added a "if __name__ == '__main__':" and it works well. But, with the following code Python enters in the same infinite loop -->

proc.py:

# ----
import multiprocessing

def f(m):
	print(m)

class P:
	def __init__(self, msg):
		self.msg = msg
	
	def start(self):
		p = multiprocessing.Process(target=f, args=(self.msg,))
		p.start()
# ----

my_script.py:
# ----
from proc import P

p = P("pouet")
p.start()
# ----

It's like Python loads all parent's process memory space before starting process which issues in an infinite call to Process.start() ...

----------
components: Library (Lib)
messages: 100707
nosy: Kain94
severity: normal
status: open
title: Multiprocessing infinite loop
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:53:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 09:53:40 +0000
Subject: [issue8095] test_urllib2 crashes on OS X 10.3 attempting to retrieve
	network proxy configuration
In-Reply-To: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>
Message-ID: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The current mechanism for urllib and urllib2 on OS X to retrieve network proxy information is to call _scproxy.c to query the OS X SystemConfiguration Framework.  _scproxy.c uses a schema key, kSCPropNetProxiesExcludeSimpleHostnames, that was introduced in OS X 10.4.  Building on 10.3 results in a compile error.  Current python.org OS X installers are built using the 10.4u SDK with a deployment target of 10.3 to allow running on OS X 10.3.9.  When such pythons are installed on 10.3, attempts to use proxy support, such as is tested in test_urllib2, result in a crash:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   _scproxy.so       	0x000a77ac get_proxy_settings + 0x6c

Whether this is worth fixing is debatable, considering that 10.3 has not been supported by Apple for many years and that the use of network proxy  servers has likely been declining.  At a minimum, it would be better for it to fail without a crash but perhaps a README item would suffice.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100708
nosy: ned.deily, orsenthil, ronaldoussoren
severity: normal
status: open
title: test_urllib2 crashes on OS X 10.3 attempting to retrieve network proxy configuration
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Tue Mar  9 10:58:35 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 09:58:35 +0000
Subject: [issue8095] test_urllib2 crashes on OS X 10.3 attempting to retrieve
	network proxy configuration
In-Reply-To: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>
Message-ID: <1268128715.01.0.447094495362.issue8095@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file16508/Python.crash.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:04:54 2010
From: report at bugs.python.org (Marcel Tschopp)
Date: Tue, 09 Mar 2010 10:04:54 +0000
Subject: [issue8096] locale.format_string fails on mapping keys
In-Reply-To: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>
Message-ID: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>


New submission from Marcel Tschopp <mts at polynorm.ch>:

locale.format_string doesn't return same result as a normal "string" % format directive, but raises a TypeError.

>>> locale.format_string('%(key)s', {'key': 'Test'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/locale.py", line 225, in format_string
    val[key] = format(perc.group(), val[key], grouping)
  File "/usr/local/lib/python2.6/locale.py", line 182, in format
    formatted = percent % value
TypeError: format requires a mapping

----------
components: Library (Lib)
messages: 100709
nosy: mtschopp
severity: normal
status: open
title: locale.format_string fails on mapping keys
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8096>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:09:06 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 10:09:06 +0000
Subject: [issue8095] test_urllib2 crashes on OS X 10.3 attempting to retrieve
	network proxy configuration
In-Reply-To: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>
Message-ID: <1268129346.82.0.105764166971.issue8095@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't have a 10.3 system to test on, and definitely don't want to spent effort on enabling compiles on 10.3

The patch below would probably fix the crash when running a binary created on 10.4 or later on osx 10.3:

Index: ../Mac/Modules/_scproxy.c
===================================================================
--- ../Mac/Modules/_scproxy.c	(revision 78807)
+++ ../Mac/Modules/_scproxy.c	(working copy)
@@ -64,13 +64,18 @@
 	result = PyDict_New();
 	if (result == NULL) goto error;
 
-	aNum = CFDictionaryGetValue(proxyDict, 
+	if (kSCPropNetProxiesExcludeSimpleHostnames != NULL) {
+		aNum = CFDictionaryGetValue(proxyDict, 
 			kSCPropNetProxiesExcludeSimpleHostnames);
-	if (aNum == NULL) {
-		v = PyBool_FromLong(0);
-	} else {
-		v = PyBool_FromLong(cfnum_to_int32(aNum));
+		if (aNum == NULL) {
+			v = PyBool_FromLong(1);
+		} else {
+			v = PyBool_FromLong(cfnum_to_int32(aNum));
+		}
+	}  else {
+		v = PyBool_FromLong(1);
 	}
+
 	if (v == NULL) goto error;
 
 	r = PyDict_SetItemString(result, "exclude_simple", v);


The patch hasn't been compiled yet, but the idea should be clear: test if kSCPropNetProxiesExcludeSimpleHostnames has a valid value before using it, default to 'True'.

(This also changes the default on 10.4/10.5, IMHO defaulting to true would be better: I haven't seen an enviroment yet where local systems should be accessed through a proxy).

BTW. Removing 3.1 and 3.2 because _scproxy isn't in those releases yet (mostly because porting requires signifant changes to the C code and I haven't had time to do that yet)

----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:27:39 2010
From: report at bugs.python.org (Andreas Pfeiffer)
Date: Tue, 09 Mar 2010 10:27:39 +0000
Subject: [issue8097] bug in modulefinder: import_hook() got an unexpected
	keyword argument 'level'
In-Reply-To: <1268130459.3.0.847669819977.issue8097@psf.upfronthosting.co.za>
Message-ID: <1268130459.3.0.847669819977.issue8097@psf.upfronthosting.co.za>


New submission from Andreas Pfeiffer <andreas.pfeiffer at cern.ch>:

Hi,

  the attached file (moduleFinderBug.py) crashes in python 2.6 on
linux (RedHat EL 5) and Mac OS X (10.6) with the traceback below.

A possible fix for this would be in modulefinder.py:
323c323
<             self.import_hook(name, caller, level=level)
---
>             self.import_hook(name, caller=caller, level=level)

Please let me know if you need any further information.

Thanks,
   cheers, andreas



$> python moduleFinderBug.py
Traceback (most recent call last):
  File "work/cms/moduleFinderBug.py", line 17, in <module>
    modulefinder.run_script(filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 114, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 305, in load_module
    self.scan_code(co, m)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 414, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 323, in _safe_import_hook
    self.import_hook(name, caller, level=level)
TypeError: import_hook() got an unexpected keyword argument 'level'

----------
components: Extension Modules
files: moduleFinderBug.py
messages: 100711
nosy: andreas
severity: normal
status: open
title: bug in modulefinder: import_hook() got an unexpected keyword argument 'level'
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16509/moduleFinderBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8097>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:33:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 10:33:13 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268130793.55.0.766108560199.issue8091@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage:  -> committed/rejected
status: open -> pending
superseder:  -> subprocess.POpen.__del__() AttributeError (os module == None!)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:33:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 10:33:27 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268130807.79.0.954184149011.issue8091@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution:  -> duplicate
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:33:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 10:33:49 +0000
Subject: [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268130829.87.0.493520978473.issue8091@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8091>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:35:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 10:35:44 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1268130944.68.0.64936555209.issue5099@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:38:11 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 10:38:11 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268131091.64.0.0750307702672.issue8089@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've commited a fix for 2.6 in r78813.

I will port that fix to 3.1 later today, but don't have time to test right now.

My fix is simular to the patch by Ned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:47:25 2010
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 09 Mar 2010 10:47:25 +0000
Subject: [issue8098] PyImport_ImportModuleNoBlock() may solve problems but
	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

Back in time, the function PyImport_ImportModuleNoBlock() was introduced and used in modules such as the time module to supposedly avoid deadlocks when using threads. It may well have solved that problem, but only served to cause other problems.

To illustrate the problem consider the test code:


import imp
import thread
import time

def run1():
   print 'acquire'
   imp.acquire_lock()
   time.sleep(5)
   imp.release_lock()
   print 'release'

thread.start_new_thread(run1, ())

time.sleep(2)

print 'strptime'
time.strptime("", "")
print 'exit'


The output of running this is


grumpy:~ grahamd$ python noblock.py 
acquire
strptime
Traceback (most recent call last):
  File "noblock.py", line 17, in <module>
    time.strptime("", "")
ImportError: Failed to import _strptime because the import lockis held by another thread.


It is bit silly that code executing in one thread could fail because at the time that it tries to call time.strptime() a different thread has the global import lock.

This problem may not arise in applications which preload all modules, but it will where importing of modules is deferred until later within execution of a thread and where there may be concurrent threads running doing work that requires modules imported by that new C function.

Based on old discussion at:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/dad73ac47b81a744

my expectation is that this issue will be rejected as not being a problem with any remedy being pushed to the application developer. Personally I don't agree with that and believe that the real solution is to come up with an alternate fix for the original deadlock that doesn't introduce this new detrimental behaviour. This may entail structural changes to modules such as the time module to avoid issue.

Unfortunately since the PyImport_ImportModuleNoBlock() function has been introduced, it is starting to be sprinkled like fairy dust across modules in the standard library and in third party modules. This is only going to set up future problems in multithreaded applications, especially where third party module developers don't appreciate what problems they are potentially introducing by using this function.

Anyway, not optimistic from what I have seen that this will be changed, so view this as a protest against this behaviour. :-)

FWIW, issue in mod_wsgi issue tracker about this is:

http://code.google.com/p/modwsgi/issues/detail?id=177

I have known about this issue since early last year though.

----------
components: Interpreter Core
messages: 100713
nosy: grahamd
severity: normal
status: open
title: PyImport_ImportModuleNoBlock() may solve problems but causes others.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8098>
_______________________________________

From report at bugs.python.org  Tue Mar  9 11:58:30 2010
From: report at bugs.python.org (Dominique Leuenberger)
Date: Tue, 09 Mar 2010 10:58:30 +0000
Subject: [issue8083] urllib proxy interface is too limited
In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za>
Message-ID: <1268132310.27.0.776607401649.issue8083@psf.upfronthosting.co.za>


Dominique Leuenberger <dominique.leuenberger at gmail.com> added the comment:

I like the idea of having the proxy handler expanded. In fact I suggest to base the idea on libproxy ( http://code.google.com/p/libproxy ) which is available on Linux / openSolaris / Windows and Mac (currently).

Libproxy queries the correct settings to be used from KDE and gnome, depending on the currently running session. A fallback is of course env.

the API of libproxy is very simple and python bindings are available.

----------
nosy: +Dominique.Leuenberger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8083>
_______________________________________

From report at bugs.python.org  Tue Mar  9 12:55:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 09 Mar 2010 11:55:27 +0000
Subject: [issue8096] locale.format_string fails on mapping keys
In-Reply-To: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>
Message-ID: <1268135727.15.0.433254901421.issue8096@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There's definitely some weirdness going on with handling mapping keys. I'll look at it.

----------
assignee:  -> eric.smith
keywords: +easy
nosy: +eric.smith
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8096>
_______________________________________

From report at bugs.python.org  Tue Mar  9 12:55:54 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 09 Mar 2010 11:55:54 +0000
Subject: [issue8092] utf8, backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268135754.88.0.903955158863.issue8092@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

After the patch the comment:

/* Implementation limitations: only support error handler that return
    bytes, and only support up to four replacement bytes. */

no longer applies.

Also I would like to see a version of this patch where the length limitation for the replacement returned from the error handler is removed (ideally for both the str and bytes case).

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8092>
_______________________________________

From report at bugs.python.org  Tue Mar  9 13:42:21 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 12:42:21 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268138541.02.0.893441053626.issue8089@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for the fix guys.  I believe this means it's no longer a blocker for 2.6.5rc2, right?

----------
priority: release blocker -> high
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 14:22:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Mar 2010 13:22:55 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1268140975.69.0.170392112859.issue8036@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

2.6 and 3.0.1 used to disable the Microsoft CRT argument error handler: they return EINVAL, but newer versions don't, and should check their arguments before calling _spawnv.

FWIW, the checks are::
    pathname != NULL
    *pathname != '\0'
    argv != NULL
    *argv != NULL
    **argv != '\0'
The first and third checks are guaranteed by the implementation, but the other three should be done in posix_spawnv().
And the other calls to the various nt.spawn* functions probably suffer the same problem.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:06:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 14:06:24 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1268143584.71.0.0187998638432.issue7755@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Martin,

Conventional wisdom on #python-dev is that you have a Solaris machine that you could test this on.  Can you do that?  I'd like to get this patch into 2.6.6 if it works.

----------
assignee:  -> loewis
keywords: +needs review
nosy: +loewis
priority: normal -> deferred blocker
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:13:48 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 09 Mar 2010 14:13:48 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1268144028.34.0.423397108448.issue8036@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Why is the Microsoft CRT argument error handler no longer disabled?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:24:59 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Mar 2010 14:24:59 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1268144699.93.0.139025931573.issue8036@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Because this is a global setting for the whole process. This was discussed with issue4804.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:36:02 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Tue, 09 Mar 2010 14:36:02 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1268145362.16.0.771176301146.issue6538@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Er, ignore my comment then!

If this is reviewed, can it get committed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:37:57 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 14:37:57 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1268145477.95.0.946753893527.issue7755@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Or maybe this one :)

----------
Added file: http://bugs.python.org/file16510/guido.au

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:38:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:38:44 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268145524.6.0.973148468177.issue8094@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Are you running this on windows?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:42:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:42:15 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268145735.6.0.533763245179.issue6656@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:45:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:45:33 +0000
Subject: [issue8096] locale.format_string fails on mapping keys
In-Reply-To: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>
Message-ID: <1268145933.87.0.893263598908.issue8096@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 6656.  This bug isn't a quite a duplicate of that bug, but I did discover (and fix) the bug this one reports in the process of creating a patch for that one, so I'm closing this one as a duplicate anyway.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> locale.format_string fails on escaped percentage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8096>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:47:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:47:45 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268146065.63.0.736562095049.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, the patch for this issue contains a fix for issue 8094.  The only reason I haven't applied it is the fear of breaking existing correct behavior because there aren't enough tests.  Maybe you can see an easy way to reuse the % test suite to check local.format_string?  (I didn't look at that option very hard.)  Or maybe we just apply it anyway...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:47:58 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 09 Mar 2010 14:47:58 +0000
Subject: [issue8056] Piped parent's multiprocessing.Process children cannot
	write to stdout
In-Reply-To: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>
Message-ID: <1268146078.27.0.577235733579.issue8056@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

I tried to reproduce / narrow-down the cause of this with a debug build in a VM but couldn't reproduce the behaviour (neither with debug nor with standard 2.6.4 binary). I have to conclude that there is something perculiar with my native Windows installation (since in both VM and natively Python is using exactly the same DLLs and ).

Apologies for wasting your time.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8056>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:48:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:48:48 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268146128.83.0.0884031747158.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I meant issue 8096.

----------
nosy: +mtschopp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:49:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:49:50 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268146190.82.0.0576366813149.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, the patch for this issue contains a fix for issue 8096.  The only reason I haven't applied it is the fear of breaking existing correct behavior because there aren't enough tests.  Maybe you can see an easy way to reuse the % test suite to check local.format_string?  (I didn't look at that option very hard.)  Or maybe we just apply it anyway...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:49:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:49:58 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268146198.01.0.879620160983.issue6656@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 15:50:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 14:50:04 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1268146204.61.0.0462010773066.issue6656@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:01:29 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Tue, 09 Mar 2010 15:01:29 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268146889.83.0.0447044084359.issue8094@psf.upfronthosting.co.za>


Benjamin VENELLE <kain94 at gmail.com> added the comment:

Sorry I've not made clear my working platform.

Yes, I'm running Python 3.1.1 32 bit on a Windows 7 x64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:04:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 15:04:46 +0000
Subject: [issue8097] bug in modulefinder: import_hook() got an unexpected
	keyword argument 'level'
In-Reply-To: <1268130459.3.0.847669819977.issue8097@psf.upfronthosting.co.za>
Message-ID: <1268147086.86.0.376165742209.issue8097@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless I'm missing something, this appears to be a bug in your code.  You redefine import_hook in your subclass, but you don't give it a level parameter.

----------
components: +Library (Lib) -Extension Modules
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8097>
_______________________________________

From report at bugs.python.org  Tue Mar  9 16:27:58 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Mar 2010 15:27:58 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268148478.29.0.422381808455.issue8094@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The restriction that imposes the "__name__= '__main__'" idiom also applies when multiprocessing is not used in the main module.

Actually the main module is always reloaded in the subprocess.  The docs should be more explicit about it.

----------
assignee:  -> jnoller
nosy: +amaury.forgeotdarc, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Tue Mar  9 17:10:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 16:10:23 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268151023.5.0.00337233536449.issue8094@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Documentation -Library (Lib)
priority:  -> normal
stage:  -> needs patch
type: crash -> behavior
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8094>
_______________________________________

From report at bugs.python.org  Tue Mar  9 17:10:37 2010
From: report at bugs.python.org (Estroms)
Date: Tue, 09 Mar 2010 16:10:37 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>


New submission from Estroms <tuomas.engstrom at gmail.com>:

I downloaded Python 3.1 yesterday. I can open the Python command line, but when i press IDLE(Python GUI)shortcut no window or program opens.

i typed to command promt C:\Python31\lib\idlelib\idle.py and got an error message. It's too long to write to here, but in the end of it, it said that "This probably means that Tcl wasn't installed properly". What should I do?

----------
components: IDLE
messages: 100734
nosy: Estroms
severity: normal
status: open
title: IDLE(Python GUI) Doesn't open
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Tue Mar  9 17:50:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Mar 2010 16:50:29 +0000
Subject: [issue8090] PEP 4 should say something about the standard library
In-Reply-To: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>
Message-ID: <1268153429.77.0.285274999691.issue8090@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> low
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8090>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:47:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Mar 2010 17:47:26 +0000
Subject: [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1268156846.44.0.543831438911.issue8093@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I reproduced this with 3.1.1 on xp. It took a while to get the shell menu to restart as the calculation process is hogging the cpu 99%.
KeyboardInterrupt (^C) would not stop the runaway process. There may have been other issues about this.

Two processes is normal - one for the shell and one for calculations. The 'normal' behavior of Restart Shell (^F6) is to start a third process. Watching in task manager, the abandoned calculation process dies in 3-4 seconds. A stuck process does not end on its own though. Bad bug.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8093>
_______________________________________

From report at bugs.python.org  Tue Mar  9 18:59:40 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 09 Mar 2010 17:59:40 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

The comment in configure.in says that some changes aren't applied to OPT variable when OPT variable has been set by the user, but they are applied when empty OPT has been explicitly set. The attached patch fixes this problem.

----------
components: Build
files: python-OPT.patch
keywords: patch
messages: 100736
nosy: Arfrever
severity: normal
status: open
title: `configure` incorrectly handles empty OPT variable
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16511/python-OPT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:08:03 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 09 Mar 2010 18:08:03 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1268158083.03.0.887303696205.issue6943@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I noticed suboptimal output of `configure`:
checking for --with-libs... no
checking for --with-system-expat... yes
checking for --with-system-ffi... checking for x86_64-pc-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
yes
checking for --with-dbmliborder... gdbm

The attached patch fixes this problem.

----------
Added file: http://bugs.python.org/file16512/python-pkg-config_detection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Tue Mar  9 19:28:46 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 18:28:46 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268159326.15.0.192315130583.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Almost!  There's a small but significant typo that needs to be fixed in 
the change (r78813) that was committed for 2.6:

- UNIVERSAL_ARCH64_FLAGS="-arch x86_64 -arch x86_64"
+ UNIVERSAL_ARCH64_FLAGS="-arch x86_64 -arch ppc64"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 20:37:11 2010
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 09 Mar 2010 19:37:11 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

2.6.4 had been working fine for me.  Today, though, it will not stay up.  I run the Django development server on Windows 7, and 2.6.4 is repeatedly crashing on me:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Validating models...
Assertion failed: w32_sharedptr->size == sizeof(W32_EH_SHARED), file ../../gcc-3.4.5/gcc/config/i386/w32-shared-ptr.c, line 247

I have no idea what's changed between yesterday and today.

----------
components: None
messages: 100739
nosy: nedbat
severity: normal
status: open
title: w32-shared-ptr.c assertion on Windows 7 with 2.6.4
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:04:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Mar 2010 20:04:39 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268165079.11.0.123895618622.issue8089@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:09:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Mar 2010 20:09:43 +0000
Subject: [issue7772] test_py3kwarn fails when running the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1268165383.27.0.500466724477.issue7772@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r78815.
Issue #7092 should silence py3k warnings (soon).
Next step is to activate "-3" on some buildbot.

----------
assignee:  -> flox
dependencies:  -Test suite emits many DeprecationWarnings when -3 is enabled
priority:  -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7772>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:22:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Mar 2010 20:22:14 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <4B96ADF3.4020808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What should I do?

Unset the the TCL_LIBRARY and TK_LIBRARY environment variables, and
report whether it helped.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:24:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Mar 2010 20:24:09 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268166249.51.0.407485677733.issue8101@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Where did you get your copy of Python from?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:26:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:26:34 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Current 2.6.5rc1+ building on OS X:

======================================================================
ERROR: test_setuptools_compat (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/test_build_ext.py", line 350, in test_setuptools_compat
    from setuptools_build_ext import build_ext as setuptools_build_ext
ImportError: No module named setuptools_build_ext

----------------------------------------------------------------------

----------
assignee: tarek
components: Distutils
messages: 100743
nosy: barry, ned.deily, tarek
severity: normal
status: open
title: test_distutils fails on 2.6.5rc1: "No module named setuptools_build_ext"
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:28:04 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:28:04 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268166484.19.0.146410785241.issue8102@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(I should add that this appears to be simply a missing test file.  There is no indication that distutils itself has a problem.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:30:22 2010
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 09 Mar 2010 20:30:22 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268166622.94.0.710563845609.issue8101@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

I got it from python.org, the .msi Windows installer:

03/02/10 05:27:37p      14,890,496 \kit\python-2.6.4.msi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:32:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Mar 2010 20:32:23 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268166743.01.0.378523276419.issue8100@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> low
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:36:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 09 Mar 2010 20:36:47 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268167007.52.0.617497025871.issue8102@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This file was added in r75256. Are you sure you miss that test file ?

----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:39:40 2010
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 09 Mar 2010 20:39:40 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268167180.15.0.143834468355.issue8101@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

I tried rebooting my PC, but the problem persists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:41:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Mar 2010 20:41:08 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268167268.73.0.895980278999.issue8101@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's very strange. I'm fairly certain there is no GCC code whatsoever in my Python msi distribution. So you must be picking up some other code. Are you sure you are not running a Cygwin copy of Python or some such?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:43:00 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Tue, 09 Mar 2010 20:43:00 +0000
Subject: [issue8103] threading.start() : unable to restart thread
In-Reply-To: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>
Message-ID: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

I've found a bug in threading module. "self._started" event is never cleared when thread terminates. So, at line 452, in start() function, the test "if self._started.is_set():" prevents any restart.

PS: I saw this bug in Python 3.1.1 32 bit on a Windows 7 platform.

----------
components: Library (Lib)
messages: 100749
nosy: Kain94
severity: normal
status: open
title: threading.start() : unable to restart thread
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8103>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:43:24 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:43:24 +0000
Subject: [issue7037] test_asynchat fails on os x 10.6
In-Reply-To: <1254514511.94.0.551531757653.issue7037@psf.upfronthosting.co.za>
Message-ID: <1268167404.02.0.39017797566.issue7037@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Still failing as of 2.6.5rc1.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7037>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:44:05 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:44:05 +0000
Subject: [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1268167445.13.0.531298417482.issue7040@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Still failing as of 2.6.5rc1.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7040>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:46:42 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 09 Mar 2010 20:46:42 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268167602.25.0.729878624393.issue8101@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Perhaps this is an issue in a 3rd-party extension module?  (Given that you're running Django, do you have a 3rd-party database connection module?; the last message in the log is "Validating models", does that require Django to go to the db to get the schema?)

Caveat: I'm not familiar with the Windows msi build of Python, so I could be way off here.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:50:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Mar 2010 20:50:57 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268167857.12.0.144383615171.issue8101@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Dave: it's indeed entirely possible that this is caused by an extension module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:52:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:52:12 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268167932.88.0.983639296642.issue8102@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The file is the source tree but it doesn't seem to get installed in the framework which is where the tests are being run from:

/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests$ ls -l setuptools*
-rw-rw-r--  1 root  admin  1592 Mar  9 11:27 setuptools_extension.py
-rw-rw-r--  1 root  admin  2385 Mar  9 11:39 setuptools_extension.pyc
-rw-rw-r--  1 root  admin  2385 Mar  9 11:39 setuptools_extension.pyo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Tue Mar  9 21:53:40 2010
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 09 Mar 2010 20:53:40 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268168020.17.0.0492455223355.issue8101@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

Yup, you're both right!

I had a C extension (for coverage.py) built for 2.5 in the 2.6 path.  Sorry for the false alarm.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:15:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 21:15:36 +0000
Subject: [issue8103] threading.start() : unable to restart thread
In-Reply-To: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>
Message-ID: <1268169336.1.0.522199688009.issue8103@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
nosy: +jnoller
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8103>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:17:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Mar 2010 21:17:47 +0000
Subject: [issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268169467.11.0.966408236307.issue8101@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8101>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:19:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Mar 2010 21:19:10 +0000
Subject: [issue8103] threading.start() : unable to restart thread
In-Reply-To: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>
Message-ID: <1268169550.87.0.11390695944.issue8103@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

By design, a thread object can be started only once:
http://docs.python.org/library/threading.html#threading.Thread.start

You should create another threading.Thread object.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8103>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:24:17 2010
From: report at bugs.python.org (stefanholek)
Date: Tue, 09 Mar 2010 21:24:17 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1268169857.9.0.738573223251.issue6953@psf.upfronthosting.co.za>


stefanholek <stefan at epy.co.at> added the comment:

To be zero-based, get_history_item would need to look like:

diff --git a/rl/readline.c b/rl/readline.c
index 33e9905..800bc00 100644
--- a/rl/readline.c
+++ b/rl/readline.c
@@ -559,7 +559,7 @@ get_history_item(PyObject *self, PyObject *args)
 
        if (!PyArg_ParseTuple(args, "i:index", &idx))
                return NULL;
-       if ((hist_ent = history_get(idx)))
+       if ((hist_ent = history_get(history_base + idx)))
                return PyString_FromString(hist_ent->line);
        else {
                Py_RETURN_NONE;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:35:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 21:35:04 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268170504.8.0.931748757678.issue8089@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: I fixed the typo in r78816

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:36:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Mar 2010 21:36:43 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1268169857.9.0.738573223251.issue6953@psf.upfronthosting.co.za>
Message-ID: <d38f5331003091336u63c124b8kffe8a4ca3524c508@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Mar 9, 2010 at 4:24 PM, stefanholek <report at bugs.python.org> wrote:
..
> To be zero-based, get_history_item would need to look like:
..
> + ? ? ? if ((hist_ent = history_get(history_base + idx)))

Did you test this with libedit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:44:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Mar 2010 21:44:15 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268171055.04.0.872623167966.issue8100@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r78817.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:44:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Mar 2010 21:44:33 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268171073.63.0.294881345173.issue8100@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:47:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Mar 2010 21:47:14 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1268171234.65.0.185662178668.issue6943@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r78819.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Tue Mar  9 22:59:16 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Mar 2010 21:59:16 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268171956.44.0.817355042227.issue8100@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:00:31 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 22:00:31 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1268172031.72.0.863621517773.issue6953@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Changing get_history_item to be 0-based would be a backward incompatible change.

The point of my report is that the documentation of the readline documentation should mention how the APIs actually behave, you currently have to hunt down that information in the documentation from libreadline.

Stefan's message does point to a potentional issue though: history_base is  not exposed to python code, and hence Python code cannot use the correct offset.  I don't understand the documentation for history_get in that same document though, it says "get the item at `offset`, starting from `history_base`". I don't understand if that means that `offset` must be at least `history_base` or something else (and won't read the readline sources to find out).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:01:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 22:01:53 +0000
Subject: [issue8095] test_urllib2 crashes on OS X 10.3 attempting to retrieve
	network proxy configuration
In-Reply-To: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>
Message-ID: <1268172113.58.0.506928105472.issue8095@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

OK, I tried the patch.  Reversing the default sense causes the proxy tests in test_urllib2 to fail on 10.6 et al.  So I changed the sense of the tests in the patch to match previous behavior; the modified patch is attached.  Unfortunately, it didn't help on 10.3; test_urllib2 still gets a bus error:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   _scproxy.so       	0x003b57ac get_proxy_settings + 0x6c
1   org.python.python 	0x00498dfc PyEval_EvalFrameEx + 0x535c
...

----------
Added file: http://bugs.python.org/file16513/issue-scconfig-10_3-trunk-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8095>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:06:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Mar 2010 22:06:47 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1268172407.2.0.917995044277.issue8065@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I my experience, reporting bugs in open source components of OSX to bugreport.apple.com is a waste of time.   Such reports are largely ignored  and they are not visible to upstream developers.

I believe the upstream for libedit is NetBSD, http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit, but I cannot find their bug tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:10:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 22:10:39 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268172639.03.0.331130536552.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Looks good for 2.6.5 (with 10.6 'intel' build).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:14:41 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 22:14:41 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1268172881.93.0.869749558759.issue8065@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Removed file: http://bugs.python.org/file16480/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:15:03 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Mar 2010 22:15:03 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1267784862.24.0.455687340788.issue8065@psf.upfronthosting.co.za>
Message-ID: <1268172903.92.0.449228929796.issue8065@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Without filing a bug Apple won't know that something is wrong and they will definitly not fix the issue. If you file an issue and post the radar number I'll ping the Python maintainer inside Apple.  There's little change that this will be fixed, but you never know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:29:01 2010
From: report at bugs.python.org (stefanholek)
Date: Tue, 09 Mar 2010 22:29:01 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1268173741.06.0.461129836842.issue6953@psf.upfronthosting.co.za>


stefanholek <stefan at epy.co.at> added the comment:

I have read the readline source code, and it does mean just that. :-) 

Anyway, this does not really apply to the stdlib because unless someone implements 'stifle_history' and friends 'history_base' is going to be 1 at all times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:49:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Mar 2010 22:49:53 +0000
Subject: [issue8065] Memory leak in readline.get_current_history_length
In-Reply-To: <1268172903.92.0.449228929796.issue8065@psf.upfronthosting.co.za>
Message-ID: <d38f5331003091449g6eecf435xd1858cb2da25a763@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I submitted two bug reports:

7734961
libedit history_truncate_file () fails to preserve magic line
Mac OS X
Other Bug
09-Mar-2010 05:48 PM
Open

7734839
libedit read_history() does not update history_length
Mac OS X
Other Bug
09-Mar-2010 05:39 PM
Open

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8065>
_______________________________________

From report at bugs.python.org  Tue Mar  9 23:57:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2010 22:57:47 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1268175467.92.0.848495415813.issue7300@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyString_Format() uses a "goto unicode;" if a '%c' or '%s' argument is unicode. The unicode label converts the partial formatted result (byte string) to unicode, and use PyUnicode_Format() to finish to formatting.

I don't think that you can apply the same algorithm here (converts the partial result to unicode) because it requires to rewrite the format string: arguments can be used twice or more, and used in any order.

Example: "{0} {1}".format("bytes", u"unicode") => switch to unicode occurs at result="bytes ", format=" {1}", arguments=(u"unicode"). Converts "bytes " to unicode is easy, but the format have to be rewritten in " {0}" or something else.

Call trace of str.format(): do_string_format() -> build_string() -> output_markup() -> render_field(). The argument type is proceed in render_field().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Wed Mar 10 00:44:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2010 23:44:36 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1268178276.71.0.00644839711154.issue7300@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

*Draft* patch fixing the issue: render_field() raises an error if the argument is an unicode argument, string_format() catchs this error and converts self to unicode and call unicode.format(*args, **kw).

Pseudo-code:

 try:
    # self.format() raises an error if any argument is 
    # an unicode string)
    return self.format(*args,**kw)
 except UnicodeError:
    unicode = self.decode(default_encoding)
    return unicode.format(*args, **kw)

The patch changes the result type of '{}'.format(u'ascii'): it was str and it becomes unicode. The new behaviour is consistent with "%s" % u"ascii" => u"ascii" (unicode).

I'm not sure that catching *any* unicode error is a good idea. I think that it would be better to use a new exception type dedicated to this issue, but it looks complex to define a new exception. I will may do it for the next patch version ;-)

----------
keywords: +patch
Added file: http://bugs.python.org/file16514/issue7300-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Wed Mar 10 00:50:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Mar 2010 23:50:05 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1268178605.83.0.110610602296.issue7300@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch converts the format string to unicode using the default encoding. It's inconsistent with str%args: str%args converts str to unicode using the ASCII charset (if a least one argument is an unicode string), not the default encoding.

>>> "\xff%s" % u'\xe9'
...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:25:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2010 00:25:45 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1268180745.69.0.520353307834.issue7267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

u'{0:c}'.format(256) formatter in implemented in Objects/stringlib/formatter.h and this C template is instanciated in... Python/formatter_string.c (and not Python/formatter_unicode.c). Extract of formatter_unicode.c comment:

/* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since
   we can live with only the string versions of those.  The builtin
   format() will convert them to unicode. */

format_int_or_long_internal() is instanciated (only once) with STRINGLIB_CHAR=char and so "numeric_char = (STRINGLIB_CHAR)x;" becomes "numeric_char = (char)x;" whereas x is a long in [0; 0x10ffff] (or [0; 0xffff] depending on Python unicode build option).

I think that 'c' format type should have its own function because 
format_int_or_long_internal() gets locale info, compute the number of digits, and other things not related to just creating one character from its code (chr(code) / unichr(code)). But it's just a remark, it doesn't fix this issue.

To fix this issue, I think that the FORMAT_LONG & cie templates should be instanciated twice (str & unicode).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7267>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:30:00 2010
From: report at bugs.python.org (Matt Gattis)
Date: Wed, 10 Mar 2010 00:30:00 +0000
Subject: [issue8104] socket.recv_into doesn't support a memoryview as an
	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>


New submission from Matt Gattis <gattis at gmail.com>:

>>> view = memoryview(bytearray(bufsize))
>>> while len(view):
...    view = view[sock.recv_into(view,1024):]
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: recv_into() argument 1 must be pinned buffer, not memoryview

----------
components: IO
messages: 100773
nosy: Matt.Gattis
severity: normal
status: open
title: socket.recv_into doesn't support a memoryview as an argument
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8104>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:42:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 00:42:26 +0000
Subject: [issue8105] mmap crash on Windows with out of range file descriptor
In-Reply-To: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>
Message-ID: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Creating an mmap object can crash the interpreter on Windows if a file descriptor is passed in which is outside of the range for _get_osfhandle. I noticed the crash possibility while reviewing the Modules/mmapmodule.c code for work on another issue related to the consistency of the exceptions which mmap raises.

This can be tested by creating a mmap object with the file descriptor for a socket. This is not a valid way to create an mmap, but it represents a valid file descriptor which is out of range. For example, I created a socket with a file descriptor of 124, and _get_osfhandle expects the descriptor to be between 0 and 23.

Patch against trunk, with a test.

Note that this does not seem to affect 2.6 (not sure why, yet).

----------
components: Library (Lib), Windows
files: mmap_crash.diff
keywords: patch
messages: 100774
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: mmap crash on Windows with out of range file descriptor
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16515/mmap_crash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8105>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:43:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 00:43:38 +0000
Subject: [issue8105] mmap crash on Windows with out of range file descriptor
In-Reply-To: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>
Message-ID: <1268181818.76.0.0517039646492.issue8105@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16515/mmap_crash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8105>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:43:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 00:43:48 +0000
Subject: [issue8105] mmap crash on Windows with out of range file descriptor
In-Reply-To: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>
Message-ID: <1268181828.88.0.789350865869.issue8105@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Added file: http://bugs.python.org/file16516/mmap_crash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8105>
_______________________________________

From report at bugs.python.org  Wed Mar 10 01:52:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 00:52:29 +0000
Subject: [issue8105] mmap crash on Windows with out of range file descriptor
In-Reply-To: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>
Message-ID: <1268182349.95.0.784378586527.issue8105@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I should add that I tried the same thing on linux and no crash occured, it properly raised an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8105>
_______________________________________

From report at bugs.python.org  Wed Mar 10 02:08:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 10 Mar 2010 01:08:01 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1268183281.66.0.084444210769.issue4473@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Ping...

Any hope for 2.7/3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Wed Mar 10 02:20:52 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 10 Mar 2010 01:20:52 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Current SSL module doesn't manage SSL sessions, so any connection must do the full SSL handshake.

SSL/TLS support session restarting, when an old SSL context is used in a new connection, so you don't need to do the full SSL handshake.

This is a huge performance improvement.

I think SSL module should keep a small pool of sessions in core, to reuse. Better yet:

a) In SSL sockets, a method should be added to get the SSL context.

b) When creating a SSL socket, in client mode, a new optional parameter should be accepted, for a SSL context.

c) When creating a SSL socket, in server mode, we have two options: a) provide a dictionary or similar, with different contexts for possible clients connections or, better b) provide a callback the SSL module will call when getting an incoming connection, with a session ID as a parameter. The callback can provide a session SSL state or "None". This second approach allow for session management, like expiration or persistence to disk.

(the second option is equivalent to the first if the dict-like object includes this logic inside)

What do you think?.

----------
components: Extension Modules
messages: 100777
nosy: jcea
severity: normal
status: open
title: SSL session management
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Wed Mar 10 05:38:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 04:38:43 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1268195923.0.0.762329000806.issue8106@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +janssen
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:05:15 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 10 Mar 2010 05:05:15 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1268197515.67.0.609741376262.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file16411/pydoc_gui.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Wed Mar 10 06:13:51 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 10 Mar 2010 05:13:51 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1268198031.66.0.235511008204.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Missed a buffer write in the gettopic() method. Fixed.
Plus some minor doc string changes.

Can someone change the stage to "patch review".  I can't do that myself.

Or is there something else I need to do first?

----------
Added file: http://bugs.python.org/file16517/pydoc_gui.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Wed Mar 10 09:20:21 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 10 Mar 2010 08:20:21 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

test_distutils fails like this:

test test_distutils crashed -- <type 'exceptions.TypeError'>: object of type 'NoneType' has no len()
Traceback (most recent call last):
  File "Lib\test\regrtest.py", line 560, in runtest_inner
    indirect_test()
  File "c:\Python26\lib\test\test_distutils.py", line 13, in test_main
    test.test_support.run_unittest(distutils.tests.test_suite())
  File "c:\Python26\lib\distutils\tests\__init__.py", line 30, in test_suite
    suite.addTest(module.test_suite())
  File "c:\Python26\lib\distutils\tests\test_build_ext.py", line 391, in test_suite
    src = _get_source_filename()
  File "c:\Python26\lib\distutils\tests\test_build_ext.py", line 22, in _get_sou
rce_filename
    return os.path.join(srcdir, 'Modules', 'xxmodule.c')
  File "c:\Python26\lib\ntpath.py", line 96, in join
    assert len(path) > 0
TypeError: object of type 'NoneType' has no len()

Not sure whether this is a regression from 2.6.4.

----------
assignee: tarek
components: Distutils
messages: 100779
nosy: barry, loewis, tarek
severity: normal
status: open
title: test_distutils fails on Windows in 2.6.5rc2
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:20:27 2010
From: report at bugs.python.org (Estroms)
Date: Wed, 10 Mar 2010 12:20:27 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268223627.11.0.421623247944.issue8099@psf.upfronthosting.co.za>


Estroms <tuomas.engstrom at gmail.com> added the comment:

I'm beginner, so where can I find those things?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Wed Mar 10 13:36:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Mar 2010 12:36:08 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268224568.18.0.0688583537267.issue8107@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This has been introduced in r77955, and affected all the 2.6 Windows buildbots (e.g. http://www.python.org/dev/buildbot/builders/x86%20XP-5%202.6/builds/9/steps/test/logs/stdio).
The problem is caused by the fact that "srcdir = sysconfig.get_config_var('srcdir')" returns None on Windows.

----------
keywords: +buildbot
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:44:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 13:44:39 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

There's such failure on trunk and py3k when openssl 0.9.8m is installed.
(Debian platform)
No failure with 0.9.8k.

test_ftplib
Exception in thread Thread-40:
Traceback (most recent call last):
  File "./Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "./Lib/test/test_ftplib.py", line 223, in run
    asyncore.loop(timeout=0.1, count=1)
  File "./Lib/asyncore.py", line 211, in loop
    poll_fun(timeout, map)
  File "./Lib/asyncore.py", line 154, in poll
    write(obj)
  File "./Lib/asyncore.py", line 88, in write
    obj.handle_error()
  File "./Lib/asyncore.py", line 84, in write
    obj.handle_write_event()
  File "./Lib/test/test_ftplib.py", line 290, in handle_write_event
    super(SSLConnection, self).handle_write_event()
  File "./Lib/asyncore.py", line 440, in handle_write_event
    self.handle_write()
  File "./Lib/asynchat.py", line 174, in handle_write
    self.initiate_send()
  File "./Lib/asynchat.py", line 215, in initiate_send
    self.handle_close()
  File "./Lib/test/test_ftplib.py", line 43, in handle_close
    self.close()
  File "./Lib/test/test_ftplib.py", line 316, in close
    self.socket.unwrap()
  File "./Lib/ssl.py", line 272, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1367: The operation did not complete (read)

----------
components: Extension Modules
messages: 100782
nosy: flox
priority: high
severity: normal
stage: test needed
status: open
title: test_ftplib fails with OpenSSL 0.9.8m
type: crash
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:45:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 13:45:11 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268228711.18.0.498631495401.issue8108@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +giampaolo.rodola, haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:47:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 13:47:36 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268228856.45.0.255639911151.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It occurs only for trunk and 3.x, where the "ftp over ssl" is implemented. See #2054.

And the Debian alpha buildbots have the same library 0.9.8m:
http://www.python.org/dev/buildbot/all/builders/alpha%20Debian%20trunk
http://www.python.org/dev/buildbot/all/builders/alpha%20Debian%203.x

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:49:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 13:49:03 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268228943.55.0.559552917796.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

OpenSSL changelog (scroll to 0.9.8m): http://www.openssl.org/news/changelog.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:50:29 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 10 Mar 2010 13:50:29 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268229029.65.0.874562278696.issue8107@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> high
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 14:56:26 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 10 Mar 2010 13:56:26 +0000
Subject: [issue7540] urllib2 request does not update content length after new
	add_data
In-Reply-To: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>
Message-ID: <1268229386.07.0.453956485807.issue7540@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

The reverts in SVN look good to me; re-closing this issue as no further action is required.

If there's a proposal for specific changes to urllib2 to improve diagnostics in unsupported cases, that should be detailed in a separate issue.

Marking this issue "invalid" since the original reported symptom was determined to be caused by an unsupported use (re-use of the request).

----------
resolution: accepted -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Wed Mar 10 15:18:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 14:18:10 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268230690.63.0.491530143059.issue8099@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

In a command prompt window, type the following:

C:\>set TCL_LIBRARY=
C:\>set TK_LIBRARY=
C:\>C:\Python31\python.exe C:\Python31\Lib\idlelib\idle.py

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:14:07 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 10 Mar 2010 15:14:07 +0000
Subject: [issue8109] Support for TLS Server Name Indication extension
In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>
Message-ID: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

SSL sockets should support SNI, both as servers and clients: http://en.wikipedia.org/wiki/Server_Name_Indication

After that, libraries that support SSL/TLS should be upgraded to take advantage of it.

Any interest in supporting this?.

----------
components: Extension Modules
messages: 100787
nosy: jcea
priority: normal
severity: normal
status: open
title: Support for TLS Server Name Indication extension
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8109>
_______________________________________

From report at bugs.python.org  Wed Mar 10 16:57:13 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 10 Mar 2010 15:57:13 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>


New submission from Dave Fugate <dfugate at microsoft.com>:

subprocess.py contains the following line (380 in CPython 2.6.3):
    mswindows = (sys.platform == "win32")

which only correctly detects CPython on Windows.  This line should be changed to:
    mswindows = (sys.platform == "win32" or sys.platform == "cli" or sys.platform == "silverlight")

so subprocess can be utilized from IronPython as well.

This bug should be trivial to fix.

----------
components: Library (Lib)
messages: 100788
nosy: midnightdf
severity: normal
status: open
title: subprocess.py doesn't correctly detect Windows machines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:04:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 16:04:31 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268237071.23.0.661603646661.issue8110@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
priority:  -> normal
stage:  -> test needed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:12:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 16:12:08 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268237528.74.0.193878415059.issue8110@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:13:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Mar 2010 16:13:28 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268237608.77.0.34833483739.issue8110@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Probably it should use platform.system() == 'Windows' instead.

----------
keywords: +easy
nosy: +dino.viehland, michael.foord, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:16:24 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Mar 2010 16:16:24 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268237784.2.0.440158755844.issue8110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

but, does it work even with your fix?
it seems to me that "from _subprocess import *" will fail miserably.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:19:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 16:19:30 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268237970.5.0.912371711913.issue8110@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Also, using platform.system() == 'Windows' would exclude IronPython running on Mono.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:21:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Mar 2010 16:21:49 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1268238109.11.0.510385417285.issue8074@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

fwiw, the similar issue2241 was rejected two years ago.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:22:13 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 10 Mar 2010 16:22:13 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268238133.36.0.273830158818.issue8110@psf.upfronthosting.co.za>


Dave Fugate <dfugate at microsoft.com> added the comment:

platform.system()=="Windows" won't work unless you change platform as well:
IronPython 2.6.1 DEBUG (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.system()
'cli'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:26:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Mar 2010 16:26:41 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268238401.29.0.210879752651.issue8110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

it's not about platform detection; does IronPython have the equivalent of msvcrt.open_osfhandle()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:27:58 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 10 Mar 2010 16:27:58 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268238478.97.0.401435235642.issue8110@psf.upfronthosting.co.za>


Dave Fugate <dfugate at microsoft.com> added the comment:

Is there any reason _subprocess couldn't be implemented in C#?  If not, this is the first of many steps needed to get subprocess working under IronPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:28:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 16:28:22 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268238502.91.0.787183315981.issue8110@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch, with duck subprocessing. :D

----------
keywords: +patch
Added file: http://bugs.python.org/file16518/issue8110_subprocess_mswindows.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:31:49 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 10 Mar 2010 16:31:49 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>


New submission from Thomas Wouters <thomas at python.org>:

docs.python.org is showing the docs for 2.6.5c2. As its most obvious bad consequence, docs.python.org/download.html doesn't offer any actual downloads, and there are no obvious (to newbies looking to download docs) links to working downloads.

----------
assignee: georg.brandl
components: Documentation
messages: 100797
nosy: georg.brandl, twouters
severity: normal
status: open
title: docs.python.org/download.html unhelpful.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:39:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 16:39:42 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268239182.0.0.661089354468.issue8110@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Amaury is right. On Windows, _subprocess is a built-in, so the platform stuff just currently enables further failure.

Dave: My C# skills aren't the greatest, but looking at PC/_subprocess.c there are a few Win32 functions you might need to P/Invoke, but I believe a lot of the functionality is supported in .NET.

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Wed Mar 10 17:47:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Mar 2010 16:47:15 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1268239635.99.0.739756861382.issue8074@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I like the feature. I'm a bit concerned about the proliferation of command line options for unittest though. 

Steve's rejection of the feature seemed to be on the basis that he didn't need it (or see a need for it). :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From sudhirsinghrana at gmail.com  Wed Mar 10 17:48:11 2010
From: sudhirsinghrana at gmail.com (sudhir singh rana)
Date: Wed, 10 Mar 2010 22:18:11 +0530
Subject: ubuntu : cannot find -lpython2.5 while building jcc for pylucene
Message-ID: <d6b7ed1d1003100848j1c83584ah4f33da6ac74f3229@mail.gmail.com>

Hi,

I am getting following error while buiding jcc for pylucene

/usr/bin/ld: cannot find -lpython2.5
collect2: ld returned 1 exit status

any idea which thing is causing this problem.

I am using pylucene 3.0.0.1 version with python 2.5.4 and with java-6-sun

Thanks
Sudhir

From report at bugs.python.org  Wed Mar 10 18:37:52 2010
From: report at bugs.python.org (tormen)
Date: Wed, 10 Mar 2010 17:37:52 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	depricated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>


New submission from tormen <tormen at gmx.net>:

This throws an exception and crashes your DocXMLRPCServer when using registered python functions that use function annotations.

Seems inconsistent to me.
Or is there a reason for this?

----------
messages: 100800
nosy: tormen
severity: normal
status: open
title: xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) depricated function "inspect.getargspec()"
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:39:04 2010
From: report at bugs.python.org (tormen)
Date: Wed, 10 Mar 2010 17:39:04 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	depricated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268242744.24.0.198009736118.issue8112@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

"This" refers to the summary of the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Wed Mar 10 18:48:04 2010
From: report at bugs.python.org (tormen)
Date: Wed, 10 Mar 2010 17:48:04 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268243284.9.0.206156926506.issue8112@psf.upfronthosting.co.za>


Changes by tormen <tormen at gmx.net>:


----------
title: xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) depricated function "inspect.getargspec()" -> xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function "inspect.getargspec()"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Wed Mar 10 19:27:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 18:27:05 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268245625.01.0.360284996688.issue8112@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you provide a test case which reproduces your issue?

----------
components: +Library (Lib)
nosy: +brian.curtin
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Wed Mar 10 20:07:46 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 10 Mar 2010 19:07:46 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268248066.28.0.602355069771.issue8100@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Could you apply this patch also in 3.1 branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Wed Mar 10 20:26:53 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 10 Mar 2010 19:26:53 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1268249213.52.0.138389866475.issue1222585@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching my own patch, which has the following advantages:
- Determination of target language is performed per source file instead of per list of source files passed to CCompiler.compile().
- Proper determination of linker.
- Proper support for CXXFLAGS and other variables.

----------
nosy: +Arfrever
Added file: http://bugs.python.org/file16519/python-distutils-C++.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 10 20:59:27 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 10 Mar 2010 19:59:27 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1268251167.62.0.215370264288.issue1222585@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Moved to distutils2 (distutils is feature frozen now)

----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 10 21:09:47 2010
From: report at bugs.python.org (Michael Droettboom)
Date: Wed, 10 Mar 2010 20:09:47 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1268251787.07.0.603387737477.issue1222585@psf.upfronthosting.co.za>


Michael Droettboom <mdboom at users.sourceforge.net> added the comment:

Does the reassignment only apply to the more recent more ambitious patch?  The original patch (and my forward porting of it) is purely a bugfix, not a feature freeze.  This is a showstopper bug for matplotlib on Solaris, for example, and I would hate to see its application further delayed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 10 21:17:38 2010
From: report at bugs.python.org (admin)
Date: Wed, 10 Mar 2010 20:17:38 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>


admin <roundup-admin at psf.upfronthosting.co.za> added the comment:

_PyGILState_Init() initialize autoInterpreterState variable. This variable have to be set before the first call to PyGILState_Ensure().

The problem is that _PyGILState_Init() is called late: at the end of Py_InitializeEx(). It's called after initsite(), whereas initsite() may need to call _PyGILState_Init().

Example: add the following lines at the end of site.py:
---
import readline
import rlcompleter
readline.parse_and_bind("tab: complete")
raw_input("press TAB")
---
Run an interpreter and press TAB:
---
$ ./python
press TABpython: Python/pystate.c:595: PyGILState_Ensure: Assertion `autoInterpreterState' failed.
Abandon
---

Other example of functiions using _PyGILState_Init(): _PyObject_Dump() (useful for debug), sqlite module, os.popen*(), ctypes Python callbacks, etc.

I don't know the right place for _PyGILState_Init() in Py_InitializeEx(). _PyGILState_Init() calls the following functions:
 - PyThread_get_thread_ident()
 - PyThread_allocate_lock()
 - PyThread_acquire_lock()
 - PyThread_release_lock()
 - Py_FatalError() (on error)

None of these function use Python functions, so _PyGILState_Init() can be called very early. The earliest position is just after the call to PyThreadState_New(), before PyThreadState_Swap(). It tested it and it works correctly.

If _PyGILState_Init() is called before PyThreadState_Swap(), PyThreadState_Swap() can be simplified (it doesn't need to check if GIL is initialized or not). Attached patch implement that.

--

I hit this bug when I was debuging Python: I added a call to _PyObject_Dump() which stopped Python (assertion error) because the GIL was not initialized :-/

I already hitted this bug some weeks ago when I was working on the thread state preallocation when creating a new thread: #7544.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Wed Mar 10 21:40:28 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 10 Mar 2010 20:40:28 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1268253628.91.0.467880064657.issue1222585@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

If we consider that Distutils didn't provide c++ support, and that it partially worked by accident (through gcc), I would call it a new feature. Especially since it requires a new option.

We are freezing the API so we can't add options to methods/functions. 

That's why it could be done on distutils2 instead, which will be released when 2.7 final is released (but not in the stdlib), and backward compatible with 2.4, 2.5, 2.6.

If we could do the proper job for C++ support in distutils2 that would be better. 

Notice that distutils2 is a fork of how distutils was in trunk last month, so it should be fairly simple to depend on it in your project, to benefit from new features etc. The goal is to push it back in the stdlib in 3.3. 

If you want to start a dev. branch of your project using distutils2, I am willing to help there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:28:55 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Mar 2010 22:28:55 +0000
Subject: [issue8100] `configure` incorrectly handles empty OPT variable
In-Reply-To: <1268248066.28.0.602355069771.issue8100@psf.upfronthosting.co.za>
Message-ID: <1afaf6161003101428o1ec387feg3a6a06f9eb1c132f@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/3/10 Arfrever Frehtes Taifersar Arahesis <report at bugs.python.org>:
>
> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:
>
> Could you apply this patch also in 3.1 branch?

Done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8100>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:30:29 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Wed, 10 Mar 2010 22:30:29 +0000
Subject: [issue8113] PyUnicode_AsUnicode doesn't check for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

The C-API function "PyUnicode_AsUnicode(PyObject *unicode)" does not check the argument for NULL pointers. 
It passes it directly to the macro "PyUnicode_Check(op)" which then crashes when trying to access "Py_TYPE(op)".

I marked this as Python 2.7 because I checked this on trunk but I assume that this bug is present in all versions.

The attached patch fixes this issue.

----------
files: PyUnicode_AsUnicode.patch
keywords: patch
messages: 100809
nosy: donlorenzo
severity: normal
status: open
title: PyUnicode_AsUnicode doesn't check for NULL pointer
versions: Python 2.7
Added file: http://bugs.python.org/file16520/PyUnicode_AsUnicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8113>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:40:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Mar 2010 22:40:50 +0000
Subject: [issue8113] PyUnicode_AsUnicode doesn't check for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268260850.21.0.580404743057.issue8113@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Why is that a bug? You shouldn't pass a NULL argument.

----------
nosy: +benjamin.peterson
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8113>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:44:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Mar 2010 22:44:18 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268261058.04.0.932471741089.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Um, this sucks because I think that that means it was introduced after 2.6.4 final.  Since it's a regression, marking as a blocker for 2.6.5 final, but in order to stay a blocker it has to be a really critical bug and I'll want to review the fix before it goes it (to make sure it doesn't break anything else).  Otherwise, I'll bump it down to deferred blocker and we can fix it for 2.6.6.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:51:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2010 22:51:54 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268261514.82.0.949734079328.issue8107@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r77955 is a backport of r69304, commit made 12 months before the backport. It's related to issue #4151.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:53:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2010 22:53:18 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268261598.88.0.276264671923.issue8107@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch replaces sysconfig.project_base by sysconfig.get_config_var('srcdir'). You can maybe use sysconfig.project_base if sysconfig.get_config_var('srcdir') is None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Wed Mar 10 23:58:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Mar 2010 22:58:29 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268261909.56.0.67175229893.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to trunk: r78826 + r78827. I will later backport to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Thu Mar 11 00:08:06 2010
From: report at bugs.python.org (Vivek Anand)
Date: Wed, 10 Mar 2010 23:08:06 +0000
Subject: [issue8114] python 2.6.4 installation is not working for the single
	user mode in vista.
Message-ID: <1268262486.45.0.509985990928.issue8114@psf.upfronthosting.co.za>


Changes by Vivek Anand <anand.vivek13 at gmail.com>:


----------
components: Windows
nosy: insidevivek
severity: normal
status: open
title: python 2.6.4 installation is not working for the single user mode in vista.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8114>
_______________________________________

From report at bugs.python.org  Thu Mar 11 00:23:23 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 10 Mar 2010 23:23:23 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268263403.32.0.821538148485.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This test just grabs xxmodule.c from Python to try out a compilation.

It's a lot of work just to try out a .c file in build_ext. I've already changed this in trunk by having a c file local to distutils tests, as a fallback in case the location cannot be found (depending on the execution context).

I can backport this to 2.6. It's pretty safe to do it since its just a change in the test, the distutils code is not changed. Barry let me know if you want me to do backport it in release26, and if yes, when I should do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 00:50:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 10 Mar 2010 23:50:26 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268265026.16.0.212276391514.issue8107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I'm guessing this falls into the same category as Issue8102, that is, since the python tests are also installed and run on end-user systems by various installers, it is important that none of the tests depend on files from a python build directory or source tree.  In other words, if a test needs a file, that file needs to be explicitly installed.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:02:14 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Thu, 11 Mar 2010 00:02:14 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1268265734.27.0.749665550971.issue3243@psf.upfronthosting.co.za>


Ryan Coyner <rcoyner at gmail.com> added the comment:

This patch and its tests still work. Any particular reason why it hasn't been adopted yet?

----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:09:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 00:09:36 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1268266176.03.0.269365715805.issue7880@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in r78828 and r78829 (py3k), except for the part related to #7774.

(It was turning buildbots red, after Victor fixed #3137)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7880>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:14:04 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 11 Mar 2010 00:14:04 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268266444.42.0.558278859329.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

This still seems to be a bug in Python 3.1.1, does it not? Can this be re-opened?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Mar 11 01:34:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 00:34:41 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268267681.27.0.829401206873.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Thanks to" my commit r78826 (fixing #3137), site errors are now fatal: Python exits with an error instead of just printing "import site failed; ...". It's the come back of #7774: test_executable_with_cwd of test_subprocess now always fail.

The test fails because of an error raise by the site module:
-----
Traceback (most recent call last):
  File "Lib/site.py", line 542, in <module>
    main()
  File "Lib/site.py", line 524, in main
    known_paths = addusersitepackages(known_paths)
  File "Lib/site.py", line 257, in addusersitepackages
    user_site = getusersitepackages()
  File "Lib/site.py", line 239, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "Lib/site.py", line 229, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/home/SHARE/SVN/python-trunk/Lib/sysconfig.py", line 494, in get_config_var
    return get_config_vars().get(name)
  File "/home/SHARE/SVN/python-trunk/Lib/sysconfig.py", line 402, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/home/SHARE/SVN/python-trunk/Lib/sysconfig.py", line 255, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/lib/python2.7/config/Makefile (No such file or directory)
-----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:00:30 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Thu, 11 Mar 2010 01:00:30 +0000
Subject: [issue8113] PyUnicode_AsUnicode doesn't check for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268269230.37.0.54067777682.issue8113@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

I thought that the CamelCase C-functions like PyUnicode_AsUnicode would check for errors like this and if you don't want error checking you can use the capitalized versions like PyUnicode_AS_UNICODE.
I just looked at the code for PyFloat_AsDouble and it checks for NULL pointers. so does PyInt_AsLong. 
OTOH, PyString_As<whatever> does not.
I didn't check on any other types.

So if it is not considered a bug then I just want to point out the inconsistency.

IMHO, the C-API documentation lacks information on how it behaves in error conditions (this might be a bit over generalized). Would there be interest in documentation patches in these cases or are developers expected to look at the actual source code for this kind of information?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8113>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:04:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 01:04:53 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268269493.93.0.252250706.issue7774@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed test failures related to incorrect sys.executable, which were visible after #3137 was fixed. Changesets r78830 and r78831.

Note: there's 2 comments related to #7774. To review when this issue is fixed:
 - Lib/sysconfig.py
 - Lib/test/test_subprocess.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:07:43 2010
From: report at bugs.python.org (Riccardo Rotondo)
Date: Thu, 11 Mar 2010 01:07:43 +0000
Subject: [issue8115] Pyojbc on Snow Leopard
In-Reply-To: <1268269662.95.0.833333019817.issue8115@psf.upfronthosting.co.za>
Message-ID: <1268269662.95.0.833333019817.issue8115@psf.upfronthosting.co.za>


New submission from Riccardo Rotondo <riccardo.rotondo at ct.infn.it>:

Hello, I'm having trouble with pyobj since I have installed Python 2.6.4 by official dmg download here. 
Befor I used python pre-installed in Snow Leopard and everything worked ok. Now I can't import pyobjc.
I tried to perform easy_install pyobjc but I can't still import objc. 
The strangest thing is that it works for previos version!
Here some log:
rmacbpro:~ riccardorotondo$ python
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
http://GCC 4.0.1 (Apple Inc. build 5493) on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named Foundation
>>> exit()
rrmacbpro:~ riccardorotondo$ python2.5
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24) 
http://GCC 4.2.1 (Apple Inc. build 5646) on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
>>> exit()

Thanks for help
Bye

Riccardo

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100823
nosy: RiccardoR, ronaldoussoren
severity: normal
status: open
title: Pyojbc on Snow Leopard
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8115>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:09:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 01:09:35 +0000
Subject: [issue8113] PyUnicode_AsUnicode doesn't check for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268269775.4.0.451534768891.issue8113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I just looked at the code for PyFloat_AsDouble and it checks for NULL pointers

It's just a little help for developers: it will raise the ugly TypeError("bad argument type for built-in operation") and returns -1.

It's never a good idea to pass NULL to a function of the Python C API. I think that most (or all?) functions will fail.

> IMHO, the C-API documentation lacks information on how it behaves 
> in error conditions (this might be a bit over generalized).

I didn't read the documentation, but you HAVE TO always check the result of a Python function.

If the function returns a PyObject*, you have to check that the result is not NULL. The same rule applies for Pyxxx_AsXxx(): you also have to check the result (the error value depends on the function). Eg. PyInt_AsLong() returns -1 on error: use (result == -1) && PyErr_Occured()) in the caller to detect an error.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8113>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:12:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 01:12:04 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268269924.82.0.984516778593.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My change about site initialization error raised 2 old issues: #7774 and #7880. flox commited a fix for #7880 and a workaround for #7774 (just enough to fix test_subprocess).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Thu Mar 11 02:47:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 11 Mar 2010 01:47:52 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268272072.18.0.868880114199.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Tarek, I guess the fix is as haypo suggests?  Just use sysconfig.project_base if sysconfig.get_config_var('srcdir') returns None?

If that's the only change, then please do fix this for 2.6.5 final.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:01:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 02:01:44 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268272904.99.0.753341780497.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is not related to subprocess, subprocess is just used in examples to show the bug. The problem is that Python defines an invalid sys.executable if the process was created with a custom argv[0]. In Python trunk, the site module now uses sysconfig which depends on sys.executable. If sys.executable, sysconfig fails, site import fails, and finally Python exists (since my fix for #3137). I think that we have to split the problem in two parts:

 1) Python startup fails if sysconfig raises an error
 2) sys.executable is invalid is argv[0] is modified

(1) Functions using (indirectly) sysconfig in site module:

 - addbuilddir()
 - addusersitepackages()

I don't know if Python should exits with an error if these functions fail.

(2) Except of Python unit test, is it required in "real world" applications? I know that Twisted does modify argv[0] to display "twistd" in process list. It looks like there is trivial, portable and/or reliable solution for this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:06:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 02:06:53 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268273213.67.0.577961210203.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooh, I shouldn't post messages at 3:05.

"If sys.executable *is invalid*, sysconfig fails, site import fails, and finally Python *exits* (since my fix for #3137)."

"It looks like there is *no* trivial, portable and/or reliable solution *to fix* this problem."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:18:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 02:18:47 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268273927.63.0.550729308029.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Twisted uses the following code (on UNIX-like OS):

def launchWithName(name):
    if name and name != sys.argv[0]:
        exe = os.path.realpath(sys.executable)
        log.msg('Changing process name to ' + name)
        os.execv(exe, [name, sys.argv[0], '--originalname'] + sys.argv[1:])

Twisted doesn't care if sys.executable is invalid when argv[0] has been changed. sys.executable is only used to change the process name (sys.executable is used before argv[0] is modified).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 03:29:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 02:29:19 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268274559.43.0.291976868544.issue7774@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Actually there's 3 steps to fix this:
1) do not absolutize the sys.executable if it is empty (in Modules/getpath.c)
2) change sysconfig.py to deal with empty sys.executable (see this patch)
3) do a best effort to provide a valid sys.executable.
   It should be possible in most cases.

See message above for details on (3):
http://bugs.python.org/issue7774#msg98284

Patch attached for (2). (Fixes tests)

----------
keywords: +patch
Added file: http://bugs.python.org/file16521/issue7774_sysconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:19:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 03:19:37 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1268277577.71.0.745214602473.issue4376@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ping! This issue is still open.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Thu Mar 11 04:31:52 2010
From: report at bugs.python.org (Jon Buller)
Date: Thu, 11 Mar 2010 03:31:52 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1265735234.86.0.775645542448.issue7424@psf.upfronthosting.co.za>
Message-ID: <4B98641F.9040706@bullers.net>


Jon Buller <jon at bullers.net> added the comment:

Sorry to not be able to follow up for so long, but I was moving 
cross-country.

I was playing with the tests a bit and ended up trying this:

$ ./python -E -tt -d -v -W all ./Lib/test/regrtest.py -l -v -s test_builtin

Which resulted (after quite a bit of output) in this:

# /usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.pyc matches 
/usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.py
import tempfile # precompiled from 
/usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.pyc
dlopen("/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.24-sparc-2.6/fcntl.so", 
2);
import fcntl # dynamically loaded from 
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.24-sparc-2.6/fcntl.so
import thread # builtin
test_builtin
[1]   Segmentation fault      ./python -E -tt -d -v -W all 
./Lib/test/regrtest.py -l -v -s test_builtin

So, is this perhaps a bug either in Python's thread usage, or NetBSD's 
thread
library?  Is there an easy way to tell python to build without any threads,
even if configure finds the proper system include files and libraries?  Is
it as simple as "./configure --without-threads" when starting the build?
(I'm about to try that...)

Jon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________

From report at bugs.python.org  Thu Mar 11 05:55:05 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Mar 2010 04:55:05 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268283305.71.0.755871416582.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

No that won't work because the test tries to find a module that is only in the source dir. So not existing on python installations. The simplest thing to do is to skip the test if srcdir cannot be found. 

I'll fix this asap

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 06:03:48 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Mar 2010 05:03:48 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268283828.29.0.0190966786171.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Also, notice that srcdir can be broken on some platform. For instance, under Mac OS X Framework install:

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('srcdir')
'/Volumes/Rivendell/Users/ronald/Projects/python/r264'

we get the path that was used by Ronald to compile the distribution :)

Working on it..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 07:25:46 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Mar 2010 06:25:46 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268288746.41.0.35823550243.issue8107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's not that "srcdir" is broken - that undoubtedly was the value of the source directory on the *build* machine.  The problem is that "srcdir", (and likely some other build related config variables) has no meaning other than on the *build* machine at the time of the build.  It (they) cannot in general be meaningfully used at execution time, particularly if the install takes place on a machine other than build machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 07:40:56 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Mar 2010 06:40:56 +0000
Subject: [issue8115] Pyojbc on Snow Leopard
In-Reply-To: <1268269662.95.0.833333019817.issue8115@psf.upfronthosting.co.za>
Message-ID: <1268289656.87.0.749105215391.issue8115@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This issue is off-topic for the python bugtracker.

But: to install pyobjc you need to do three things:

1) Download and install easy_install or distribute 
   (download from pypi.python.org)

2) Check that 'which easy_install' refers to a 
   file inside /Library/Frameworks/Python.framework

3) Run easy_install pyobjc==2.2

If that doesn't work: subscribe to the list at <http://www.python.org/community/sigs/current/pythonmac-sig/> and ask there.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8115>
_______________________________________

From report at bugs.python.org  Thu Mar 11 07:53:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Mar 2010 06:53:54 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268290434.04.0.32639680614.issue8107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

IMHO stuffing xxmodule.c inside the distutils test tree (see msg100815) is the right solution because the python source tree might not be present during testing (such as when the user does a binary install and then runs the unittests to check if everything works).

Tarek: sysconfig.get_config_var('srcdir') returns the value of 'srcdir' in  'Makefile' and that value is only valid during the build of Python. It is the variable that is used in Python's makefiles to refer to files in the source tree and is needed when you run configure from a directory that is not the root of the source tree.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 07:58:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Mar 2010 06:58:12 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268290692.55.0.920908264238.issue7774@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This doesn't fail on OSX when using a framework build of Python because that uses a different way to find sys.prefix: in Python.framework the shared library with the interpreter (libpython.so on Linux) is always in a known location relative to sys.prefix.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 08:47:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Mar 2010 07:47:02 +0000
Subject: [issue8104] socket.recv_into doesn't support a memoryview as an
	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268293622.78.0.958114579713.issue8104@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8104>
_______________________________________

From report at bugs.python.org  Thu Mar 11 08:49:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Mar 2010 07:49:44 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268293784.39.0.418567073903.issue8111@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Agreed.  I will have a more sane set of docs that are continually rebuilt vs. docs that are frozen in place for the next minor release that happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:31:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 11 Mar 2010 09:31:46 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1268299906.06.0.903067851509.issue7291@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

In this ticket, setting the authentication using a ProxyBasicAuthHandler is not yet addressed yet. (this was informed in the last note). Reopening this one to track it.

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Thu Mar 11 10:52:25 2010
From: report at bugs.python.org (Eric Devolder)
Date: Thu, 11 Mar 2010 09:52:25 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1268266444.42.0.558278859329.issue2698@psf.upfronthosting.co.za>
Message-ID: <f0531c171003110152s22879c83ka92d7857b91b1841@mail.gmail.com>


Eric Devolder <eric.devolder at gmail.com> added the comment:

Yes, I believe it is.

that should be re-opened.

2010/3/11 Craig McQueen <report at bugs.python.org>

>
> Craig McQueen <python at craig.mcqueen.id.au> added the comment:
>
> This still seems to be a bug in Python 3.1.1, does it not? Can this be
> re-opened?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2698>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16522/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________
-------------- next part --------------
<div>Yes, I believe it is.</div>
<div>??</div>
<div>that should be re-opened.<br><br></div>
<div class="gmail_quote">2010/3/11 Craig McQueen <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"><br>Craig McQueen &lt;<a href="mailto:python at craig.mcqueen.id.au">python at craig.mcqueen.id.au</a>&gt; added the comment:<br><br></div>This still seems to be a bug in Python 3.1.1, does it not? Can this be re-opened?<br>

<div>
<div></div>
<div class="h5"><br>----------<br><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue2698" target="_blank">http://bugs.python.org/issue2698</a>&gt;<br>
_______________________________________<br></div></div></blockquote></div><br>

From report at bugs.python.org  Thu Mar 11 11:36:10 2010
From: report at bugs.python.org (=?utf-8?q?Ale=C5=A1_Drinovec?=)
Date: Thu, 11 Mar 2010 10:36:10 +0000
Subject: [issue8116] Addition problem
In-Reply-To: <1268303770.93.0.756891541973.issue8116@psf.upfronthosting.co.za>
Message-ID: <1268303770.93.0.756891541973.issue8116@psf.upfronthosting.co.za>


New submission from Ale? Drinovec <ales.drinovec at gmail.com>:

*** Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40) [MSC v.1500 32 bit (Intel)] on win32. ***
>>> 5.1+3.8
8.899999999999999
>>> 4.1+4.8
8.899999999999999
>>> 

Tested in IDLE and in PyScripter

----------
components: Interpreter Core
messages: 100842
nosy: sailoral
severity: normal
status: open
title: Addition problem
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8116>
_______________________________________

From report at bugs.python.org  Thu Mar 11 12:30:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 11:30:35 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268307035.58.0.457722173269.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

getpath.patch: another patch written by flox. If argv[0] is set to a non existent program name, sys.executable is set to an empty string instead of a directory name.

Example of the bug with Python 2.5:

$ sh -c "exec -a xxx python -c 'import sys, os; print repr(sys.executable), repr(os.getcwd())'"
'/home/haypo/' '/home/haypo'

----------
Added file: http://bugs.python.org/file16523/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:26:18 2010
From: report at bugs.python.org (Jon Buller)
Date: Thu, 11 Mar 2010 12:26:18 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <4B98641F.9040706@bullers.net>
Message-ID: <4B98E165.2070807@bullers.net>


Jon Buller <jon at bullers.net> added the comment:

"./configure --without-threads" didn't seem to have any effect...  :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:34:04 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 11 Mar 2010 12:34:04 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>


New submission from Yuriy Taraday <yorik.sar at gmail.com>:

Screnario:
 - start logging, log something;
 - stop logging (stop application, for example);
 - start logging again after rotate interval passes.

log4j's RotatingFileAppender's behavior:
After restart, logfile is rotated if nessesary.

TimedRotatingFileHandler's behavior:
After restart do no checks on existing logs.

I thing, log4j's behavior is more intuitive. Patch adds necessary check to constructor.

----------
components: Library (Lib)
files: python-logging.diff
keywords: patch
messages: 100845
nosy: yorik.sar
severity: normal
status: open
title: TimedRotatingFileHandler doesn't rotate log file at startup.
type: behavior
Added file: http://bugs.python.org/file16524/python-logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:37:16 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 12:37:16 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268311036.36.0.423782371787.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

The "no header" thing is very much done on purpose, and it's documented in the upstream ElementTree documentation.

I suggest dropping this "Python 3 exists in its own universe" nonsense; it's not very professional, and it's hurting Python, its users, and all third party developers.  The "things I don't understand are braindead" stuff is less of a problem; that only hurts yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:40:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Mar 2010 12:40:22 +0000
Subject: [issue8116] Addition problem
In-Reply-To: <1268303770.93.0.756891541973.issue8116@psf.upfronthosting.co.za>
Message-ID: <1268311222.58.0.576454782276.issue8116@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug in Python:  it's an unavoidable symptom of using binary floating-point arithmetic internally to store values.

I recommend looking at the last chapter of the Python tutorial, which gives a very nice explanation of floating-point issues.

http://docs.python.org/3.1/tutorial/floatingpoint.html

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8116>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:52:45 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Thu, 11 Mar 2010 12:52:45 +0000
Subject: [issue8113] PyUnicode_AsUnicode doesn't check for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268311965.32.0.844366766934.issue8113@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

Thanks for the fast replies.

I used to groups some Python calls together and check in the end if any of them failed in one exception handling block. I will now check every call individually.

I will open a new bug for documentation fixes where there is now information on what a function returns when it fails.

feel free to set resolution to invalid. or what ever you feel is appropriate.

thanks again for your time.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8113>
_______________________________________

From report at bugs.python.org  Thu Mar 11 13:56:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 12:56:45 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268312205.94.0.103673536083.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r78835 (trunk) fixes getpath and includes also a fix for sysconfig which should fix test_executable_with_cwd() of test_subprocess.

My fix on sysconfig is different than flox's patch: since I fixed getpath, sys.executable cannot be a directory name. At revision r78835, sys.executable can have 3 values:
 (a) absolute path to Python executable name (most common case)
 (b) empty string if argv[0] has been set to a non existent program name
 (c) absolute path to a different program if argv[0] has been set to a different program, with or without path (eg. "true" and "/bin/path")

(c) is the worst case: Python refuses to start. r78835 fixes the site module error for case (b).

There are different methods to get the real program name, but no one is portable. As flox wrote, we can "do a best effort to provide a valid sys.executable". Extract of stackoverflow link:

 * Mac OS X: _NSGetExecutablePath() (man 3 dyld)
 * Linux: readlink /proc/self/exe
 * Solaris: getexecname()
 * FreeBSD: sysctl CTL_KERN KERN_PROC KERN_PROC_PATHNAME -1
 * BSD with procfs: readlink /proc/curproc/file
 * Windows: GetModuleFileName() with hModule = NULL

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:28:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 13:28:27 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268314107.74.0.441436042324.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There is a 4th case about sys.executable: If argv[0] is an empty string, Python search the absolute path of "python" (hardcoded program name). The result is /usr/bin/python in my Linux box, whereas the real program name should be /opt/pythontrunk/bin/python. I think that this case is a bug and should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:50:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 13:50:33 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268315433.31.0.756089997723.issue7774@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:52:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 13:52:04 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268315524.79.0.0999012773727.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh well, it's really hard to test the tests in my working copy because it depends on a lot of factors: the current working directory, is Python installed or not, the OS, etc. The test introduced in r78835 was incorrect (only the test, the fix is correct): r78836 fixes the test for Windows (where sys.executable is correct even if argv[0] is set to a non existent program name, I don't understand how) and r78837 fixes the test for Ubuntu.

r78837 is a temporary fix to workaround #7774 bug: it's the same hack used in test_executable_with_cwd() from test_subprocess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 14:57:00 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 13:57:00 +0000
Subject: [issue7114] HTMLParser doesn't handle <![CDATA[ ... ]]>
In-Reply-To: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>
Message-ID: <1268315820.17.0.235204677397.issue7114@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

And to clarify, XHTML is an reformulation of HTML4 using XML syntax, so you should use an XML parser to parse it, not an HTML parser.  The formats are related, but not identical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7114>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:03:12 2010
From: report at bugs.python.org (Estroms)
Date: Thu, 11 Mar 2010 14:03:12 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268316192.07.0.0719048598062.issue8099@psf.upfronthosting.co.za>


Estroms <tuomas.engstrom at gmail.com> added the comment:

When I write to Command Promt "C:\>set TCL_LIBRARY=" it says: "'C:\' is not recognized as an internal or external command, operable program or batch file."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:05:34 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 14:05:34 +0000
Subject: [issue5100] ElementTree.iterparse and Element.tail confusion
In-Reply-To: <1233259522.5.0.311608999465.issue5100@psf.upfronthosting.co.za>
Message-ID: <1268316334.22.0.815756247154.issue5100@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Footnote: "iterparse" does things this way mostly to keep the implementation simple and fast; due to buffering, the tree builder are usually ahead of the event generation with up to 16k.  See the note on this page:

http://effbot.org/zone/element-iterparse.htm

and the message it links to for more on this topic.

Your case is a very common use case for "tostring", so it would probably have made sense to make "tostring" skip the tail on the element itself, at least if it's whitespace only.  Guess we could add an option...

But in your case, you can probably just nuke or normalize the "tail" element before writing it out (i.e. set it to None or "\n").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5100>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:07:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Mar 2010 14:07:38 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268316458.87.0.452758794908.issue8099@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That was an example of the cmd prompt. 
Just type "set TCL_LIBRARY=" without the quotes, along with the contents of the other three lines except for the "C:\>".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:22:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Mar 2010 14:22:46 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268317366.97.0.877440287125.issue8117@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:40:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:40:20 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268318420.19.0.268003625726.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed on trunk with r78838.
Some extra work is required to port it to 3.x.

Thank you Fredrik and Antoine for reviewing this patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:45:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2010 14:45:50 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1268311036.36.0.423782371787.issue8047@psf.upfronthosting.co.za>
Message-ID: <20100311094522.2a2103e4@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The "no header" thing is very much done on purpose, and it's
> documented in the upstream ElementTree documentation.

I'm sorry, where is that?
I can't find it either at
http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm#elementtree.ElementTree.tostring-function
or
http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm#elementtree.ElementTree.ElementTree.write-method

> I suggest dropping this "Python 3 exists in its own universe"
> nonsense; it's not very professional, and it's hurting Python, its
> users, and all third party developers.

Ha. There has been a very long temporal window (until 3.1, probably)
during which things were very much in flux and anyone with a
professional knowledge of elementtree and XML APIs could chime in and
point out any nonsense in py3k.

Now Python 3.1 is out and as a result py3k also has to ensure upwards
compatibility for its own APIs. Of course we can still make exceptions
if the alleged breakage is truly major. To me, it doesn't /seem/ to be
the case here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:46:09 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 11 Mar 2010 14:46:09 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268318769.26.0.340745009342.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Adding xxmodule.c to the test directory is more than I want to do for 2.6.5.  The actual crash happens because if sysconfig.get_config_var('srcdir') returns None, os.path.join() will traceback.  It doesn't know how to handle None arguments.  So my suggestion is that when srcdir is None, fallback to using sysconfig.project_base as before.

As long as that is guaranteed to be a string, we won't get the crash.  _get_source_filename() will return some bogus but syntactically valid path, and then the os.path.exists() test in test_suite() will return False, so the test will be skipped.  That seems like the safest change for 2.6.5 final, though I am fine with backporting the trunk fix for realzies in 2.6.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:49:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:49:28 +0000
Subject: [issue1538691] Patch cElementTree to export CurrentLineNumber
Message-ID: <1268318968.94.0.880241117785.issue1538691@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

ElementTree fixed in 2.7. See #6472.

----------
dependencies:  -Update ElementTree with upstream changes
resolution: postponed -> fixed
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538691>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:51:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:51:36 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1268319096.96.0.200345141013.issue3475@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with latest xml.etree.

----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:52:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 11 Mar 2010 14:52:30 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1268319150.0.0.918096444406.issue7300@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure I'm wild about doing the work twice, once as string and once as unicode if need be. But I'll consider it, especially since this is only a 2.7 issue.

There could be side effects of evaluating the replacement strings, but I'm not sure it's worth worrying about. Attribute (or index) access having side effects isn't something I think we need to cater to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7300>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:53:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:53:29 +0000
Subject: [issue3151] elementtree serialization bug for weird namespace urls
In-Reply-To: <1213974981.57.0.313909578004.issue3151@psf.upfronthosting.co.za>
Message-ID: <1268319209.62.0.379849881603.issue3151@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in trunk.

----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3151>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:56:01 2010
From: report at bugs.python.org (admin)
Date: Thu, 11 Mar 2010 14:56:01 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264424764.68.0.913730662553.issue7774@psf.upfronthosting.co.za>


admin <roundup-admin at psf.upfronthosting.co.za> added the comment:

It may help to find other methods:
http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe


By the way, it should not "absolutize" the path when sys.executable is irrelevant. IMHO, it should render an empty thing in such case (code below).


--- Modules/getpath.c   (revision 77750)
+++ Modules/getpath.c   (working copy)
@@ -441,7 +441,7 @@
        }
        else
                progpath[0] = '\0';
-       if (progpath[0] != SEP)
+       if (progpath[0] != SEP && progpath[0] != '\0')
                absolutize(progpath);
        strncpy(argv0_path, progpath, MAXPATHLEN);
        argv0_path[MAXPATHLEN] = '\0';

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:57:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:57:28 +0000
Subject: [issue6565] improper use of __setitem__ in ElementTree for Python 3.1
In-Reply-To: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>
Message-ID: <1268319448.93.0.0991892603387.issue6565@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in 2.7 with #6472. It should be ported to 3.x later.

----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6565>
_______________________________________

From report at bugs.python.org  Thu Mar 11 15:59:14 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 14:59:14 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1268319554.78.0.525801370374.issue6230@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in trunk with #6472.

----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6230>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:00:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 15:00:15 +0000
Subject: [issue6265] cElementTree & ElementTree use different exceptions for
	XML Errors
In-Reply-To: <1244717207.44.0.0661498908043.issue6265@psf.upfronthosting.co.za>
Message-ID: <1268319615.24.0.845337714057.issue6265@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6265>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:01:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 15:01:45 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1268319705.36.0.361876809199.issue6232@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
dependencies:  -Update ElementTree with upstream changes
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6232>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:24:29 2010
From: report at bugs.python.org (Estroms)
Date: Thu, 11 Mar 2010 15:24:29 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268321069.47.0.856906563425.issue8099@psf.upfronthosting.co.za>


Estroms <tuomas.engstrom at gmail.com> added the comment:

When I type "set TCL_LIBRARY" it says "TCL_LIBRARY=C:IBMTOOLS\Python22\tcl\tcl18.4".
So I have older version of python on my computer in IBMtools, but I want to use the new Python. How can I uninstall older python, because it can't be found in Start menu and there is no uninstall program in python folder. So how can I uninstall it using command prompt?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:33:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Mar 2010 15:33:02 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268321582.53.0.586723913725.issue8099@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Just delete the Python22 folder.

Typing "set TCL_LIBRARY=" (note the equal sign) will unset the environment variable for that command prompt. Can you try running the steps from msg100786?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:38:24 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Mar 2010 15:38:24 +0000
Subject: [issue8118] PYTHON_API_VERSION needs to be bumped?
In-Reply-To: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>
Message-ID: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

If I understand the code correct Python 2.6 has the same value for PYTHON_API_VERSION, even though extensions are not compatible.

In particular: when you compile an extension that uses PyInt_Check with python2.6 and load that extension with python 2.5 you will not get a version warning from Py_InitModule4 and you will also not get the right answers from PyInt_Check.

This due to PyType_FastSubclass (in python 2.6) which tests flags in the type structure that are not initiazed in 2.5.  That is a change in the ABI and hence should be accompanied by increasing PYTHON_API_VERSION.

 
This is technically a bug in 2.6, but I'm not selecting that version in the list because increasing PYTHON_API_VERSION in 2.6.x would break existing installations when they upgrade.

----------
components: Extension Modules, Interpreter Core
messages: 100867
nosy: ronaldoussoren
priority: high
severity: normal
status: open
title: PYTHON_API_VERSION needs to be bumped?
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8118>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:49:03 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 11 Mar 2010 15:49:03 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268322543.87.0.574751943423.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Sorry, Antoine, but you can't possibly mean what you say here. The culprit in question is clearly one of the best hidden features of the new Py3 ET API. The only existing reference to it that I can find is the SVN commit comment when it was applied. How is that supposed to be any reason for keeping up "backwards compatibility" within the Py3 series?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:53:41 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Mar 2010 15:53:41 +0000
Subject: [issue8119] Minor comment error in configure.in ("malloc support"
	appears twice)
In-Reply-To: <1268322821.23.0.828766306245.issue8119@psf.upfronthosting.co.za>
Message-ID: <1268322821.23.0.828766306245.issue8119@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

A minor nit: configure.in has this comment twice:
"Check for Python-specific malloc support"

c.f.:

# Check for Python-specific malloc support
AC_MSG_CHECKING(for --with-tsc)

(snip)

# Check for Python-specific malloc support
AC_MSG_CHECKING(for --with-pymalloc)



Clearly the first one should read something like:
# Determine if the bytecode evaluation loop should be instrumented using the CPU timestamp-counter
or somesuch.

Seems to affect both trunk and py3k

----------
components: Interpreter Core
messages: 100869
nosy: dmalcolm
severity: normal
status: open
title: Minor comment error in configure.in  ("malloc support" appears twice)
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8119>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:54:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 11 Mar 2010 15:54:52 +0000
Subject: [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268322892.05.0.358739601768.issue8099@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I recommend against deleting that Python installation: it probably came from the PC vendor, and might serve a purpose.

Just unset TCL_LIBRARY, through the Windows Environment GUI. Ask on comp.lang.python how to do this, or on some Windows help forum.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8099>
_______________________________________

From report at bugs.python.org  Thu Mar 11 16:57:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Mar 2010 15:57:41 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1268323061.76.0.180593313292.issue6266@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with #6472.

----------
dependencies:  -Update ElementTree with upstream changes
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:07:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Mar 2010 16:07:17 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268323637.01.0.916564968275.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@Ronald, @Barry: Yes that's what I did in trunk, so I can just merge that revision. (r78707, r78709)

The only problem I had with it is that in case xxmodule.c changes, I have to change it there too, but it's no big deal.

Barry, I'll merge back this as soon as I get a correct wifi connection this week :)  (I am at a conference)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:15:02 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Mar 2010 16:15:02 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268324102.71.0.694420354438.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

What traceback do you get exactly ? The same one than the first TB of this issue ?

----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:25:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Mar 2010 16:25:01 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1268324701.29.0.261565403622.issue4376@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

theller> - Should 'part' be inserted as is, [possibly] leading 
theller>   to a total structure of fields with mixed byte order?

+1 for this option.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:47:08 2010
From: report at bugs.python.org (tormen)
Date: Thu, 11 Mar 2010 16:47:08 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268326028.4.0.266043862951.issue8112@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

Okey ...

Consider you have a function:
def fn( str:str ): pass

That you register to your DocXMLRPCServer:
register_function of SimpleXMLRPCDispatcher stores the function object  in the dictionary self.funcs under the name of the function (as key).

Then you start your server and access (with a browser) the ip and port of the machine running your xmlrpc server which calls
> DocXMLRPCRequestHandler.do_GET which
> generate_html_documenation() which copies the funcs dictionary into methods and hands it to
> ServerHTMLDoc.docserver which calls for each function name + function object:
> ServerHTMLDoc.docroutine which calls (for inspect.ismethod and inspect.isfunction):

inspect.getargspec on the function object

which will fail if you register an annotated function (like the above "fn") in the first place:
=========================================
  File "/usr/lib/python3.1/inspect.py", line 789, in getargspec
    raise ValueError("Function has keyword-only arguments or annotations"
ValueError: Function has keyword-only arguments or annotations, use getfullargspec() API which can support them
=========================================

Which most probably leads to the conclusion that you should just use the getfullargspec instead of getargspec just to avoid that the XMLRPC server crashes if someone registers a annotated function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:52:10 2010
From: report at bugs.python.org (tormen)
Date: Thu, 11 Mar 2010 16:52:10 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268326330.49.0.113107178573.issue8112@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

If you want an example:

pydoc3.1 xmlrpc.server

2nd usage pattern

change "SimpleXMLRPCServer" to "DocXMLRPCServer"
change function signature from "pow(self, x, y)" to "pow(self, x:int, y:int)"

and your good to go and have your doc xmlrpc server crashed the moment you send a get request to him (e.g. by accessing "http://ip:port" in the browser of your choice).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:53:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Mar 2010 16:53:28 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268326408.31.0.811799331848.issue8047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I suspect that what Antoine is referring to is the fact that Python 3.1 has this behavior.  Whether or not it is explicitly documented is a secondary issue.

We're having a similar issue in the unittest package, where there's a new function, assertSameElements, that has an unfortunate and poorly documented API.  But changing that API now that the function exists in a released version (3.1) is not something to be done lightly, if it is done at all.

This is definitely an unfortunate state of affairs no matter how you look at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 17:55:45 2010
From: report at bugs.python.org (tormen)
Date: Thu, 11 Mar 2010 16:55:45 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268326545.43.0.783913512945.issue8112@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

If you want I can send you a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Thu Mar 11 19:01:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Mar 2010 18:01:05 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268330465.51.0.603369171916.issue8112@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A patch with tests would be an excellent thing to have.

----------
nosy: +r.david.murray
priority:  -> normal
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:01:13 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 19:01:13 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268334073.06.0.43535054637.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

> if I don't specify an encoding, I get unicode.  If I do specify an encoding, I get encoded bytes.

You're confusing the XML document encoding with character set encoding.

A serialized (unparsed) XML document is a byte stream, not a string of Unicode characters.  And the character set encoding is both embedded in that byte stream and affects how it's generated in more than one way; you cannot just recode XML documents nilly willy and expect things to work.

A parsed XML document (an infoset) -- for ET, that's the tree of Element objects -- does indeed contain Unicode strings, but the transformation from the byte stream to the Unicode string doesn't just involve character set decoding; there are several other constructs that are handled by the XML parser.

> Ha. There has been a very long temporal window

You should have had plenty of time to fix it, then, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:02:20 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 19:02:20 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268334140.7.0.648199809168.issue6472@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

W00t!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:08:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 11 Mar 2010 19:08:04 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1268334484.99.0.454938082495.issue8032@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I find the printing of frame objects confusing:

3033            f = PyFrame_New(tstate, co, globals, locals);
(gdb)
3034            if (f == NULL)
(gdb) p f
$3 = File /home/martin/work/27/Lib/encodings/utf_8.py, line 15, in decode ()

I didn't recognize that this is actually the output of the Frame; I recommend something like

  Frame %x, for file ....

Also, it prints NULL PyObject* as "<unknown at remote 0x0>". I think null pointers should be special cased, and just be printed as 0x0. Also, what is the "remote" keyword? Aren't all pointers remote in this application? I'd hope that local Python objects never show up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 11 20:38:09 2010
From: report at bugs.python.org (Dan Halbert)
Date: Thu, 11 Mar 2010 19:38:09 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1268336289.78.0.152470399601.issue5712@psf.upfronthosting.co.za>


Changes by Dan Halbert <halbert at halwitz.org>:


----------
nosy: +dhalbert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Thu Mar 11 21:22:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2010 20:22:52 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1268334073.06.0.43535054637.issue8047@psf.upfronthosting.co.za>
Message-ID: <20100311152240.29d621a3@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Ha. There has been a very long temporal window
> 
> You should have had plenty of time to fix it, then, right?

Under the condition that someone would have actually reported it, yes.
We don't magically fix bugs if nobody (including us) detects and reports
them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 21:43:46 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 11 Mar 2010 20:43:46 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268340226.82.0.544187181488.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Then I would call that a clear sign that no-one actually stumbled over this feature in Py3 before I did, well hidden as it was. Still time to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 21:48:50 2010
From: report at bugs.python.org (kwas)
Date: Thu, 11 Mar 2010 20:48:50 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268340530.85.0.999058692382.issue8117@psf.upfronthosting.co.za>


Changes by kwas <kvasiliev at gmail.com>:


----------
nosy: +kwas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:02:54 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Mar 2010 21:02:54 +0000
Subject: [issue8119] Minor comment error in configure.in ("malloc support"
	appears twice)
In-Reply-To: <1268322821.23.0.828766306245.issue8119@psf.upfronthosting.co.za>
Message-ID: <1268341374.18.0.783100654537.issue8119@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8119>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:12:01 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Mar 2010 21:12:01 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1268341921.61.0.426378948175.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for reviewing the patch.

I've changed the pretty-printing of NULL pointers to "0x0" as suggested, and I've updated frame printing.  Frames are now printed like this
(gdb) p f
$1 = Frame 0x827e544, for file /home/david/coding/python-gdb/crasher.py, line 19, in <module> ()

...so that in a gdb backtrace you might see:
#18 0x080f9aab in PyEval_EvalFrameEx (f=Frame 0x827e544, for file /home/david/coding/python-gdb/crasher.py, line 19, in <module> (), throwflag=0) at Python/ceval.c:2665

Is this what you had in mind?

As for the use of the word "remote",this is mostly for my own sanity, but I suspect it is needed.  My rationale for this is that there are two address spaces at play: the local address space with the gdb process, and the remote one within the inferior process.  It's possible for addresses with the gdb process to be printed for any object with a NULL tp_repr in its class, and if it were, it would be confusing which address space is it.

For example, if within gdb I run this command:
(gdb) python print repr(gdb.selected_frame())
<gdb.Frame object at 0xb753ef98>

the hexadecimal value that's printed is an address within gdb's address space, that of the python object wrapping the gdb frame information.

I did deliberately model the FakeRepr representation on the output of PyObject_Repr when tp_repr is NULL:
   PyString_FromFormat("<%s object at %p>", Py_TYPE(v)->tp_name, v);
adding the "remote" word to disambiguate things.

Is that OK?  It seemed to me like the best compromise of readability and lack of ambiguity.


I'm attaching an updated version of the patch (version 3), and am about to attach a diff against the last version (which was version 2)

There are some other substantial changes in the patch:
- Line numbers reported in frames were incorrect; I've fixed this, mimicking the "dis" module/PyCode_Addr2Line
- I've started to add various "py-" commands (with selftests):
  - "py-list" command, which tries to mimic gdb's "list" command, but at the level of Python source code
  - "py-up" and "py-down" command, which go up and down the stack, based on the location of PyEval_EvalFrameEx frames
  - "py-bt" which prints a python-level backtrace, based on the location of PyEval_EvalFrameEx frames
- I added a trivial script (Lib/test/test_gdb_sample.py) for use by the test cases for the above
- Fixed a bug in PyStringObjectPtr.proxyval() so that it now supports strings with embedded NUL characters
- Various comment fixes.

I split out the test cases into multiple classes, invoking them all.  All pass on my system, taking under 20 seconds ("Ran 28 tests in 17.770s")

----------
Added file: http://bugs.python.org/file16525/add-gdb7-python-hooks-to-trunk-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:12:52 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Mar 2010 21:12:52 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1268341972.1.0.384998636097.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attaching diff from v2 to v3

----------
Added file: http://bugs.python.org/file16526/diff-of-gdb7-hooks-v3-relative-to-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:14:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Mar 2010 21:14:40 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268342080.98.0.253844931674.issue8047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You may well be correct.  But just because no one reported a bug does not mean that no one is using the API.  The person using it may find it perfectly logical (and may be writing py3 only code, not porting py2 code).

However, regardless of whether we decide it is acceptable to change the behavior, it seems to me that having an interface named 'tostring' that returns bytes by default in Python3 would be a broken API.  I don't see any way around that terminology problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:39:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 21:39:29 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268343569.93.0.385218061714.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem comes from SSL_Shutdown() on a non blocking connection. See:
http://www.mail-archive.com/openssl-dev at openssl.org/msg24097.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:48:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 21:48:36 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268344116.81.0.629432223803.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch changing SSL_Shutdown() behaviour on non blocking socket was written in 2006 by Darryl Miles and it will commited into 0.9.8m. The original patch:
http://marc.info/?l=openssl-dev&m=115153998821797&w=2

In our testcase, SSL_Shutdown() fails with SSL_ERROR_WANT_READ, which means (extract of the email): "Return -1 WANT_READ while we are still waiting for the inbound recv notify alert to be received."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 11 22:52:12 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 11 Mar 2010 21:52:12 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1268344332.03.0.0541133145939.issue2001@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Mar 11 23:03:37 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Thu, 11 Mar 2010 22:03:37 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268345017.23.0.668251636636.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

>>> import array
>>> array.array("i", [1, 2, 3]).tostring()
b'\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 00:01:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2010 23:01:23 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1268345017.23.0.668251636636.issue8047@psf.upfronthosting.co.za>
Message-ID: <20100311180107.50c1e4df@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Thu, 11 Mar 2010 22:03:37 +0000,
Fredrik Lundh <report at bugs.python.org> a ?crit :
> 
> >>> import array
> >>> array.array("i", [1, 2, 3]).tostring()
> b'\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'

The fact that array is old, rusty and slightly broken doesn't meen we
should propagate that brokenness to other Python modules.
Also, as David said, the fact that you think there is a bug
here doesn't mean everyone would agree.
Finally, the behaviour you seem to be looking for could be added
as a separated API or an optional method argument. Patches welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 00:06:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Mar 2010 23:06:27 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268348787.2.0.278888188788.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

More informations:
http://www.openssl.org/docs/ssl/SSL_shutdown.html
http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=1891

Extract of the manual page:

 
 If the underlying BIO is non-blocking, SSL_shutdown() will also return when the underlying BIO could not satisfy the needs of SSL_shutdown() to continue the handshake. In this case a call to SSL_get_error() with the return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. ***The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_shutdown().*** The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition. When using a buffering BIO, like a BIO pair, data must be written into or retrieved out of the BIO before being able to continue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 00:09:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2010 23:09:57 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268348997.35.0.448452292625.issue8108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 00:15:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Mar 2010 23:15:58 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1268349358.96.0.104216068328.issue7424@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you try to recompile Python in debug mode?
("make distclean && ./configure --with-pydebug").

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________

From report at bugs.python.org  Fri Mar 12 00:52:32 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 11 Mar 2010 23:52:32 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268351552.64.0.70228767739.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Not so much of a traceback. But essentially the same final error:
running build
running build_py
running build_ext
building 'cobs._cobsext' extension
error: Unable to find vcvarsall.bat

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:10:42 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 00:10:42 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268352642.19.0.414420973545.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

So now it's the domain experts against some hypothetical people that might exist?  Tricky.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:14:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Mar 2010 00:14:24 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268352864.95.0.957156192815.issue8047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, Benjamin pointed out to me that it would be a bad thing if array.tostring produced a string.  True, the method is named wrong, but it is less broken than returning a string.  I suspect that that is the same argument Fredrik is making: that returning the XML as a byte string is less broken than returning it as a string when it in fact may contain other encoded stuff.  The email package has some of the same problems, and there we are retooling the API to deal with this.

Presumably ET needs to have a retooled API for Python3 as well.  Then the question becomes what do we do in the meantime?  For email, we are just living with the breakage until we can get something better in place, because no one has come up with any good short term solutions for email.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:16:25 2010
From: report at bugs.python.org (Jon Buller)
Date: Fri, 12 Mar 2010 00:16:25 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1268349358.96.0.104216068328.issue7424@psf.upfronthosting.co.za>
Message-ID: <4B9987D4.6030809@bullers.net>


Jon Buller <jon at bullers.net> added the comment:

This is bad.  The problem went away and the test completed without the 
segfault.  If you think the output would help track anything down, let 
me know and I'll
save and upload it somewhere.  (Or I could hand out an SSH account via 
IPv6 to the machine...  With some effort, I could probably reconfigure 
my network to get it
on one of my 2 IPv4 addresses.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7424>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:35:34 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 12 Mar 2010 00:35:34 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268354134.03.0.293797624443.issue8047@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hey, can we all try to get along?

For anyone who didn't follow the link to r56841, that was mine (though Christian Heimes provided the basis for much of the patch apart from elementtree), and I wrote at the time:

"""I had to fix a few tests and modules beyond what Christian did, and
invent a few conventions.  E.g. in elementtree, I chose to
write/return Unicode strings whe no encoding is given, but bytes when
an explicit encoding is given."""

I am not a user of elementtree, so this may well have been a mistake -- at the time (in 2007) we were so busy making zillions of tests pass that some mistakes were made.  Some of those were caught in time, others apparently not.

My thinking was that since an XML document looks like text, it should probably be considered text, at least by default.  (There may have been some unittests that appeared to require this -- of course this was probably just the confusion between byte strings and 8-bit text strings inherent in Python 2.)

Regarding backwards compatibility, there are now two backwards compatibility problems: with 2.x, and with 3.1.  It seems we cannot easily be backwards compatible with both (though if someone figures out a way that would be best of course).

If I were to propose an API for returning a Unicode string, I would probably add a new method (e.g. tounicode()) rather than using a "magical" argument (tostring(encoding=str)), but given that that exists in another supposedly-compatible implementation I'm not against it.  Maybe tostring(encoding=None) could also be made to work? That would at least make it *possible* to write code that receives a text object and that works in 3.1 and 3.2 both.  In 2.x I think neither of these should work, and there probably isn't a need -- apps needing full compatibility will just have to refrain from calling tostring() without arguments.

ISTM that the behavior of write() is just fine -- the contents of the file will be correct after all.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:41:06 2010
From: report at bugs.python.org (Vasily Ivanov)
Date: Fri, 12 Mar 2010 00:41:06 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1268354466.26.0.903996206722.issue2531@psf.upfronthosting.co.za>


Changes by Vasily Ivanov <bas at usagebot.com>:


----------
nosy: +bas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Fri Mar 12 01:53:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 00:53:37 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268355217.49.0.850120906422.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are different kind of bugs, but all of them are related to SSL_Shutdown(). It depends on the socket timeout:
 - blocking socket: nothing special (no change from previous OpenSSL version)
 - timeout or non blocking socket: if SSL_shutdown() returns -1 and SSL_get_error()==SSL_ERROR_WANT_READ, we have to read bytes from the socket (to read the "close" notify acknowledge?)

I did't understood how much bytes have to be read, nor if we have to check the socket status using select() or not.

Attached patch is a draft to demonstrate how the bug have to be fixed, but I don't know OpenSSL nor asynchat enough to write a good fix. TODO: unwrap() returns None on SSL_shutdown() error and if the socket has been closed.

----------
keywords: +patch
Added file: http://bugs.python.org/file16527/ssl_shutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:09:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Mar 2010 04:09:06 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1268366946.56.0.708345361149.issue2001@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:42:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 04:42:17 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268368937.77.0.0959094549962.issue8047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not wanting to waste my time anymore on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 05:42:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 04:42:36 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268368956.34.0.360121771323.issue8047@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 07:03:14 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 12 Mar 2010 06:03:14 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268373794.34.0.541118247968.issue8117@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk (r78853), thanks.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Fri Mar 12 07:49:05 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 12 Mar 2010 06:49:05 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268376545.19.0.528228682473.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Hi Guido, your comment was long overdue in this discussion.

Guido van Rossum, 12.03.2010 01:35:
> My thinking was that since an XML document looks like text, it should
> probably be considered text, at least by default.  (There may have
> been some unittests that appeared to require this -- of course this
> was probably just the confusion between byte strings and 8-bit text
> strings inherent in Python 2.)

Well, well, XML...

It does look like text, but it's encoded text that is defined as a stream of bytes, and that's the only safe way of dealing with it.

There certainly *is* a use case for treating the serialised result as text, that's why lxml has this feature. A minor one is for debug output (which certainly doesn't merit being the default), but another one is when dealing with HTML, where encoding information is certainly less well defined and *much* less often seen in the wild. So users tend to be happy when they get their real-world HTML input fixed up into proper Unicode, still happier when they see that lxml can parse that correctly and even serialise the result back into a Unicode string directly, that they can post-process as text if they need to.

However, the main part here is the input, i.e. getting HTML data properly decoded into Unicode. The output part is a lot less important, and it's often easier to let lxml.html do the correct serialisation into bytes with proper encoding meta information, rather than dealing with it yourself.

Those are the two use cases I see for lxml. Their impact on ElementTree is relatively low as it doesn't support *parsing* from a Unicode string, so the most important HTML feature isn't there in the first place. The lack of major use cases in ElementTree is one of the reasons I'm so opposed to making this feature the backwards incompatible default for the output side.


> Regarding backwards compatibility, there are now two backwards
> compatibility problems: with 2.x, and with 3.1.  It seems we cannot
> easily be backwards compatible with both (though if someone figures
> out a way that would be best of course).
> 
> If I were to propose an API for returning a Unicode string, I would
> probably add a new method (e.g. tounicode()) rather than using a
> "magical" argument (tostring(encoding=str)), but given that that
> exists in another supposedly-compatible implementation I'm not
> against it.

Actually, lxml.etree originally had a tounicode() function for this purpose, and I deprecated it in favour of tostring(encoding=unicode) to avoid having a separate interface for this, while staying just as explicit as before.  I'm aware that this wasn't an all-win decision, but I found passing the unicode type to be explicit enough, and separate enough from an encoding /name/ to make it clear what happens. It's certainly less beautiful in Py3, where you write "tostring(encoding=str)".

I still didn't remove the function from the API, but it's been deprecated for years. Reactivating it in lxml.etre, and duplicating it in ET would safe lxml.etree from having to break user code (as "tostring(encoding=str)" could simply continue to work, but disappear from the docs). It wouldn't safe ET-Py3 from breaking backwards compatibility to itself, though.


> Maybe tostring(encoding=None) could also be made to work? That would
> at least make it *possible* to write code that receives a text object
> and that works in 3.1 and 3.2 both.  In 2.x I think neither of these
> should work, and there probably isn't a need -- apps needing full
> compatibility will just have to refrain from calling tostring()
> without arguments.

It could be made to work, and it doesn't even read that bad. I can't imagine anyone using this explicitly to get the default behaviour, although you never know how people put together their keyword argument dicts programmatically. 'None' has always been the documented default for the encoding parameter, so I'm sure there's at least a tiny bit of code that uses it to say "I'm not overriding the default here".

Actually, the encoding has been a keyword-only parameter in lxml.etree for ages, which was ok with the original default and conform with the official ET documentation. So it would be easy to switch here, although not beautiful in the implementation. Same for ElementTree, where the current default None in the signature could simply be replaced by the 'real' default 'us-ascii'. Within the Py3 series, this change would not keep up backwards compatibility either.

So, as a solution, I do prefer separating this feature out into a separate function, so that we can simplify the interface of tostring() into always returning a byte string serialisation, as it always was in ET. The rather distinct use case of serialising to an unencoded text string can well be handled by a tounicode() function.


> ISTM that the behavior of write() is just fine -- the contents of the
> file will be correct after all.

Not according to the Py3.2 dev docs of open():

"""
'encoding' is the name of the encoding used to decode or encode the file. This should only be used in text mode. The default encoding is platform dependent (whatever locale.getpreferredencoding() returns)
"""

So if a users "preferred encoding" is not UTF-8 compatible, then writing out the Unicode serialisation will result in an incorrect XML serialisation, as an XML byte stream without encoding declaration is assumed to be in UTF-8 by specification.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 08:00:59 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 12 Mar 2010 07:00:59 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268377259.28.0.826105602662.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

One more thing: given that many web-frameworks are still not available for Py3 at this time, and that there are still tons of third-party libraries missing on that platform, I would be surprised if there was any ElementTree based XML/HTML processing code written specifically and only for Py3 by now. So I cannot imagine any noticeable body of code being available that relies on this new Py3 feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 09:15:36 2010
From: report at bugs.python.org (Hamed J.I)
Date: Fri, 12 Mar 2010 08:15:36 +0000
Subject: [issue8120] Py_Initialize: Can't initialize system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>


New submission from Hamed J.I <hamed.ji at gmail.com>:

While try to run Python.exe version 3.1 or 3.2 RC2 on
Windows 7 or Windows XP SP2 get the following error:

Py_Initialize: Can't initialize system standard streams
Lookup Error: unknown encoding: cp720

after download and install cp720.py to lib/encodings get the following error:

Py_Initialize: Can't initialize system standard streams
TypeError: 'NoneType' object is not callable

this is while IDLE works fine

----------
components: Installation
messages: 100904
nosy: Hamed.ji
severity: normal
status: open
title: Py_Initialize: Can't initialize system standard streams
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8120>
_______________________________________

From report at bugs.python.org  Fri Mar 12 09:25:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Mar 2010 08:25:09 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268382309.24.0.124855767139.issue8117@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think this change is worth a sentence in the documentation.
"Improved algorithm" is a bit terse.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Fri Mar 12 09:40:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Mar 2010 08:40:49 +0000
Subject: [issue8120] Py_Initialize: Can't initialize system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268383249.03.0.276025955442.issue8120@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

two questions: 
- where did you obtain cp720.py, are you sure it was a python3 version?
- I've never seen a "3.2 RC2" version. Did you mean the py3k branch?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8120>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:00:48 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 09:00:48 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268384448.06.0.254820444753.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

"'None' has always been the documented default for the encoding parameter"

That's probably mostly by accident at least in original ET, but the 1.3 draft docs at effbot.org/elementtree does spell it out explicitly for the 'write' method:

   Output encoding. If omitted or set to None, defaults to US-ASCII.

Not sure I'd consider this text binding in itself, though (even if I'd argue that it's preferred to have the same interpretation of encoding everywhere).

"writing out the Unicode serialisation will result in an incorrect XML serialisation"

I think Guido meant the ElementTree.write method; is that broken too?

The file.write(et.tostring()) issue is probably my most pressing concern here; that's a common use case (e.g. when using "iterparse" to cut pieces from a big document), and the defaults were chosen to increase the chance that this automatically do the right thing for non-ASCII even if the programmer never tests it.  In 3.X, that construct is suddenly dependent on the interpreter's default encoding.

I think I'd prefer old "tostring" behaviour and a separate "tounicode" function, and I'm still not convinced that the latter is required for the XML use case (which implies that maybe it should live in lxml.html for the HTML case, even if it ends up calling the same internal implementation).

Or should that be "tobytes" and "tounicode" to eliminate all ambiguity?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:18:55 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 12 Mar 2010 09:18:55 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268385535.34.0.380424046278.issue8117@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Clarified Misc/NEWS entry and added a paragraph to the documentation on TimedRotatingFileHandler (r78855).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:19:00 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Mar 2010 09:19:00 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268385540.05.0.868937650922.issue8111@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Things getting worse before they get better? http://docs.python.org/ now shows the 2.7a4 documentation, which is really not good. Perhaps we need some safeguards to make sure that http://docs.python.org/ is a *stable* version of the docs? :P

----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:22:20 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Mar 2010 09:22:20 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268385740.12.0.689170363173.issue8111@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Oh, actually, looks like something was redirecting from docs.python.org to docs.python.org/dev. It seems fixed now. (It wasn't just me, though, I got complaints from others that it was 2.7a4 for at least an hour.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:23:35 2010
From: report at bugs.python.org (Hamed J.I)
Date: Fri, 12 Mar 2010 09:23:35 +0000
Subject: [issue8120] Py_Initialize: Can't initialize system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268385815.61.0.176174819188.issue8120@psf.upfronthosting.co.za>


Hamed J.I <hamed.ji at gmail.com> added the comment:

in fact i'm not sure it is compatible with python 3.1
i have download it from 

http://blog.oneortheother.info/tip/python-fix-cp720-encoding/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8120>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:25:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Mar 2010 09:25:11 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268385911.0.0.771152404273.issue8111@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Uh oh. Definitely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:26:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Mar 2010 09:26:20 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268385980.58.0.670354803238.issue8111@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oh, just now saw your second message.  At least it's back to semi-broken now :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:32:45 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Mar 2010 09:32:45 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268386365.04.0.959820508489.issue8111@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:32:54 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Mar 2010 09:32:54 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268386374.01.0.515701211769.issue8111@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:33:40 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Mar 2010 09:33:40 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268386420.31.0.562922140723.issue8111@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Nevermind the 2.7a4 comments, I think I'm just not all awake yet. The complaints I got were about it being 2.6.5c2, my browser showing me 2.7a4 may have been stupid autocompletion or something. (Still, please fix :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:34:49 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 09:34:49 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268386489.58.0.687163201406.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

(what's the Python 3 replacement for the array module, btw?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:38:28 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 12 Mar 2010 09:38:28 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268386708.33.0.879532905928.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

"'None' has always been the documented default for the encoding parameter"

What I meant here was that "help(ET.tostring)" will show you that as the default. Also, in the docs, the signature is "tostring(tree, encoding=None)", so None is the documented default value for the argument, regardless of the internal handling.


> "writing out the Unicode serialisation will result in an incorrect
> XML serialisation"
> I think Guido meant the ElementTree.write method; is that broken too?

Yes, the feature has been implemeted deep down in the _encode() helper function, so it impacts the entire serialiser, not only its API.


> I think I'd prefer old "tostring" behaviour and a separate "tounicode" function, and I'm still not convinced that the latter is required for the XML use case (which implies that maybe it should live in lxml.html for the HTML case, even if it ends up calling the same internal implementation).

I obviously agree that the use case for XML is fable, but that alone doesn't make this a convincing argument to move it into lxml.html when the implementation will stay in lxml.etree anyway. Besides, that's pretty off-topic for this bug tracker.


> Or should that be "tobytes" and "tounicode" to eliminate all ambiguity?

That might be the clean break-all-bridges solution, but I don't think the name tostring() is so inherently broken in Py3 that it needs fixing. It's not "tostr()", for example.

I wouldn't raise much opposition against tobytes() as an alias for tostring(), although that sounds more like duplicating an otherwise simple API.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:42:21 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Fri, 12 Mar 2010 09:42:21 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268386941.08.0.973936258891.issue8117@psf.upfronthosting.co.za>


Yuriy Taraday <yorik.sar at gmail.com> added the comment:

Can this change be included in the 2.6 release?
It's small enough but necessary for our current development.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Fri Mar 12 10:53:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Mar 2010 09:53:25 +0000
Subject: [issue8120] Py_Initialize: Can't initialize system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268387605.89.0.0372665681585.issue8120@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

cp720.py was added a few months ago, and will be available with 3.2.
for the impatient, it's here:
http://svn.python.org/view/python/branches/py3k/Lib/encodings/cp720.py?view=markup

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8120>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:14:08 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 10:14:08 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268388848.19.0.324445722517.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

"Yes, the feature has been implemented deep down in the _encode() helper function, so it impacts the entire serialiser, not only its API"

Ouch.

>>> import locale
>>> locale.getpreferredencoding() == "utf-8"
False
>>> from xml.etree.ElementTree import *
>>> e = Element("tag")
>>> e.text = "hell?"
>>> tostring(e)
'<tag>hell?</tag>'
>>> ElementTree(e).write("out.xml")
>>> tree = parse("out.xml")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python31\lib\xml\etree\ElementTree.py", line 843, in parse
    tree.parse(source, parser)
  File "C:\Python31\lib\xml\etree\ElementTree.py", line 581, in parse
    parser.feed(data)
  File "C:\Python31\lib\xml\etree\ElementTree.py", line 1221, in feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:14:46 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 12 Mar 2010 10:14:46 +0000
Subject: [issue8121] Typo in cStringIO
In-Reply-To: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>
Message-ID: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

There is a malformed string in the module cStringIO.

StringI <--> StringIO


>>> sys.version
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
>>> StringIO.StringIO('123')
<StringIO.StringIO instance at 0x02D230D0>
>>> cStringIO.StringIO('123')
<cStringIO.StringI object at 0x0183ECB0>
>>>

----------
components: None
messages: 100920
nosy: jmfauth
severity: normal
status: open
title: Typo in cStringIO
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8121>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:18:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Mar 2010 10:18:43 +0000
Subject: [issue8121] Typo in cStringIO
In-Reply-To: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>
Message-ID: <1268389123.83.0.284063293274.issue8121@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That name is actually correct.  cStringIO features two different types, depending on whether you call cStringIO.StringIO() with or without an argument.  One is called "StringI", the other "StringO".

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8121>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:22:41 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 10:22:41 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268389361.54.0.405869928108.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

"I wouldn't raise much opposition against tobytes() as an alias for tostring(), although that sounds more like duplicating an otherwise simple API."

Adding an alias would be a way address the 2.X/3.X terminology overlap; string traditionally implies 8-bit in 2.X, and apparently now Unicode in 3.X.  That's likely to cause a lot of confusion for people switching over (and to people writing 3.X documentation, as well; the array module's documentation is an example).

ET isn't the only thing with tostring functionality, of course -- it's  pretty much the standard name for "serialize data structure to byte string for later transmission" -- so it probably wouldn't hurt with a python-dev pronouncement here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:23:17 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 10:23:17 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268389397.9.0.414580988872.issue8047@psf.upfronthosting.co.za>


Changes by Fredrik Lundh <fredrik at effbot.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:25:34 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 10:25:34 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268389534.99.0.307502437906.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

"I wouldn't raise much opposition against tobytes() as an alias for tostring(), although that sounds more like duplicating an otherwise simple API."

Adding an alias would be a way address the 2.X/3.X terminology overlap; string traditionally implies 8-bit in 2.X, and apparently now Unicode in 3.X.  That's likely to cause a lot of confusion for people switching from 2 to 3 (and to people writing 3.X documentation, apparently; the array module's documentation is an example of that).

(And once everyone has switched over, we can deprecate the tostring spelling... :)

ET isn't the only thing with tostring functionality, of course -- it's  pretty much the standard name for "serialize data structure to byte string for later transmission" -- so it probably wouldn't hurt with a python-dev pronouncement here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:27:51 2010
From: report at bugs.python.org (Hamed J.I)
Date: Fri, 12 Mar 2010 10:27:51 +0000
Subject: [issue8120] Py_Initialize: Can't initialize system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268389671.34.0.588999997824.issue8120@psf.upfronthosting.co.za>


Hamed J.I <hamed.ji at gmail.com> added the comment:

Thank you very much

Worked well

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8120>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:56:00 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 12 Mar 2010 10:56:00 +0000
Subject: [issue8117] TimedRotatingFileHandler doesn't rotate log file at
	startup.
In-Reply-To: <1268386941.08.0.973936258891.issue8117@psf.upfronthosting.co.za>
Message-ID: <119781.21321.qm@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> From: Yuriy Taraday <report at bugs.python.org>

> Can this change be included in the 2.6 release?
> It's small enough but necessary for our current 
> development.

I'm sorry, Yuriy, I don't think it can be, as it's an enhancement rather than a bug fix. It does change existing behaviour, and strictly speaking it would break backward compatibility, so I can't merge it into the 2.6 maintenance tree - where no new features are allowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8117>
_______________________________________

From report at bugs.python.org  Fri Mar 12 11:59:18 2010
From: report at bugs.python.org (oliv)
Date: Fri, 12 Mar 2010 10:59:18 +0000
Subject: [issue8122] re.sub doesn't handle properly matches with yes-pattern
	no-pattern
In-Reply-To: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>
Message-ID: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>


New submission from oliv <o_medoc at yahoo.fr>:

Using python 2.6.4 on Arch Linux

The regular expression syntax in python indicate: 

(?(id/name)yes-pattern|no-pattern)
Will try to match with yes-pattern  if the group with given id or name exists, and with no-pattern  if it doesn?t.

I used that functionnality but the code doesn't works anymore:
import re
myre = re.compile('(?P<port>[0-9]+/(tcp|udp))\s+(?P<status>\S+)\s+(?P<service>[a-zA-Z0-9_-]+)\s*(?P<details>.*)')
myre.sub('(?(<details>)\g<details>|\g<service>)',"443/tcp open  ssl      Microsoft IIS SSL")

> The output is:
'(?(<details>)Microsoft IIS SSL|ssl)'
Instead of:
Microsoft IIS SSL

It looks like a bug as it was working earlier...

----------
components: Build
messages: 100926
nosy: oliv
severity: normal
status: open
title: re.sub doesn't handle properly matches with yes-pattern no-pattern
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8122>
_______________________________________

From report at bugs.python.org  Fri Mar 12 12:00:21 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 12 Mar 2010 11:00:21 +0000
Subject: [issue8121] Typo in cStringIO
In-Reply-To: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>
Message-ID: <1268391621.84.0.237581976173.issue8121@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

Wow! I never been aware of this (documentation, dir(), __doc__)
Indeed:

>>> cStringIO.StringIO()
<cStringIO.StringO object at 0x02D94F40>
>>> cStringIO.StringIO('abc')
<cStringIO.StringI object at 0x016DE920>

Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8121>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:03:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Mar 2010 12:03:41 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268395421.82.0.101498267268.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch to merge ElementTree 1.3 in 3.x.

----------
Added file: http://bugs.python.org/file16528/issue6472_upstream_py3k_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:03:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Mar 2010 12:03:59 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268395439.55.0.0925319118239.issue6472@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16192/issue6472_etree_upstream_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:04:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Mar 2010 12:04:06 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268395446.03.0.768402081275.issue6472@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16244/issue6472_etree_upstream_v5a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:24:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Mar 2010 12:24:32 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268396672.96.0.689172417646.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I plan to merge ET 1.3 in the 3.x branch tomorrow (See #6472)
Currently, the patch is consistent with 3.1 behaviour.
It could be changed later, depending on the pronouncement on this compatibility issue.


> Previously, in ElementTree, serialising without an explicit encoding
> was a way to get a byte encoded serialisation without an XML
> declaration header.

Now you can pass keyword argument "xml_declaration=False" to skip the header explicitely.


> xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 9

Now it works better.


~ $ ./python 
Python 3.2a0 (py3k:78865M, Mar 12 2010, 13:05:30) 
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding() == "utf-8"
False
>>> from xml.etree.ElementTree import *
>>> e = Element("tag")
>>> e.text = "hell?"
>>> tostring(e)
'<tag>hell?</tag>'
>>> ElementTree(e).write("out.xml")
>>> tree = parse("out.xml")
>>> dump(tree)
<tag>hell?</tag>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:38:59 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 12:38:59 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268397539.13.0.410271047668.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Interesting.  But isn't the problem with 3.1 that it relies on the standard encoding, which results in code that may or may not work depending on a global platform setting?  Who's doing the encoding in the new version?  And what ends up in the file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:40:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Mar 2010 12:40:30 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268397630.05.0.557789513556.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

>>> tree = parse("out.xml")

Actually the test in my previous message does not prove anything.
locale.getpreferredencoding() returns "UTF-8" != "utf-8".

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 13:52:44 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 12 Mar 2010 12:52:44 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268398364.85.0.872624795642.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Oops :)  Yeah, that was pretty lousy way to show what encoding I was using for that test:

>>> import locale
>>> locale.getpreferredencoding()
'cp1252'
>>>

(Somewhat related, it would be nice if Python actually normalized defaultencoding/preferredencoding to some canonical name for the codec in use, i.e. preferred MIME name or at least IANA; we had a rather nice little bug recently that wouldn't have happened if that had been the case...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 14:00:33 2010
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 12 Mar 2010 13:00:33 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1268398833.51.0.238677747274.issue3445@psf.upfronthosting.co.za>


Russell Keith-Magee <freakboy3742 at gmail.com> added the comment:

As an extra data point: we just hit this problem in Django ticket #13093 (http://code.djangoproject.com/ticket/13093). In our case, a decorator was using wraps(); however, that decorator was breaking when it was used on a class with a __call__ method, because the instance of the class doesn't have a __name__ attribute. 

We've implemented the proposed workaround (i.e., check the attributes that are available and provide that tuple as the assigned argument), but I don't agree that this should be expected behavior. wraps() is used to make a decorated callable look like the callable that is being decorated; if there are different types of callable objects, I would personally expect wraps() to adapt to the differences, not raise an error if it sees anything other than a function. 

True, some attributes (like __doc__) won't always be correct as a result of wrapping on non-vanilla functions -- but then, that's true of plain vanilla functions, too. A decorator wrapping a function can fundamentally change what the wrapped function does, and there's no guarantee that the docstring for the wrapped function will still be correct after decoration.

----------
nosy: +freakboy3742
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:21:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 14:21:53 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268403713.48.0.942228114271.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r78835 (trunk) fixes getpath and includes also a fix for sysconfig which should fix test_executable_with_cwd() of test_subprocess.

Backported as r78868 to the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Fri Mar 12 15:48:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 14:48:07 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268405287.58.0.229405650766.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited to trunk: r78826

Backported to py3k as r78872. But py3k will require extra work: there are some PyErr_Clear() somewhere, eating the errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:04:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 12 Mar 2010 15:04:43 +0000
Subject: [issue8122] re.sub doesn't handle properly matches with yes-pattern
	no-pattern
In-Reply-To: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>
Message-ID: <1268406283.6.0.338583999881.issue8122@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib) -Build
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8122>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:32:09 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 12 Mar 2010 15:32:09 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268407929.44.0.664153032461.issue8047@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I propose that we continue to see Fredrik as elementtree's "BDFL". If Fredrik wants the API in 3.2 to be changed to be backwards compatible with 2.x, we should do that, and damn the torpedoes (um, 3.1 compatibility).

I would do this ASAP; if you can, fix it *before* merging 1.3.

Since I hate XML equally whether it's text or bytes, please leave me out of this in the future; I apologize for having cause the problem in the first place (but note that apparently nobody cared or noticed until a week ago).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:35:58 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 12 Mar 2010 15:35:58 +0000
Subject: [issue8122] re.sub doesn't handle properly matches with yes-pattern
	no-pattern
In-Reply-To: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>
Message-ID: <1268408158.6.0.201544601577.issue8122@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

You can't use (...) syntax in substitution strings, only \N references.

----------
nosy: +gvanrossum
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8122>
_______________________________________

From report at bugs.python.org  Fri Mar 12 16:37:45 2010
From: report at bugs.python.org (Dmitry Jemerov)
Date: Fri, 12 Mar 2010 15:37:45 +0000
Subject: [issue8123] TypeError in urllib when trying to use HTTP authentication
In-Reply-To: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>
Message-ID: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov <intelliyole at gmail.com>:

I'm trying to download a file from a site using HTTP authentication. I'm subclassing FancyURLOpener, returning my credentials from the prompt_user_passwd() method, and using opener.retrieve() to download the file. I get the following error:

  File "C:/JetBrains/IDEA/build/eap/downandup.py", line 36, in download
    opener.retrieve(url, os.path.join(target_path, name))
  File "C:\Python31\lib\urllib\request.py", line 1467, in retrieve
    fp = self.open(url, data)
  File "C:\Python31\lib\urllib\request.py", line 1435, in open
    return getattr(self, name)(url)
  File "C:\Python31\lib\urllib\request.py", line 1609, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "C:\Python31\lib\urllib\request.py", line 1605, in _open_generic_http
    response.status, response.reason, response.msg, data)
  File "C:\Python31\lib\urllib\request.py", line 1621, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "C:\Python31\lib\urllib\request.py", line 1859, in http_error_401
    return getattr(self,name)(url, realm)
  File "C:\Python31\lib\urllib\request.py", line 1931, in retry_http_basic_auth
    return self.open(newurl)
  File "C:\Python31\lib\urllib\request.py", line 1435, in open
    return getattr(self, name)(url)
  File "C:\Python31\lib\urllib\request.py", line 1609, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "C:\Python31\lib\urllib\request.py", line 1571, in _open_generic_http
    auth = base64.b64encode(user_passwd).strip()
  File "C:\Python31\lib\base64.py", line 56, in b64encode
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str

The problem happens because _open_generic_http extracts the user password from the string URL, and passes the string to the b64encode method, which only accepts bytes and not strings. The problem happens with Python 3.1.1 for me, but as far as I can see it's still not fixed in the py3k branch as of now.

----------
components: Library (Lib)
messages: 100938
nosy: Dmitry.Jemerov
severity: normal
status: open
title: TypeError in urllib when trying to use HTTP authentication
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8123>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:08:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 16:08:39 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyFile_WriteString() calls PyObject_Str() which calls PyErr_CheckSignals(). If a signal was catched, the signal handler is called. If the signal handler raises an error, PyObject_Str() and then PyFile_WriteString() return NULL.

mywrite() ignores all PyFile_WriteString() errors. It should maybe only ignores errors from the file (except IOError: ...) and not any error.

Another problem: mywrite() is called from PySys_WriteStdout() and PySys_WriteStderr() which are procedures. PySys_WriteStdout()/PySys_WriteStderr() caller cannot detect the error. There are 65 calls to PySys_WriteStd...

----------
components: Interpreter Core
messages: 100939
nosy: haypo
severity: normal
status: open
title: mywrite() ignores PyFile_WriteString() errors
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:10:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 16:10:19 +0000
Subject: [issue8104] socket.recv_into doesn't support a memoryview as an
	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268410219.28.0.33774991014.issue8104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I suppose recvfrom_into() should also be converted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8104>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:10:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 16:10:17 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1268410217.6.0.552767553318.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Bug related to this issue: #8124, PySys_WriteStdout() and PySys_WriteStderr() ignore signal handlers errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:10:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 16:10:29 +0000
Subject: [issue8124] mywrite() ignores PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1268410229.14.0.883269463811.issue8124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This bug is related to #3137.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8124>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:25:07 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Fri, 12 Mar 2010 16:25:07 +0000
Subject: [issue8125] shutil.copytree behavior is inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>


New submission from joseph.h.garvin <joseph.h.garvin at gmail.com>:

shutil.copyfile's behavior is to replace the dst file if it already exists. shutil.copytree requires that the destination not already exist, and throws an OSError if it does. I see 3 problems with this behavior:

1. It's inconsistent with copyfile

2. It's inconsistent with 'cp', which is what users would be using if they were writing shell script. Given shutil's namesake I assume it's supposed to help make python a viable shell script replacement.

3. It makes it difficult to use copytree with tempfile.mkdtemp(). If I want to make a temporary directory and copy a folder into it, I need to copytree to a nonexist subfolder then move all the files down a level or resort to other unpythonic hacks. In my project I copy unit test resources to a temp folder because they're manipulated throughout the test and I want to keep the originals. I imagine that this is a common use case.

That said, if anyone depended on shutil.copytree failing to test whether or not a folder exists, changing this would break compatibility, so if it can't be changed, maybe a shutil.mergetree would be appropriate.

----------
components: Library (Lib)
messages: 100943
nosy: joseph.h.garvin
severity: normal
status: open
title: shutil.copytree behavior is inconsistent with copyfile
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8125>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:28:12 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Fri, 12 Mar 2010 16:28:12 +0000
Subject: [issue8125] shutil.copytree behavior is inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268411292.09.0.875031472568.issue8125@psf.upfronthosting.co.za>


Changes by joseph.h.garvin <joseph.h.garvin at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8125>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:36:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 16:36:05 +0000
Subject: [issue8125] shutil.copytree behavior is inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268411765.7.0.433244460427.issue8125@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 1. It's inconsistent with copyfile

I think it's ok. When using copyfile you can easily check that the destination file doesn't exist, while with copytree it's harder to do the same for *all* destination files. Therefore it makes sense for copytree to raise an error in this case.

> Given shutil's namesake I assume it's supposed to help make python a viable shell script replacement.

It doesn't mean the semantics have to be exactly the same. Actually, many Python users are under Windows where semantics will be different.

> It makes it difficult to use copytree with tempfile.mkdtemp(). If I want to make a temporary directory and copy a folder into it, I need to copytree to a nonexist subfolder then move all the files down a level or resort to other unpythonic hacks.

I actually don't understand your problem. If you are creating a temporary directory, it is empty so there isn't any risk of hitting an already existing file.

In any case, I don't think your arguments are good enough to warrant breaking compatibility with older versions.

----------
nosy: +pitrou
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8125>
_______________________________________

From report at bugs.python.org  Fri Mar 12 17:37:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 12 Mar 2010 16:37:59 +0000
Subject: [issue8125] shutil.copytree behavior is inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268411879.23.0.738982192198.issue8125@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Also, keep in mind that shutil.copytree is more of an example than the be-all-end-all directory copy function, as stated in both the documentation and source code.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8125>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:01:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 17:01:04 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1268413264.28.0.637395420965.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited unicode_fromformat_U.patch as r78875.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:10:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 17:10:41 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1268413841.37.0.701403023849.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, my ssl_rand_egd_unicode-py3k.patch is complelty broken! It writes a pointer to an object into the "char* path" variable :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:18:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 17:18:23 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1268414303.83.0.546845137477.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

object_pyunicode_asstring-py3k.patch commited as r78876.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Fri Mar 12 18:40:08 2010
From: report at bugs.python.org (Palluat de Besset)
Date: Fri, 12 Mar 2010 17:40:08 +0000
Subject: [issue8126] Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a
	10.6 Mac
In-Reply-To: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>
Message-ID: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>


New submission from Palluat de Besset <marc.palluatdebesset at sophos.com>:

/usr/bin/gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPYTHONFRAMEWORK='"Python"' -o pythonw ./Tools/pythonw.c -I.. -I./../Include ../Python.framework/Versions/3.2/Python
./Tools/pythonw.c:22:19:./Tools/pythonw.c:22:19: error: spawn.h: No such file or directory
 error: spawn.h: No such file or directory
./Tools/pythonw.c:91: error: syntax error before ?*? token./Tools/pythonw.c:91: error: syntax error before ?*? token
./Tools/pythonw.c: In function ?setup_spawnattr?:
./Tools/pythonw.c:95: error: ?cpu_type_t? undeclared (first use in this function)
./Tools/pythonw.c:95: error: (Each undeclared identifier is reported only once
./Tools/pythonw.c:95: error: for each function it appears in.)
./Tools/pythonw.c:95: error: syntax error before ?cpu_types?
./Tools/pythonw.c:101: error: ?spawnattr? undeclared (first use in this function)
./Tools/pythonw.c:122: error: ?cpu_types? undeclared (first use in this function)
./Tools/pythonw.c:122: error: ?CPU_TYPE_X86? undeclared (first use in this function)
./Tools/pythonw.c:142: error: ?POSIX_SPAWN_SETEXEC? undeclared (first use in this function)
./Tools/pythonw.c: In function ?main?:
./Tools/pythonw.c:158: error: ?posix_spawn? undeclared (first use in this function)
./Tools/pythonw.c:159: error: ?posix_spawnattr_t? undeclared (first use in this function)
./Tools/pythonw.c:159: error: syntax error before ?spawnattr?
./Tools/pythonw.c:161: error: ?spawnattr? undeclared (first use in this function)

./Tools/pythonw.c: In function ?setup_spawnattr?:
./Tools/pythonw.c:95: error: ?cpu_type_t? undeclared (first use in this function)
./Tools/pythonw.c:95: error: (Each undeclared identifier is reported only once
./Tools/pythonw.c:95: error: for each function it appears in.)
./Tools/pythonw.c:95: error: syntax error before ?cpu_types?
./Tools/pythonw.c:101: error: ?spawnattr? undeclared (first use in this function)
./Tools/pythonw.c:120: error: ?cpu_types? undeclared (first use in this function)
./Tools/pythonw.c:120: error: ?CPU_TYPE_POWERPC? undeclared (first use in this function)
./Tools/pythonw.c:142: error: ?POSIX_SPAWN_SETEXEC? undeclared (first use in this function)
./Tools/pythonw.c: In function ?main?:
./Tools/pythonw.c:158: error: ?posix_spawn? undeclared (first use in this function)
./Tools/pythonw.c:159: error: ?posix_spawnattr_t? undeclared (first use in this function)
./Tools/pythonw.c:159: error: syntax error before ?spawnattr?
./Tools/pythonw.c:161: error: ?spawnattr? undeclared (first use in this function)
lipo: can't figure out the architecture type of: /var/tmp//cct0zueu.out
make[1]: *** [pythonw] Error 1
make: *** [frameworkinstallapps] Error 2

----------
components: Build
messages: 100949
nosy: mpalluat
severity: normal
status: open
title: Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a 10.6 Mac
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:26:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 12 Mar 2010 18:26:26 +0000
Subject: [issue7997] http://www.python.org/dev/faq/ doesn't seem to explain
	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1268418386.62.0.723990902935.issue7997@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Nitpick: Various occurrences of 2.6.1 in the above should probably be 2.61.
Good catch - I think my brain or fingers are too used to Python's versioning scheme, rather than autoconf's.


Here's a revised set of commands, hopefully fixing that:

$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2
$ tar -jxf autoconf-2.61.tar.bz2
$ pushd autoconf-2.61
$ ./configure --prefix=$HOME/autoconf-2.61
$ make ; make install
$ popd
$ PATH=~/autoconf-2.61/bin:$PATH autoreconf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:28:24 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 12 Mar 2010 18:28:24 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268418504.63.0.798436818942.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r78877

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:47:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Mar 2010 18:47:29 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268419649.66.0.686653545572.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Tarek, r78877 is not the fix I recommended in

http://bugs.python.org/issue8107#msg100858

Are you sure you're more comfortable with the one you committed than the one I suggested?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:51:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 18:51:22 +0000
Subject: [issue8104] socket.recv_into doesn't support a memoryview as an
	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268419882.16.0.288359816099.issue8104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
priority:  -> normal
stage:  -> patch review
type:  -> feature request
Added file: http://bugs.python.org/file16529/recvinto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8104>
_______________________________________

From report at bugs.python.org  Fri Mar 12 19:56:10 2010
From: report at bugs.python.org (tormen)
Date: Fri, 12 Mar 2010 18:56:10 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1268420170.2.0.254676299938.issue5099@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

I ran into the same problem today :(
The patch resolved it :)

BUT:
Could anyone comment on when this patch will or will not live?!

...
As the bug is fairly old and already has duplicates and everyone seems to agree on the issue.
...
Plus it seems easy enough to edit the patch to include the try: / finally: and to incorporate the remove_stderr_debug_decorations() suggestion.

----------
nosy: +tormen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:00:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 12 Mar 2010 19:00:00 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268420400.93.0.963414680299.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This will skip the whole test class if srcdir is not found, removing all tests run in test_build_ext.

Are you sure you want to skip the whole test class if the srcdir is not there for 2.6.5 final ? (we have important tests in there, related to options like inplace etc)

If so, I'll change it like you said (so test_build_ext is completely skipped under some environments).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:02:03 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 12 Mar 2010 19:02:03 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's New
	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

The What's New documentation for Python 3.0 and 3.1 have sections called "Porting to Python 3.0".  It would be great to add a link to the Python wiki page about porting Python to Python 3:

http://wiki.python.org/moin/PortingPythonToPy3k

----------
assignee: georg.brandl
components: Documentation
messages: 100956
nosy: amcnabb, georg.brandl
severity: normal
status: open
title: Add link to PortingPythonToPy3k to What's New documentation
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:03:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 19:03:48 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268420628.17.0.228667627179.issue8110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Florent's patch makes sense to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:05:39 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 12 Mar 2010 19:05:39 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268420739.63.0.507741472352.issue8110@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:13:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 19:13:38 +0000
Subject: [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1268421218.6.0.427472664638.issue4473@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +janssen
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:23:56 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 12 Mar 2010 19:23:56 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268421836.42.0.696454382805.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Victor, I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:35:59 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Mar 2010 19:35:59 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268422559.72.0.192592039952.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Martin,

Can you just double check that the addition of xxmodule.c won't cause problems with the Windows installer.  If it's okay (no problems), please close this bug and we'll keep the fix.

Thanks.

----------
assignee: tarek -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:40:17 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Mar 2010 19:40:17 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268422817.73.0.634805075474.issue8102@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:46:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Mar 2010 19:46:17 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's New
	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268423177.89.0.75153841226.issue8127@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. The page contains bad advice, and shouldn't be recommended in its current form. 

That probably could be fixed, but points to the core problem: in the wiki, anybody can add text, even if it's not properly reviewed.

It would IMO be better if a reviewed and rewritten version of that text was contributed to the documentation directly.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:48:37 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 12 Mar 2010 19:48:37 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268423317.86.0.118445867506.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

What's happening is that the new state returns from SSL_shutdown() are saying, "the shutdown you asked for didn't happen this time, but call me again when you get a chance.  And here is a hint about why it didn't happen, so that if you are sophisticated enough, you can get better information about whether subsequent calls to shutdown() will succeed."

Given the underlying architectures we are dealing with, is it possible to handle this properly?  Basically, what the SSL_shutdown code is saying is that all higher-level event loops should understand an additional kind of event, "shutting down the SSL socket", on a par with "read bytes" and "write bytes".  But our event processing handlers, like asyncore, basically only deal with read and write.  I don't see how to tell them that a "close" operation should turn into a "read" or "write".

We could also think about turning non-blocking sockets into blocking sockets, by adding a time.sleep(0.1) and re-calling SSL_shutdown().  But maybe the right thing to do would be for the write handler in the asyncore loop to catch this, and re-try the write when it gets a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 20:58:44 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Mar 2010 19:58:44 +0000
Subject: [issue7997] http://www.python.org/dev/faq/ doesn't seem to explain
	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1268423924.88.0.486552815452.issue7997@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: georg.brandl -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:05:25 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 12 Mar 2010 20:05:25 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268424325.82.0.845003694504.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I'm not sure this should be handled in ssl.py.
ssl.py correctly raises ERROR_WANT_READ/WRITE if the shutdown operation didn't complete and that's ok.
It should be up to the upper application (in our case asyncore) to deal with that.

Moreover, the patch tries to solve the issue by using a while loop which is *evil* for asynchronous environments (a similar problem is debated in issue 3890).

My suggestion is to modify the SSLConnection.close() method of the test server so that it just "return" in case of ERROR_WANT_READ/WRITE errors without calling the original asyncore's close method since the socket object must remain in the select loop as long as the connection is still around.

A subsequent call to handle_read() and/or handle_write() should not be necessary as they should automatically be called by asyncore on the next poll() loop but I'm not 100% sure about this. 

In both cases I'd say that the only thing needed to be fixed here is the test server.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:10:41 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 12 Mar 2010 20:10:41 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268424641.75.0.865497800273.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Looking at this further, what we're seeing is the trace of an ineffective attempt to handle an exception presumably raised from the FTP code.  Can we see that exception?  What's the actual state of the TCP connection at this point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:18:03 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 12 Mar 2010 20:18:03 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268425083.1.0.160571267021.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I think Giampaolo is right about this not being an ssl.py issue.  Could the exception handling in ftp.py perhaps also be made more sophisticated?  I'd really love to understand what the state of the TCP connection is here.  I'm presuming that it's still open, because otherwise you'd get a different error from OpenSSL.  So what's the error that's triggering this call?  Is it simply that the sender has run out of stuff to send?

Also, I think that asyncore.py is stingy about what information it sends.  At the very least, it could invoke handle_error() with the exception it's handling as an argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:19:56 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 12 Mar 2010 20:19:56 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268425196.67.0.0279992305338.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

And it would be interesting to know why all the SSL module tests don't fail in the same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:48:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Mar 2010 20:48:38 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's New
	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268426918.35.0.876982417185.issue8127@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:50:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Mar 2010 20:50:58 +0000
Subject: [issue8123] TypeError in urllib when trying to use HTTP authentication
In-Reply-To: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>
Message-ID: <1268427058.54.0.511554429283.issue8123@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Could you provide a script (or even better a unittest) to reproduce the problem?

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8123>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:56:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Mar 2010 20:56:45 +0000
Subject: [issue8118] PYTHON_API_VERSION needs to be bumped?
In-Reply-To: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>
Message-ID: <1268427405.57.0.00744258773482.issue8118@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is PYTHON_API_VERSION actually useful right now? It seems to me that we need Martin's ABI stability PEP to be implemented before extension modules can be safely shared between several non-bugfix releases.

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8118>
_______________________________________

From report at bugs.python.org  Fri Mar 12 21:56:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Mar 2010 20:56:46 +0000
Subject: [issue8114] python 2.6.4 installation is not working for the single
	user mode in vista.
In-Reply-To: <1268427406.37.0.715646943783.issue8114@psf.upfronthosting.co.za>
Message-ID: <1268427406.37.0.715646943783.issue8114@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Can you provide more information about what exactly is not working and how to reproduce the problem?

----------
nosy: +brian.curtin, ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8114>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:03:13 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 12 Mar 2010 21:03:13 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's New
	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268427793.84.0.395193732219.issue8127@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

What advice in particular do you consider bad?  I would be happy to submit some changes to the wiki page for anything that's wrong.

I think it would be great to have a reviewed version in the documentation directly, but I think the world needs a little more experience with Python 3 before it could be done well.  In the meantime, I think it's important to get the discussion moving towards finding a set of best practices.  Raising the visibility of the wiki page seems like a great way to encourage participation and to get things moving forward.

Right now, there's no sense of best practices in porting to Python 3, and it's leaving people with the impression that it's too hard and not worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:18:05 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Mar 2010 21:18:05 +0000
Subject: [issue8126] Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a
	10.6 Mac
In-Reply-To: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>
Message-ID: <1268428685.6.0.0502396928308.issue8126@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh -Build
nosy: +ronaldoussoren
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:21:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Mar 2010 21:21:07 +0000
Subject: [issue8126] Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a
	10.6 Mac
In-Reply-To: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>
Message-ID: <1268428867.32.0.454951586757.issue8126@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note: "Python.framework/Versions/3.2/Python".
You appear to be building from py3k (which will become 3.2), and not Python 3.1.2rc2.  There are pending fixes for py3k for OS X framework targeted builds and there is at least one as yet unmerged fix for 3.1.2.  At the moment, building any branch of Python on 10.6 and targeting earlier systems does not work correctly; extension module building should be OK as long as the 10.4u SDK is available and gcc 4.0 is used.  Until that is fixed, if you really need to target 10.3, you should build Python on 10.5 or 10.4, otherwise, build just for 10.6 on 10.6 (to do so you may need to set MACOSX_DEPLOYMENT_TARGET=10.6).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:23:01 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 12 Mar 2010 21:23:01 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's New
	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268428981.38.0.771098079453.issue8127@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

By the way, I just noticed your notes on the wiki page and added a response/question.  It seems that the advice that you consider bad is the official porting story (upgrade to 2.6 and use 2to3).  I agree that it's easier and better to not drop support for 2.4 and 2.5, but this seems to be officially discouraged.  The current content on the What's New page only talks about upgrading to 2.6 and using 2to3.

In any case, most of the current content on the wiki page is about supporting Python 2 and Python 3 simultaneously.  I think this is actually better than the official documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:23:42 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 12 Mar 2010 21:23:42 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268429022.85.0.0577739768002.issue8102@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok so, this file is lost during the installation process only for the Mac OS X install it seems. I need to dig into the Mac OS X build process.

If I "./configure && make && make install" with the 2.6.5rc+ tarball, 
the files are properly copied.

Btw, how do you run the tests exactly Ned ?

$ python2.6 test/regrtest.py -v test_distutils

----------
nosy: +ronaldoussoren
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:31:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Mar 2010 21:31:38 +0000
Subject: [issue8118] PYTHON_API_VERSION needs to be bumped?
In-Reply-To: <1268427405.57.0.00744258773482.issue8118@psf.upfronthosting.co.za>
Message-ID: <4B9AB2B7.2050404@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is PYTHON_API_VERSION actually useful right now? It seems to me that
> we need Martin's ABI stability PEP to be implemented before extension
> modules can be safely shared between several non-bugfix releases.

Today, PYTHON_API_VERSION primarily serves as a check that the extension
you load had been compiled for the Python release that its being loaded
into. We promise ABI stability across bug fix releases for the same
feature release, so yes, it is useful.

The original motivation (allowing to share extensions across feature
releases) was last relevant in the 1.x series, IIRC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8118>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:35:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Mar 2010 21:35:00 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's
	New	documentation
In-Reply-To: <1268427793.84.0.395193732219.issue8127@psf.upfronthosting.co.za>
Message-ID: <4B9AB381.9050006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What advice in particular do you consider bad?  I would be happy to
> submit some changes to the wiki page for anything that's wrong.

See my comments on the page. The first headline is IMO fairly
counter-productive, as it (essentially) suggests that you can't start
supporting 3.x until you can leave 2.5 behind - which for most projects
will still be several years in the future.

> Right now, there's no sense of best practices in porting to Python 3,
> and it's leaving people with the impression that it's too hard and
> not worth it.

Then discuss the page and its contents on the python-porting list.

----------
title: Add link to PortingPythonToPy3k to What's New documentation -> Add link to PortingPythonToPy3k to What's New	documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:41:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Mar 2010 21:41:47 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's
	New	documentation
In-Reply-To: <1268428981.38.0.771098079453.issue8127@psf.upfronthosting.co.za>
Message-ID: <4B9AB517.7080507@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Andrew McNabb wrote:
> Andrew McNabb <amcnabb at mcnabbs.org> added the comment:
> 
> By the way, I just noticed your notes on the wiki page and added a
> response/question.  It seems that the advice that you consider bad is
> the official porting story (upgrade to 2.6 and use 2to3).

No, "drop support for Python older than 2.6" is completely, entirely
different from "upgrade to 2.6".

> I agree
> that it's easier and better to not drop support for 2.4 and 2.5, but
> this seems to be officially discouraged.

Says who?

> In any case, most of the current content on the wiki page is about
> supporting Python 2 and Python 3 simultaneously.  I think this is
> actually better than the official documentation.

If, by "official documentation", you refer to the 3 paragraphs in
"what's new", then I agree that the text could be improved. However,
I completely disagree that your Wiki page is better wrt. to running code
 simultaneously on 2.x and 3.x unmodified.

Your page encourages such a style, and "what's new" discourages,
pointing out that it leads to contorted code. I completely agree that it
does, and the approaches proposed should be the absolute exception in
any porting strategy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 22:43:38 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 12 Mar 2010 21:43:38 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's
	New	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268430218.54.0.0672786038177.issue8127@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

Thanks for your advice.  I just signed up for the python-porting list, and I'll start a discussion there.

I'm trying to improve the wiki page to address your concerns.  There are multiple valid approaches to take, and I'm trying to make the page show this.  I'll remove the inline notes for now (since they clutter things), and I'll try to incorporate your changes.  I apologize in advance if I make any mistakes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:01:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 12 Mar 2010 22:01:44 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268431304.4.0.859565590358.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> I'd really love to understand what the state of the TCP connection 
> is here. I'm presuming that it's still open, because otherwise you'd 
> get a different error from OpenSSL.  So what's the error that's 
> triggering this call?  Is it simply that the sender has run out of 
> stuff to send?

"almost closed"? :)
I don't know but I wouldn't label this as an "unexpected error" because when dealing with non blocking sockets errors like this one are perfectly legitimate as they "tell" the upper application what it is expected to do (for example EWOULDBLOCK on send() means "retry later").

A patch is in attachment but I have not been able to reproduce this issue on python 2.7 r78878 on Ubuntu 8.04 so it might not work (I suspect it might end up in an endless loop).

If this doesn't work we can try the second option of calling handle_read/write right after shutdown().

----------
Added file: http://bugs.python.org/file16530/testftpd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:24:19 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Mar 2010 22:24:19 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268432659.94.0.811961968223.issue8110@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What does the patch achieve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Fri Mar 12 23:49:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Mar 2010 22:49:31 +0000
Subject: [issue8057] Impreciseness in bz2 module documentation?
In-Reply-To: <1267721193.52.0.548079190906.issue8057@psf.upfronthosting.co.za>
Message-ID: <1268434171.67.0.719814477514.issue8057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78884 (py3k) and r78885 (release31-maint), thanks for the report!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8057>
_______________________________________

From report at bugs.python.org  Sat Mar 13 00:24:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 23:24:50 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268436290.95.0.27103784746.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I posted on openssl-users mailing list. The author of patch (change SSL_shutdown() behaviour for non blocking socket) replied!
http://marc.info/?l=openssl-users&m=126838806919896&w=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sat Mar 13 00:42:37 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Fri, 12 Mar 2010 23:42:37 +0000
Subject: [issue8125] shutil.copytree behavior is inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268437357.06.0.473480346435.issue8125@psf.upfronthosting.co.za>


joseph.h.garvin <joseph.h.garvin at gmail.com> added the comment:

Sorry I wasn't terribly clear explaining the problem with mkdtemp. Say you create your temporary folder, /tmp/foo. Now you have a regular folder bar laid out like so:

bar/
  blarg1.ext
  blarg2.ext
  subdir/
    blarg3.ext
    blarg4.ext

I'd like this to be the result of copying:

/tmp
  /foo
    blarg1.ext
    blarg2.ext
    subdir/
      blarg3.ext
      blarg4.ext

Basically, I'd like to copy bar/ to /tmp/foo such that the paths of the files relative to bar/ are the same as the paths of the copied files relative to /tmp/foo. AFAICT there's no easy way to do this with copytree's current behavior. Because tempfile.mkdtemp() creates /tmp/foo to start, you can't use copytree to do this. 

But now I realize copy tree wants to copy the source directory as a directory, so you always get /tmp/foo/bar. What I wanted was copy(recursive_glob(src, "*"), dst). That would give you the effect you normally get from a utility like 'cp'.

> It doesn't mean the semantics have to be exactly the same. Actually, many Python users are under Windows where semantics will be different.

I believe 'copy' has the same cp-like semantics I desire under Windows, but it's been quite some time since I used it.

So, not a bug, but sticks out to me as missing. Might make sense someday to have a keyword arg to copytree that would make it behave this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8125>
_______________________________________

From report at bugs.python.org  Sat Mar 13 01:23:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2010 00:23:59 +0000
Subject: [issue7818] Improve set().test_c_api(): don't expect a set("abc"),
	modify the content
In-Reply-To: <1264907542.03.0.152611089844.issue7818@psf.upfronthosting.co.za>
Message-ID: <1268439839.38.0.950417174779.issue7818@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r78886 (trunk), r78888 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

From report at bugs.python.org  Sat Mar 13 01:24:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2010 00:24:14 +0000
Subject: [issue7818] Improve set().test_c_api(): don't expect a set("abc"),
	modify the content
In-Reply-To: <1264907542.03.0.152611089844.issue7818@psf.upfronthosting.co.za>
Message-ID: <1268439854.8.0.120574130692.issue7818@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

From report at bugs.python.org  Sat Mar 13 02:31:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 01:31:37 +0000
Subject: [issue8011] traceback tb_lineno example needs correction for Python3
In-Reply-To: <1267020758.71.0.873581563668.issue8011@psf.upfronthosting.co.za>
Message-ID: <1268443897.54.0.844271731827.issue8011@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77895 (trunk), r77896 (py3k) and r77897 (release31-maint), thanks for the report!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8011>
_______________________________________

From report at bugs.python.org  Sat Mar 13 03:47:35 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 13 Mar 2010 02:47:35 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

String interpolation % operates on unicode strings directly without calling the __str__ method. In Python 2.5 and 2.6:

>>> class K(unicode):
...     def __str__(self): return "Surprise!"
...
>>> u"%s" % K("some text")
u'some text'

but subclasses of str do call __str__:

>>> class K(str):
...     def __str__(self): return "Surprise!"
...
>>> "%s" % K("some text")
'Surprise!'

In Python 3.1, the above example for subclassing str operates like the unicode example, i.e. it fails to call __str__.

The documentation for string interpolation states that str() is called for all Python objects.

http://docs.python.org/library/stdtypes.html#string-formatting-operations

If the behaviour for unicode (2.5/2.6, str in 3.1) is considered correct, then the documentation should be updated to say that unicode is an exception to the rule. Otherwise the behaviour is incorrect, and it should call __str__ the same as everything else.

----------
messages: 100984
nosy: stevenjd
severity: normal
status: open
title: String interpolation with unicode subclass fails to call __str__
versions: Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Sat Mar 13 03:58:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Mar 2010 02:58:22 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268436290.95.0.27103784746.issue8108@psf.upfronthosting.co.za>
Message-ID: <20100312215756.30c6c413@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I posted on openssl-users mailing list. The author of patch (change
> SSL_shutdown() behaviour for non blocking socket) replied!
> http://marc.info/?l=openssl-users&m=126838806919896&w=2

Interesting read, thank you.
AFAICT, his proposed "quick fix" snippet should be good enough for us.
Also, it seems the new "graceful shutdown" logic is really trying to
handle at the transport level things which should be handled by the
application protocol (detecting whether the other end still has things
to send).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sat Mar 13 04:12:13 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Mar 2010 03:12:13 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268449933.17.0.282187367135.issue8102@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

You are correct: setuptools_build_ext.py should have been there.  It turns out the file was missing in my installer builds due to a combination of issues summarized below.  The bottom line is that this is not a problem for 2.6.5 and my apologies for causing extra work for you, Tarek.  On the plus side, there was some good in all this by causing me to find a couple of serious flaws in my testing process and in the current hg support.

The rest of the story: to manage patches, I use hg on top of svn mirrors of the various source trees.  hg supports use of a top-level .hgignore file to specify files to ignore for revision control.  There is an .hgignore file checked into the svn trees but it turns out to have at least one subtly incorrect entry in it which causes hg to ignore all files with "build" anywhere in their names.  As a result, "setuptools_build_ext.py" has not been carried along into builds in my build process and I haven't noticed it up to now.
   -> After further investigation, I will open a new issue for the faulty .hgignore files.
   -> I'll add some auditing checks to my build process to make sure files aren't being unexpectedly ignored.

For future reference, testing the tests requires an OS X framework build.  The tests themselves are installed into the lib directory of the framework:
{...}Library/Frameworks/Python.framework/Versions/m.n/lib/pythonm.n/distutils/tests/

If you do not want to disturb an existing framework installation (in /Library/Frameworks/Python.frameworks), you can try something like this:

# using the Python-2.6.5rc2 tarball
$ ./configure --enable-framework=/tmp/x/Library/Frameworks && make && make install
#   ... ignore frameworkinstallapps permission errors 
$ cd /tmp/x/Library/Frameworks/Python.framework/Versions/2.6
$ bin/python2.6 -m test.regrtest -v test_distutils
test_distutils
test_build_ext: Cannot find source code (test must run in python build dir)
test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ... ok
test_dont_write_bytecode (distutils.tests.test_build_py.BuildPyTestCase) ... ok
[...]

Due to the problem documented in Issue8107, the rest of the test is skipped.  (In the original report, the OS X installer builds use separate source and build directories and the build directory is usually still around when the tests are run, so the xxconfig.c *was* found and the test suite was attempted resulting in the reported error - another process issue for me.)  If I copy in the two updated files (test_build_ext.py and xxmodule.c) from r78877, test_build_ext now completes as expected:

$ bin/python2.6 -m test.regrtest -v test_distutils
test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ... ok
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_build_ext_inplace (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_build_ext_path_cross_platform (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_build_ext_path_with_os_sep (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_check_extensions_list (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_compiler_option (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_ext_fullpath (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_finalize_options (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_get_source_files (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_setuptools_compat (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_solaris_enable_shared (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_dont_write_bytecode (distutils.tests.test_build_py.BuildPyTestCase) ... ok
[...]

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Sat Mar 13 04:13:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2010 03:13:41 +0000
Subject: [issue8129] Wrong arguments in sqlite3.connect() documentation
In-Reply-To: <1268450021.57.0.736036682608.issue8129@psf.upfronthosting.co.za>
Message-ID: <1268450021.57.0.736036682608.issue8129@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python documentation has the prototype:

sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

http://docs.python.org/library/sqlite3.html#sqlite3.connect

Source code:

 - sqlite.rst: .. function:: connect(database[, timeout, isolation_level, detect_types, factory])
 - connect() documentation: connect(database[, 
timeout, isolation_level, detect_types, factory])
 - module_connect(): char *kwlist[] = {"database", "timeout", "detect_types", "isolation_level", "check_same_thread", "factory", "cached_statements", NULL, NULL};
 - pysqlite_connection_init(): char *kwlist[] = {"database", "timeout", "detect_types", "isolation_level", "check_same_thread", "factory", "cached_statements", NULL, NULL};

module_connect() and pysqlite_connection_init() use the same keyword list, but the documentation invert arguments detect_types and isolation_level, and miss check_same_thread and cached_statements arguments.

--

Example:

>>> import sqlite3
>>> con=sqlite3.connect(':memory:', 2.0, 'DEFER')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> con=sqlite3.connect(':memory:', 2.0, True)
>>> con=sqlite3.connect(':memory:', 2.0, isolation_level='DEFER')

The third argument is a boolean, it's the detect_types option (not the isolation level, a string).

----------
assignee: georg.brandl
components: Documentation
messages: 100987
nosy: georg.brandl, haypo
severity: normal
status: open
title: Wrong arguments in sqlite3.connect() documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8129>
_______________________________________

From report at bugs.python.org  Sat Mar 13 06:25:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 05:25:29 +0000
Subject: [issue6351] Compiler warning in _cursesmodule.c
In-Reply-To: <1246159541.88.0.944376557705.issue6351@psf.upfronthosting.co.za>
Message-ID: <1268457929.15.0.656072820175.issue6351@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This has been fixed in r74051 on trunk and r74054 on py3k.

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6351>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:14:06 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 06:14:06 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1268460846.75.0.891623899674.issue1616@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

After fixing some warning on _cursesmodule.c in r78900 I found this issue and generated an updated list of all the warnings on trunk on the buildbots. When two or more buildbots had the same warnings I grouped them together, showing the url of the buildbot first and then the warnings.

http://www.python.org/dev/buildbot/builders/x86%20XP-4%20trunk
http://www.python.org/dev/buildbot/builders/x86%20XP-5%20trunk
http://www.python.org/dev/buildbot/builders/x86%20Windows7%20trunk
7>..\Objects\bufferobject.c(406) : warning C4018: '<=' : signed/unsigned mismatch
7>..\Modules\zlib\gzio.c(131) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(181) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(226) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(627) : warning C4996: '_vsnprintf': This function or variable may be unsafe. Consider using _vsnprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1001) : warning C4996: 'strerror': This function or variable may be unsafe. Consider using strerror_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1008) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1009) : warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1010) : warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
21>..\Modules\_ctypes\libffi_msvc\ffi.c(113) : warning C4018: '>' : signed/unsigned mismatch
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library

http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20trunk
http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%20trunk
http://www.python.org/dev/buildbot/builders/alpha%20Debian%20trunk
http://www.python.org/dev/buildbot/builders/amd64%20gentoo%20trunk
http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20trunk
http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%20trunk
/home/db3l/buildarea/trunk.bolen-ubuntu/build/./Modules/posixmodule.c:7223: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/home/db3l/buildarea/trunk.bolen-ubuntu/build/./Modules/posixmodule.c:7178: warning: the use of `tempnam' is dangerous, better use `mkstemp'

http://www.python.org/dev/buildbot/builders/ia64%20Ubuntu%20trunk
/home/pybot/buildarea/trunk.klose-debian-ia64/build/./Modules/posixmodule.c:7223: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/home/pybot/buildarea/trunk.klose-debian-ia64/build/./Modules/posixmodule.c:7178: warning: the use of `tempnam' is dangerous, better use `mkstemp'
/home/pybot/buildarea/trunk.klose-debian-ia64/build/Modules/_ctypes/libffi/src/ia64/ffi.c:401: warning: function declaration isn't a prototype

http://www.python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%20trunk
/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_cursesmodule.c:706: warning: implicit declaration of function `mvwchgat'
/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_cursesmodule.c:710: warning: implicit declaration of function `wchgat'

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk
./Modules/posixmodule.c:7225: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp()
./Modules/posixmodule.c:7178: warning: warning: tempnam() possibly used unsafely; consider using mkstemp()
/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Modules/_ssl.c:706: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Modules/_ssl.c:710: warning: passing arg 2 of pointer to function from incompatible pointer type
/usr/local/include/gdbm.h:85: warning: function declaration isn't a prototype
/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Modules/dlmodule.c:189: warning: initialization discards qualifiers from pointer target type
/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Modules/_ctypes/callproc.c:1411: warning: initialization discards qualifiers from pointer target type

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%207.2%20trunk
: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp()
: warning: warning: tempnam() possibly used unsafely; consider using mkstemp()
/usr/home/db3l/buildarea/trunk.bolen-freebsd7/build/Modules/dlmodule.c:189: warning: initialization discards qualifiers from pointer target type
/usr/home/db3l/buildarea/trunk.bolen-freebsd7/build/Modules/_ctypes/callproc.c:1411: warning: initialization discards qualifiers from pointer target type

http://www.python.org/dev/buildbot/builders/x86%20gentoo%20trunk
Modules/posixmodule.c:7223: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
Modules/posixmodule.c:7178: warning: the use of `tempnam' is dangerous, better use `mkstemp'
/home/buildslave/python-trunk/trunk.norwitz-x86/build/Modules/_ssl.c:706: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/home/buildslave/python-trunk/trunk.norwitz-x86/build/Modules/_ssl.c:710: warning: passing arg 2 of pointer to function from incompatible pointer type

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> compile error
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:19:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 06:19:27 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1268461167.39.0.598759706245.issue1616@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

And this is the list for 3.x:

http://www.python.org/dev/buildbot/builders/x86%20XP-4%203.x
http://www.python.org/dev/buildbot/builders/x86%20XP-5%203.x
http://www.python.org/dev/buildbot/builders/x86%20Windows7%203.x
7>..\Modules\zlib\gzio.c(131) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(181) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(226) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(627) : warning C4996: '_vsnprintf': This function or variable may be unsafe. Consider using _vsnprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1001) : warning C4996: 'strerror': This function or variable may be unsafe. Consider using strerror_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1008) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1009) : warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
7>..\Modules\zlib\gzio.c(1010) : warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
19>..\Modules\_ctypes\libffi_msvc\ffi.c(113) : warning C4018: '>' : signed/unsigned mismatch
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library

http://www.python.org/dev/buildbot/builders/x86%20gentoo%203.x
/home/buildslave/python-trunk/3.x.norwitz-x86/build/Modules/_ssl.c:699: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/home/buildslave/python-trunk/3.x.norwitz-x86/build/Modules/_ssl.c:704: warning: passing arg 2 of pointer to function from incompatible pointer type

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%207.2%203.x
/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Modules/_ctypes/callproc.c:1387: warning: initialization discards qualifiers from pointer target type

http://www.python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%203.x
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/sha1module.c:130:1: warning: "FF0" redefined
/usr/include/sys/termios.h:251:1: warning: this is the location of the previous definition
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/sha1module.c:131:1: warning: "FF1" redefined
/usr/include/sys/termios.h:252:1: warning: this is the location of the previous definition
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/_cursesmodule.c:716: warning: implicit declaration of function `mvwchgat'
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/_cursesmodule.c:720: warning: implicit declaration of function `wchgat'
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/_multiprocessing/semaphore.c:436: warning: int format, pid_t arg (arg 4)
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/_ctypes/callproc.c:1086: warning: implicit declaration of function `alloca'
/home2/buildbot/slave/3.x.loewis-sun/build/Modules/_ctypes/stgdict.c:486: warning: implicit declaration of function `alloca'

http://www.python.org/dev/buildbot/builders/ia64%20Ubuntu%203.x
/home/pybot/buildarea/3.x.klose-debian-ia64/build/Modules/_ctypes/libffi/src/ia64/ffi.c:401: warning: function declaration isn't a prototype

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%203.x
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:699: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:704: warning: passing arg 2 of pointer to function from incompatible pointer type
/usr/local/include/gdbm.h:85: warning: function declaration isn't a prototype
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/callproc.c:1387: warning: initialization discards qualifiers from pointer target type

http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x
/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Modules/_pickle.c:4392:9: warning: case value '0' not in enumerated type 'enum opcode'
/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Modules/_csv.c:541:15: warning: operation on 'self->field' may be undefined
/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Modules/_csv.c:1062:14: warning: operation on 'self->rec' may be undefined

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:47:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 06:47:26 +0000
Subject: [issue4498] Compiler warning "signed/unsigned comparion in mmapmodule"
In-Reply-To: <1228254513.06.0.0352568369142.issue4498@psf.upfronthosting.co.za>
Message-ID: <1268462846.63.0.638697032723.issue4498@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That line has been changed in #6344 (see the last message for the revision numbers).
Raymond, do you still have that warning?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4498>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:50:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 06:50:05 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1268463005.05.0.931884736954.issue8128@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Interpreter Core
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Sat Mar 13 07:50:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 06:50:53 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1268463053.12.0.755618131866.issue1616@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There are also a few issues related to compiler warnings:
#7225: about other warnings in object.c, marshal.c, signalmodule.c;
#4500: about other warnings in object.c, marshal.c, main.c;
#4370: about "unknown conversion type character `z' in format" (with patch);
#2973: about the warnings in _ssl.c;
#7463: about a warning in PyDateTime_IMPORT;
#3030: about "_POSIX_C_SOURCE" being redefined on HP-UX;

#1621 might be related too, it has high priority, patches but it's still open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:32:38 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 13 Mar 2010 07:32:38 +0000
Subject: [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Python 3.2a0 (py3k:78205M, Feb 16 2010, 17:32:08)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> e = None
[50279 refs]
>>> e
[50279 refs]
>>> try: raise ValueError
... except ValueError as e: pass
...
[50277 refs]
>>> e
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'e' is not defined
[50277 refs]


Same for 3.1.1. Note how the refcount is going down after the try-except.

----------
components: Interpreter Core
messages: 100993
nosy: scoder
severity: normal
status: open
title: except-as in Py3 eats variables
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8130>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:39:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 07:39:30 +0000
Subject: [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268465970.02.0.687006248779.issue8130@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a not a bug and it's documented: http://docs.python.org/py3k/reference/compound_stmts.html#the-try-statement

The solution is to assign the value to another variable:
>>> try: raise ValueError
... except ValueError as e: exc = e
...
>>> exc
ValueError()
>>> e
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'e' is not defined

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8130>
_______________________________________

From report at bugs.python.org  Sat Mar 13 08:45:09 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 13 Mar 2010 07:45:09 +0000
Subject: [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268466309.71.0.742102170233.issue8130@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I knew that the variable was supposed to go out of scope when leaving the except block, but I wasn't aware that this was supposed to be done using (the equivalent of) a 'del'. Were the side-effects of deleting variables defined outside of the try-except considered negligible at the time? I can't see a warning about that in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8130>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:00:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 08:00:38 +0000
Subject: [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268467238.16.0.748835612336.issue8130@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In this case I don't see much difference between deleting a variable or assigning it to something else.

This code works on both Python 2 and 3:
>>> e = 'test'
>>> try: pass                    # no errors raised here
... except Exception as e: pass  # this is not executed
...
>>> e
'test'

If you do this instead:
>>> e = 'test'
>>> try: raise ValueError        # raise the error
... except Exception as e: pass  # this is executed
...

On both 2.x and 3.x 'e' doesn't refer to 'test' anymore in the moment that the exception is captured by the except, so what happens next to the "new e" is not related to what the "old e" was.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8130>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:45:21 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 13 Mar 2010 08:45:21 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1268469921.01.0.0666805373252.issue8128@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:48:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Mar 2010 08:48:46 +0000
Subject: [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268470126.42.0.215073966719.issue8130@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See also #4617, with some patch.

----------
nosy: +flox
superseder:  -> SyntaxError when free variable name is also an exception target

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8130>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:50:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Mar 2010 08:50:00 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1268470200.56.0.344689967602.issue4617@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16341/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Sat Mar 13 09:50:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Mar 2010 08:50:33 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1268470233.73.0.768904116432.issue4617@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +Interpreter Core
nosy: +flox
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:20:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Mar 2010 09:20:13 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1268472013.67.0.44932012645.issue8128@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:21:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Mar 2010 09:21:31 +0000
Subject: [issue8129] Wrong arguments in sqlite3.connect() documentation
In-Reply-To: <1268450021.57.0.736036682608.issue8129@psf.upfronthosting.co.za>
Message-ID: <1268472091.9.0.277042776876.issue8129@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8129>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:35:50 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 13 Mar 2010 09:35:50 +0000
Subject: [issue8131] Delivery Status Notification (Failure)
In-Reply-To: <0016e6d778afb63ed90481ab4e69@google.com>
Message-ID: <a4f83ee11003130135q676eb9c9k5aa59bc4f1aae829@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

www.google.com/chromebeta/what a browser

---------- Forwarded message ----------
From: "Mail Delivery Subsystem" <mailer-daemon at googlemail.com>
Date: Mar 13, 2010 1:31 AM
Subject: Delivery Status Notification (Failure)
To: <renben77 at gmail.com>

Delivery to the following recipient failed permanently:

    homepagewebsitebrowser at gmail.com

Technical details of permanent failure:
The email account that you tried to reach does not exist. Please try
double-checking the recipient's email address for typos or unnecessary
spaces. Learn more at
http://mail.google.com/support/bin/answer.py?answer=6596

----- Original message -----

Return-Path: <renben77 at gmail.com>
Received-SPF: pass (google.com: domain of renben77 at gmail.com designates
10.216.85.9 as permitted sender) client-ip=10.216.85.9;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
renben77 at gmail.com designates 10.216.85.9 as permitted sender) smtp.mail=
renben77 at gmail.com; dkim=pass header.i=renben77 at gmail.com
Received: from mr.google.com ([10.216.85.9])
       by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666728 (num_hops
= 1);
       Sat, 13 Mar 2010 01:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
       d=gmail.com; s=gamma;
       h=domainkey-signature:mime-version:received:in-reply-to:references
        :date:message-id:subject:from:to:content-type;
       bh=e95TaoJEoSEO0fI8PxX3gWmPAWk7MpFGuxo5WXR7c5s=;
       b=ryAtBQKbrkyqTmY9I7u9+8+TU18Nn0sUpEQdUKNMv9qLD4DcFTgrs5+Cl9yajGzLRR
        blBWEtQT7JePAJSXemEJWH+qwSlpv0j/MHONzSYvtImdpxUAH5m5ROAIb2syRtJ3MsC0
        6Z6VTwMh9+3tlrGMKddmKV0w7EuEVGvWLM1BA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
       d=gmail.com; s=gamma;
       h=mime-version:in-reply-to:references:date:message-id:subject:from:to
        :content-type;
       b=PopzoxmDZC0tp09qENK/OV5l98fQkpgX8A/ZezTstyFIONBDDC6ky9PGrzUk17u1zq
        v1DYZ5TdIpXdC+/hyA9QNW7XfEST/yG7jqSBeVA12Fmly1EZ7VRps+MBCWVBXFyZvnhR
        uihbsR+Wn2fR+8kPZplTiwSfHE/5J0fnA/hyY=
MIME-Version: 1.0
Received: by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666716; Sat,
13
       Mar 2010 01:31:06 -0800 (PST)
In-Reply-To: <a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com>
References: <a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com>
Date: Sat, 13 Mar 2010 01:31:06 -0800
Message-ID: <a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com>
Subject: Fwd: Re: Few tweaks

From: reynaldo bendijo <renben77 at gmail.com>
To: homepagewebsitebrowser at gmail.com
Content-Type: multipart/alternative; boundary=0016e6d778afb50bc50481ab4e58

www.google.com/chromebeta/what a browser

---------- Forwarded message ----------
From: "reynaldo b...

----------
files: unnamed
messages: 100998
nosy: renben
severity: normal
status: open
title: Delivery Status Notification (Failure)
Added file: http://bugs.python.org/file16531/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8131>
_______________________________________
-------------- next part --------------
<p></p>
<p><a href="http://www.google.com/chromebeta/what">www.google.com/chromebeta/what</a> a browser</p>
<p><blockquote type="cite">---------- Forwarded message ----------<br>From: &quot;Mail Delivery Subsystem&quot; &lt;<a href="mailto:mailer-daemon at googlemail.com">mailer-daemon at googlemail.com</a>&gt;<br>Date: Mar 13, 2010 1:31 AM<br>
Subject: Delivery Status Notification (Failure)<br>To:  &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;<br><br>Delivery to the following recipient failed permanently:<br>
<br>
 ?? ?? <a href="mailto:homepagewebsitebrowser at gmail.com">homepagewebsitebrowser at gmail.com</a><br>
<br>
Technical details of permanent failure:<br>
The email account that you tried to reach does not exist. Please try double-checking the recipient&#39;s email address for typos or unnecessary spaces. Learn more at <a href="http://mail.google.com/support/bin/answer.py?answer=6596" target="_blank">http://mail.google.com/support/bin/answer.py?answer=6596</a><br>

<br>
----- Original message -----<br>
<br>
Return-Path: &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;<br>
Received-SPF: pass (<a href="http://google.com" target="_blank">google.com</a>: domain of <a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a> designates 10.216.85.9 as permitted sender) client-ip=10.216.85.9;<br>
Authentication-Results: <a href="http://mr.google.com" target="_blank">mr.google.com</a>; spf=pass (<a href="http://google.com" target="_blank">google.com</a>: domain of <a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a> designates 10.216.85.9 as permitted sender) smtp.mail=<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>; dkim=pass header.i=<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a><br>

Received: from <a href="http://mr.google.com" target="_blank">mr.google.com</a> ([10.216.85.9])<br>
 ?? ?? ?? ??by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666728 (num_hops = 1);<br>
 ?? ?? ?? ??Sat, 13 Mar 2010 01:31:06 -0800 (PST)<br>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;<br>
 ?? ?? ?? ??d=<a href="http://gmail.com" target="_blank">gmail.com</a>; s=gamma;<br>
 ?? ?? ?? ??h=domainkey-signature:mime-version:received:in-reply-to:references<br>
 ?? ?? ?? ?? :date:message-id:subject:from:to:content-type;<br>
 ?? ?? ?? ??bh=e95TaoJEoSEO0fI8PxX3gWmPAWk7MpFGuxo5WXR7c5s=;<br>
 ?? ?? ?? ??b=ryAtBQKbrkyqTmY9I7u9+8+TU18Nn0sUpEQdUKNMv9qLD4DcFTgrs5+Cl9yajGzLRR<br>
 ?? ?? ?? ?? blBWEtQT7JePAJSXemEJWH+qwSlpv0j/MHONzSYvtImdpxUAH5m5ROAIb2syRtJ3MsC0<br>
 ?? ?? ?? ?? 6Z6VTwMh9+3tlrGMKddmKV0w7EuEVGvWLM1BA=<br>
DomainKey-Signature: a=rsa-sha1; c=nofws;<br>
 ?? ?? ?? ??d=<a href="http://gmail.com" target="_blank">gmail.com</a>; s=gamma;<br>
 ?? ?? ?? ??h=mime-version:in-reply-to:references:date:message-id:subject:from:to<br>
 ?? ?? ?? ?? :content-type;<br>
 ?? ?? ?? ??b=PopzoxmDZC0tp09qENK/OV5l98fQkpgX8A/ZezTstyFIONBDDC6ky9PGrzUk17u1zq<br>
 ?? ?? ?? ?? v1DYZ5TdIpXdC+/hyA9QNW7XfEST/yG7jqSBeVA12Fmly1EZ7VRps+MBCWVBXFyZvnhR<br>
 ?? ?? ?? ?? uihbsR+Wn2fR+8kPZplTiwSfHE/5J0fnA/hyY=<br>
MIME-Version: 1.0<br>
Received: by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666716; Sat, 13<br>
 ?? ?? ?? ??Mar 2010 01:31:06 -0800 (PST)<br>
In-Reply-To: &lt;<a href="mailto:a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com">a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com</a>&gt;<br>
References: &lt;<a href="mailto:a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com">a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com</a>&gt;<br>
Date: Sat, 13 Mar 2010 01:31:06 -0800<br>
Message-ID: &lt;<a href="mailto:a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com">a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com</a>&gt;<br>
Subject: Fwd: Re: Few tweaks<br>
<p><font color="#500050">From: reynaldo bendijo &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;</font></p>To: <a href="mailto:homepagewebsitebrowser at gmail.com">homepagewebsitebrowser at gmail.com</a><br>
Content-Type: multipart/alternative; boundary=0016e6d778afb50bc50481ab4e58<br>
<p><font color="#500050"><br><a href="http://www.google.com/chromebeta/what">www.google.com/chromebeta/what</a> a browser<br><br>---------- Forwarded message ----------<br>From: &quot;reynaldo b...</font></p></blockquote>
</p>

From report at bugs.python.org  Sat Mar 13 10:37:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 09:37:19 +0000
Subject: [issue8131] Delivery Status Notification (Failure)
In-Reply-To: <a4f83ee11003130135q676eb9c9k5aa59bc4f1aae829@mail.gmail.com>
Message-ID: <1268473039.88.0.319736331656.issue8131@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8131>
_______________________________________

From report at bugs.python.org  Sat Mar 13 10:51:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 09:51:35 +0000
Subject: [issue7845] complex.__lt__ should return NotImplemented instead of
	raising TypeError
In-Reply-To: <1265205516.08.0.748801363745.issue7845@psf.upfronthosting.co.za>
Message-ID: <1268473895.59.0.823392869937.issue7845@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r78902.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7845>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:41:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 10:41:01 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1268476861.97.0.803621210965.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Benjamin!  test_structmembers.py looks perfect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Sat Mar 13 11:46:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 10:46:11 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1268477171.92.0.0696774344164.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tests for this issue, currently failing on T_INT/T_UINT (internal error), T_LONG/T_ULONG (fails to raise TypeError), T_PYSSIZET (internal error).   The older patch only fixes the T_PYSSIZET failures; I'm working on a fix for the others.

----------
Added file: http://bugs.python.org/file16532/issue8014_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Sat Mar 13 12:43:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 11:43:57 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1268480637.82.0.905238443916.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Internal errors for T_UINT and T_PYSSIZET fixed in r78918.  The fix needs to be backported to the release31-maint branch, but I don't think it's urgent enough to try getting it in between 3.1.2 rc1 and 3.1.2 final.

There's still a problem with testing repeated attribute setting for T_UINT and T_ULONG;  for some reason, the first attempt to set a T_UINT attribute to something invalid correctly produces TypeError, but an immediately following second attempt doesn't raise TypeError---this can be seen by uncommenting the T_UINT and T_ULONG bits in test_bad_assignments.  Am investigating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Sat Mar 13 14:25:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 13:25:11 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1268486711.96.0.896933604241.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed reason for failing tests (there was a bad error check in structmembers.c that compared a return value with (unsigned int)-1 instead of (unsigned long)-1), and re-enabled those tests, in r78920.

Leaving open for the backport to 3.1.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:29:48 2010
From: report at bugs.python.org (grumetz)
Date: Sat, 13 Mar 2010 15:29:48 +0000
Subject: [issue8132] email.header.decode_header makes mistakes
In-Reply-To: <1268494188.38.0.891731205331.issue8132@psf.upfronthosting.co.za>
Message-ID: <1268494188.38.0.891731205331.issue8132@psf.upfronthosting.co.za>


New submission from grumetz <jpgrumetz at free.fr>:

Examples:

s = '=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?=Arobase !'
decode_header(s) --->
[('=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?=Arobase !', None)]
which seems bad...
but
ss ='=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?= Arobase !'
decode_header(ss) --->
[('Accus\xc3\xa9 de r\xc3\xa9ception (affich\xc3\xa9) - ', 'utf-8'), ('Arobase !', None)]
which seems good...

----------
components: Library (Lib)
messages: 101004
nosy: grmtz
severity: normal
status: open
title: email.header.decode_header makes mistakes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8132>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:51:24 2010
From: report at bugs.python.org (Chris Lieb)
Date: Sat, 13 Mar 2010 15:51:24 +0000
Subject: [issue8073] Test fail for sha512
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1268495484.12.0.600825908639.issue8073@psf.upfronthosting.co.za>


Chris Lieb <chris.lieb.hotmail+python at gmail.com> added the comment:

Just for reference, I tried applying all of the patches in the SuSE 11.2 source RPM python-2.6.4.92-3.1.src.rpm from http://software.opensuse.org/search?q=python and rebuilding and retesting, but got the same results as using the vanilla Python 2.6.4 sources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Sat Mar 13 16:56:08 2010
From: report at bugs.python.org (Michael Newman)
Date: Sat, 13 Mar 2010 15:56:08 +0000
Subject: [issue8011] traceback tb_lineno example needs correction for Python3
In-Reply-To: <1267020758.71.0.873581563668.issue8011@psf.upfronthosting.co.za>
Message-ID: <1268495768.57.0.328224029432.issue8011@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

No problem. Please note its actually fixed in r78895 (trunk), r78896 (py3k) and r78897 (release31-maint). Your previous message had the svn revision numbers off by 1000.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8011>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:29:08 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 16:29:08 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268497748.46.0.201641559696.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The patch seems to be trivial. I need review, specially compiling under non-Solaris OS.

I plan to commit this patch to 2.6, 2.7, 3.1 and 3.2.

Must I update "NEWS"?

----------
assignee:  -> jcea
keywords: +needs review, patch
nosy: +jcea
priority:  -> normal
Added file: http://bugs.python.org/file16533/mknod-solaris.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:29:46 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 16:29:46 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268497786.84.0.610265424446.issue3928@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 17:54:50 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 13 Mar 2010 16:54:50 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1268499290.75.0.832978331751.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

distutils from trunk is restored to state before 9 months ago

----------
Added file: http://bugs.python.org/file16534/python-trunk-20100313-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:07:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Mar 2010 17:07:19 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268500039.98.0.809510897401.issue3928@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Compiles fine under Debian stable.
You shouldn't commit to 2.6 until 2.6.5 is released, though. If you want to do so, contact Barry first.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:08:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Mar 2010 17:08:07 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268500087.85.0.939831095126.issue3928@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You do need a NEWS entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 18:18:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 17:18:43 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1268500723.58.0.771907659131.issue3871@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Roumen, I am moving all the new work in distutils into distutils2, and distutils is going to be frozen.

Do you want to work on this feature in distutils2 ? (which is distutils code base before I started to revert things)

Let me know so I mark this issue under "Distutils2"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:09:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Mar 2010 18:09:15 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268503755.54.0.0932533658599.issue8111@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Raising to "release blocker" status to get the changes that fix this and that are already in 2.6 approved by Barry.

The revisions are: r78907, r78914, r78923.

I'm attaching a patch with the collective diff.

In short, these changes mirror those done on the other active branches, which makes sure that all daily builds are done consistently.  Code is added only to the Doc Makefile and the "download documentation" template, both of which are not relevant to the released distribution.  Another rc is definitely not needed.

With these changes in place, we have:
- more consistent daily documentation builds (no longer coupled to the test runs by Neal)
- daily builds suspended for stable branches during the release process
- documentation downloads also for the development builds
- strict separation between released docs and daily updated docs

----------
assignee: georg.brandl -> barry
keywords: +patch
nosy: +barry
priority: high -> release blocker
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16535/26changes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:12:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Mar 2010 18:12:17 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268503937.6.0.540663152213.issue8107@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch in its current form is incomplete: xxmodule.c won't end up on the target system, since msi.py doesn't package it. So that would need to be changed as well.

With the current release26-maint branch, test_distutils now passes, both with xxmodule.c present, and with it being absent. If it is present, test_distutils prints a number of additional output lines, starting with "Creating library ...".

I also agree that the change is too heavy for the 2.6 maintenance release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:28:22 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 18:28:22 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268504902.4.0.242282566891.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok then, I am applying Barry's suggestion right now in release26-maint then

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:47:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 18:47:00 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268506020.22.0.471862908144.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r78935.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Sat Mar 13 19:53:12 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 18:53:12 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268506392.75.0.798416219786.issue8102@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok thanks for the tests Neal.

Martin, do I have to do soemthing in msi.py to see this file included ? (I am looking at msi.py right now and it looks like it has the proper glob, but I want to be 100% sure)

Ronald, what about the Mac OS scripts ?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Sat Mar 13 20:36:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Mar 2010 19:36:18 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268508978.54.0.949661414953.issue8102@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Tarek, in general, if you want a new file in Lib included, create a bug report and assign it to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:02:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 20:02:25 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_issue5604 from test_imp is currently failing on OS X !0.6 (py3k branch), with the following output:

======================================================================
ERROR: test_issue5604 (__main__.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?

----------------------------------------------------------------------


I think this has something to do with the platform automatically
using NFD normalization for filenames.  Here's an interactive session: 

Python 3.2a0 (py3k:78936, Mar 13 2010, 19:42:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, unicodedata
>>> fname = 'test' + b'\xc3\xa4'.decode('utf-8')
>>> with open(fname+'.py', 'w') as file: file.write('a = 1\n')
... 
6
>>> imp.find_module(fname)   # expected this to succeed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named test?
>>> imp.find_module(unicodedata.normalize('NFD', fname))
(<_io.TextIOWrapper name=4 encoding='utf-8'>, 'test?.py', ('.py', 'U', 1))


In contrast, a simple 'open' doesn't seem to care about normalization:

>>> open(fname+'.py')
<_io.TextIOWrapper name='test?.py' encoding='UTF-8'>
[50305 refs]
>>> open(unicodedata.normalize('NFD', fname)+'.py')
<_io.TextIOWrapper name='test?.py' encoding='UTF-8'>
[50305 refs]

----------
messages: 101018
nosy: ezio.melotti, mark.dickinson
severity: normal
status: open
title: test_imp fails on OS X 10.6; filename normalization issue.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:08:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 20:08:11 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268510891.96.0.449003049046.issue8133@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Also affects 3.1.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:18:23 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 20:18:23 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268511503.62.0.463891995083.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, do the final review, ready for commiting.

I have asked about committing to 2.6 in the python-committers mailing list.

----------
stage: patch review -> commit review
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:19:14 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 20:19:14 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268511554.45.0.716647882115.issue3928@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:23:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 20:23:25 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268511805.0.0.404701730711.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, do the final review, ready for commiting.

I have asked about committing to 2.6 in the python-committers mailing list.

----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file16536/mknod-solaris_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:23:54 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 20:23:54 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268511834.79.0.238483852641.issue3928@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file16533/mknod-solaris.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:31:14 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 13 Mar 2010 20:31:14 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268512274.86.0.266781156087.issue3928@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 21:52:54 2010
From: report at bugs.python.org (Dmitry Jemerov)
Date: Sat, 13 Mar 2010 20:52:54 +0000
Subject: [issue8123] TypeError in urllib when trying to use HTTP authentication
In-Reply-To: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>
Message-ID: <1268513574.41.0.284221323241.issue8123@psf.upfronthosting.co.za>


Dmitry Jemerov <intelliyole at gmail.com> added the comment:

from urllib.request import *

opener = FancyURLopener()
opener.retrieve("http://username:password at google.com/index.html", "index.html")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8123>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:02:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 21:02:01 +0000
Subject: [issue8102] test_distutils fails on 2.6.5rc1: "No module named
	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268514121.86.0.517716872341.issue8102@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok I see. Good to know thx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8102>
_______________________________________

From report at bugs.python.org  Sat Mar 13 22:28:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Mar 2010 21:28:20 +0000
Subject: [issue7993] Add IO bandwidth test to ccbench
In-Reply-To: <1266874270.23.0.810643863348.issue7993@psf.upfronthosting.co.za>
Message-ID: <1268515700.61.0.520053609718.issue7993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r78939 (trunk) and r78940 (py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7993>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:11:09 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Sat, 13 Mar 2010 22:11:09 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>


New submission from Greg Jednaszewski <jednaszewski at gmail.com>:

Found on 2.6.2 and 2.6.4:

I expect that printing an uninitialized variable from a defaultdict should work.  In fact it does with old-style string formatting.  However, when you try to do it with new-style string formatting, it raises a KeyError.

>>> import collections
>>> d = collections.defaultdict(int)
>>> "{foo}".format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'foo'
>>> "%(foo)d" % d
'0'

----------
components: Library (Lib)
messages: 101025
nosy: jednaszewski
severity: normal
status: open
title: collections.defaultdict gives KeyError with format()
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:12:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Mar 2010 22:12:44 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268518364.24.0.212841010925.issue8134@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.smith, ezio.melotti
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:24:26 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 13 Mar 2010 22:24:26 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268519066.38.0.154355156751.issue8107@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

So, issue closed right?  Or do you want to keep it bumped down and open for 2.6.6?

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:27:48 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 13 Mar 2010 22:27:48 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268519268.95.0.715394258851.issue3928@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This will not block 2.6.5 but is a candidate for 2.6.6.

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:29:59 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 13 Mar 2010 22:29:59 +0000
Subject: [issue8111] docs.python.org/download.html unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268519399.65.0.379123688267.issue8111@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks Georg!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8111>
_______________________________________

From report at bugs.python.org  Sat Mar 13 23:34:40 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Mar 2010 22:34:40 +0000
Subject: [issue8107] test_distutils fails on Windows in 2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268519680.47.0.209347546196.issue8107@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

No I guess its fine to leave it closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8107>
_______________________________________

From report at bugs.python.org  Sun Mar 14 00:10:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 13 Mar 2010 23:10:46 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268521846.69.0.876787381691.issue8134@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

str.format() does not take a mapping object. You want:

>>> "{0[foo]}".format(d)
'0'

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sun Mar 14 00:46:20 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Sat, 13 Mar 2010 23:46:20 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268523980.89.0.458486904655.issue8134@psf.upfronthosting.co.za>


Greg Jednaszewski <jednaszewski at gmail.com> added the comment:

Oops, thanks.  I should have known that.  However, should this work?  This is what initially led me to file this ticket.  My initial example was a bad one.

>>> from collections import defaultdict
>>> d = defaultdict(int)
>>> d['bar'] += 1
>>> "{bar}".format(**d)
'1'
>>> "{foo}".format(**d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'foo'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sun Mar 14 00:47:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Mar 2010 23:47:33 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268524053.26.0.559992632102.issue8134@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

No, because that's not the behavior of keyword arguments.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sun Mar 14 01:08:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 14 Mar 2010 00:08:25 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268525305.81.0.926247979664.issue7808@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I confirm the leaks in the C code. How do you find them?

I see your point with the weakrefs in the unittest, but I don't see why they are so important. We are creating a GC cycle, yes, but the GC will collect it eventually, beside the reference counters being fooled because the cycle. Are you using a tool to find cycles?

I am committing your patch upstream and I need to understand the rationale :).

Thanks!.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 01:56:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 00:56:46 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268528206.67.0.838580468849.issue7808@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The tool is called regrtest:

~ $ ./python -m test.regrtest -R 2:3: -uall test_bsddb3

Some devs and some buildbots hunt refleaks in the test suite.
Even if the test-related refleaks are not important, they may hide real refleaks in the source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 02:02:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 01:02:59 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268528579.8.0.560893247167.issue7808@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You need a debug build of Python to use -R:
./configure --with-pydebug && make

See also: http://www.python.org/dev/faq/#how-do-i-create-a-debug-build-of-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 02:04:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 01:04:04 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268528644.67.0.0560662552965.issue7808@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> I confirm the leaks in the C code. How do you find them?

I've done it manually, disabling some tests, and running "regrtest -R" repeatedly until I isolate the function which is responsible.
Then I studied the source code, looking for the missing DECREFs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 02:45:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 01:45:23 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1268531123.04.0.425033427328.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Merged in 3.x with r78942 and r78945.

See #8047 for a discussion about the `encoding` argument of the serializer (used for .write() method and tostring() tostringlist() functions).
Currently the output is not encoded by default in 3.1 and 3.x.
It is encoded to ASCII in 2.6 and 2.x.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Sun Mar 14 03:26:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 14 Mar 2010 02:26:28 +0000
Subject: [issue8134] collections.defaultdict gives KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268533588.89.0.653116985423.issue8134@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

See also issue 6081.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8134>
_______________________________________

From report at bugs.python.org  Sun Mar 14 03:49:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Mar 2010 02:49:17 +0000
Subject: [issue8132] email.header.decode_header makes mistakes
In-Reply-To: <1268494188.38.0.891731205331.issue8132@psf.upfronthosting.co.za>
Message-ID: <1268534957.09.0.999696045543.issue8132@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Per the RFC, this is the correct behavior.  An encoded word *must* begin and end either at the field boundary or with whitespace.  So ...?=Arobase, with no whitespace between the = and Arobase, makes your first example into an invalid encoded word, and thus it is returned as if it were plain ASCII.

One could argue that email could be smarter and interpret this string as an encoded word anyway, following the Postel principle (be generous in what you accept), but it currently does not do so, and not doing so is not a bug.

email6 will handle such non-RFC compliant examples better, if all goes well.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8132>
_______________________________________

From report at bugs.python.org  Sun Mar 14 03:53:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 02:53:09 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268535189.99.0.125823094293.issue6081@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Sun Mar 14 07:56:20 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Mar 2010 06:56:20 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1268549780.67.0.0195450850228.issue1652@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

A restore_signals parameter was added in py3k r78946.

I'm leaving this issue open as it needs backporting to 2.7.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:15:30 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 14 Mar 2010 07:15:30 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268550930.19.0.699399542984.issue7808@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have spend a few hours trying to understand the issue deeply, and I have an easier to understand version. It is bigger, but explain the issue good enough to use in a production program.

Please, Florent, review. It pass the leak test.

I rather prefer this patch because the weak references were sort of magic, and this new code actually shows what you should use in production.

If you think the patch is OK, it will be integrated in pybsddb 4.8.4 and then backported for python 2.7.

I also solved an undesired coupling between Replication Manager and Base Replication testsuites.

----------
Added file: http://bugs.python.org/file16537/issue7808_bsddb3_refleak_v2TOv3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 08:18:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 07:18:46 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1268551126.82.0.493180719239.issue6780@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a proof of concept that solves the problem for unicode strings and startswith/endswith.
If during the conversion to Unicode a TypeError is raised (e.g. TypeError: Can't convert 'list' object to str implicitly), the error message is changed to "TypeError: startswith first arg must be str, unicode, or tuple, not list".
If the error is not a TypeError (e.g. a UnicodeDecodeError) the behavior is unchanged.
I haven't tested the patch thoroughly, but if this approach is OK I will prepare a complete patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file16538/issue6780.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:46:37 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:46:37 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1268556397.6.0.438276976101.issue1712522@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I've finally gotten around to a complete analysis of this code. I have a code/test/documentation patch which fixes the issue without any code breakage.

There is another bug in quote which I've found and fixed with this patch: If the 'safe' parameter is unicode, it raises a UnicodeDecodeError.

I have backported all of the 'quote' test cases from Python 3 (which I wrote) to Python 2. This exposed the reported bug as well as the above one. It's good to have a much larger set of test cases to work with. It tests things like all combinations of str/unicode, as well as non-ASCII byte string input and all manner of unicode inputs.

The bugfix itself comes from Python 3 (this has already been approved, over many months, by Guido, so I am hoping a similar change can get pushed through into Python 2 fairly easily). The solution is to add "encoding" and "errors" arguments to 'quote', and have quote encode the unicode string before anything else. 'encoding' defaults to 'utf-8'. So:

>>> quote(u'/El Ni?o/')
'/El%20Ni%C3%B1o/'

which is typically the desired behaviour. (Note that URI syntax does not cover Unicode strings; it merely says to encode them with some encoding, recommended but not required UTF-8, and then percent-encode those.)

With this patch, quote *always* returns a str, even on unicode input. I think that makes sense, because a URI is, by definition, an ASCII string. It could easily be made to return a unicode instead.

The other fix is for 'safe'. If 'safe' is a byte string we don't touch it. But if it is a Unicode string, we throw away all non-ASCII bytes. This means you can't make *characters* safe, only *bytes*, since URIs deal with bytes. In Python 3, we go further and throw away all non-ASCII bytes from 'safe' as well, so you can only make ASCII bytes safe. For this patch, I didn't go that far, for backwards compatibility reasons.

Also updated documentation.

In summary, this patch makes 'quote' fully Unicode compliant. It does not change any existing behaviour which wouldn't previously have thrown an exception, so it can't possibly break any existing code (unless it's relying on the exception being thrown).

(A minor change I made was replacing the line "cachekey = (safe, always_safe)" with "cachekey = safe". This avoids unnecessary work of hashing always_safe and the tuple, since always_safe doesn't change. It doesn't affect the behaviour.)

Note: I've also backported the 'unquote' test cases from Python 3 and found a few more bugs. I'm going to report them separately, with patches.

----------
keywords: +patch
Added file: http://bugs.python.org/file16539/urllib-quote.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712522>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:46:56 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:46:56 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urllib.unquote fails to decode a percent-escape with mixed case. To demonstrate:

>>> unquote("%fc")
'\xfc'
>>> unquote("%FC")
'\xfc'
>>> unquote("%Fc")
'%Fc'
>>> unquote("%fC")
'%fC'

Expected behaviour:

>>> unquote("%Fc")
'\xfc'
>>> unquote("%fC")
'\xfc'

I actually fixed this bug in Python 3, at Guido's request as part of the huge fix to issue 3300. To quote Guido:

> # Maps lowercase and uppercase variants (but not mixed case).
> That sounds like a disaster.  Why would %aa and %AA be correct but
> not %aA and %Aa?  (Even though the old code had the same problem.)

(Indeed, the RFC 3986 allows mixed-case percent escapes.)

I have attached a patch which fixes it simply by removing the dict mapping all lower and uppercase variants to characters, and simply calling int(item[:2], 16). It's slower, but correct. This is the same solution we used in Python 3.

I've also backported a number of test cases from Python 3 which cover this issue, and also legitimate bad percent encoding.

Note: I've also backported the remainder of the 'unquote' test cases from Python 3 but I found another bug, so I will report that separately, with a patch.

----------
components: Library (Lib)
files: urllib-unquote-mixcase.patch
keywords: patch
messages: 101044
nosy: mgiuca
severity: normal
status: open
title: urllib.unquote doesn't decode mixed-case percent escapes
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16540/urllib-unquote-mixcase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:48:23 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:48:23 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The 'unquote' function has some very strange behaviour on Unicode input. My proposed fix will, I am sure, be contentious, because it could change existing behaviour (only on unicode strings), but I think it's worth it for a sane unquote function.

Some historical context: I already reported this bug in Python 3 as http://bugs.python.org/issue3300 (or part of it). We argued for two months. I rewrote the function, and Guido accepted it. The same bugs are present in Python 2, but less urgent since they only affect 'unicode' strings (whereas in Python 3 they affected all strings).

PROBLEM DESCRIPTION

The basic problem is this:
Current behaviour:
>>> urllib.unquote(u"%CE%A3")
u'\xce\xa3'
(or u'??')

Desired behaviour:
>>> urllib.unquote(u"%CE%A3")
'\xce\xa3'
(Which decodes with UTF-8 to u'?')

Basically, if you give unquote a unicode string, it will give you back a unicode string, with all of the percent-escapes decoded with Latin-1. This behaviour was added in r39728. The following line was added:

res[i] = unichr(int(item[:2], 16)) + item[2:]

It takes a percent-escape (e.g., "CE"), converts it to an int (e.g., 0xCE), then calls unichr to form a Unicode character with that codepoint (e.g., u'\u00ce'). That's totally wrong. A URI percent-escape "is used to represent a data octet" [RFC 3986], not a Unicode code point.

I would argue that the result of unquote should always be a str, no matter the input. Since a URI represents a byte sequence, not a character sequence, unquote of a unicode should return a byte string, which the user can then decode as desired.

Note that in Python 3 we didn't have a choice, since all strings are unicode, we used a much more complicated solution. But we also added a function unquote_to_bytes. Python 2's unquote should behave like Python 3's unquote_to_bytes.

PROPOSED SOLUTION

To that end, my proposed solution is simply to encode the input unicode string with UTF-8, which is exactly what Python 3's unquote_to_bytes function does. I have attached a patch which does this. It is thoroughly tested and documented. However, see the discussion of potential problems later.

WHY THE CURRENT BEHAVIOUR IS BAD

I'll also point out that the patch in r39728 which created this problem also added a test case, still there, which demonstrates just how confusing this behaviour is:

r = urllib.unquote(u'br%C3%BCckner_sapporo_20050930.doc')
self.assertEqual(r, u'br\xc3\xbcckner_sapporo_20050930.doc')

This takes a string, clearly meant to be a UTF-8-encoded percent-escaped string for u'br?ckner_sapporo_20050930.doc', and unquotes it. Because of this bug, it is decoded with Latin-1 to the string 'br??ckner_sapporo_20050930.doc'. And this garbled string is *actually the expected output of the test case*!!

Furthermore, this behaviour is very confusing because it breaks equality of ASCII str and unicode objects. Consider:

>>> "%C3%BC" == u"%C3%BC"
True
>>> urllib.unquote("%C3%BC")
'\xc3\xbc'
>>> urllib.unquote(u"%C3%BC")
u'\xc3\xbc'
>>> urllib.unquote("%C3%BC") == urllib.unquote(u"%C3%BC")
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False

Why should the ASCII str object "%C3%BC" encode to one value, while the ASCII unicode object u"%C3%BC" encode to another? The two inputs represent the same string, so they should produce the same output.

POTENTIAL PROBLEMS

The attached patch will not, to my knowledge, affect any calls to unquote with str input. It only changes unicode input. Since this was buggy anyway, I think it's a legitimate fix.

I am, however, concerned about code breakage for existing code which uses unicode strings and depends upon this behaviour. Some use cases:

1. Unquoting a unicode string which is pure ASCII, with pure ASCII percent-escapes. This previously would produce a pure ASCII unicode string, now produces a pure ASCII str. This shouldn't break anything unless some code specifically checks that strings are of type 'unicode' (e.g., the Storm database library).
2. Unquoting a unicode string with pure ASCII percent-escapes, but non-ASCII characters. This previously would preserve all the unescaped characters; they will now be encoded to UTF-8. Technically this should never happen, as URIs are not allowed to contain non-ASCII characters [RFC 3986].
3. Unquoting a unicode string which is pure ASCII, with non-ASCII percent escapes. Some code may rely on the implicit decoding as Latin-1. However, I think it is more likely that existing code would just break, since most URIs are UTF-8 encoded.

TWO SOLUTIONS

Having gone through the problems, I imagine that we may reach the conclusion that it is too dangerous to "fix" this bug. Therefore, I am proposing an alternate solution (which I will attach in a follow-up comment), which is not to change the code at all. Instead, just fix the broken test case and add lots more test cases, and also document this odd behaviour thoroughly, and recommend that the input to unquote be passed as a string, then decoded as desired.

I will call the patches "urllib-unquote-fix" (which fixes the bug, adding lots of test cases and updating the documentation to describe the new behaviour), and "urllib-unquote-explain" (which adds lots of test cases and updates the documentation to describe the existing behaviour in detail).

Please discuss. :)

Note: I've just simultaneously filed another bug (issue #8135) on unquote relating to mixed case percent-escapes. Between them, these two patches include all relevant 'unquote' test cases from Python 3. I've also backported the 'quote' test cases in a patch for issue #1712522.

----------
components: Library (Lib)
files: urllib-unquote-fix.patch
keywords: patch
messages: 101045
nosy: mgiuca
severity: normal
status: open
title: urllib.unquote decodes percent-escapes with Latin-1
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16541/urllib-unquote-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:49:20 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:49:20 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268556560.02.0.618146783943.issue8136@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Alternative patch which fixes test cases and documentation without changing the behaviour.

----------
Added file: http://bugs.python.org/file16542/urllib-unquote-explain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Sun Mar 14 09:58:30 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 14 Mar 2010 08:58:30 +0000
Subject: [issue8137] Missing iso-8859-16 codec in the docs
In-Reply-To: <1268557110.11.0.0736384603908.issue8137@psf.upfronthosting.co.za>
Message-ID: <1268557110.11.0.0736384603908.issue8137@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

The "codecs ? Codec registry and base classes" part of
the documentions (Python 2.6.4, 2.7.a?, 3.1.1) does not
mention the existence of the iso-8859-16 codec.

----------
assignee: georg.brandl
components: Documentation
messages: 101047
nosy: georg.brandl, jmfauth
severity: normal
status: open
title: Missing iso-8859-16 codec in the docs
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8137>
_______________________________________

From report at bugs.python.org  Sun Mar 14 10:55:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Mar 2010 09:55:19 +0000
Subject: [issue8137] Missing iso-8859-16 codec in the docs
In-Reply-To: <1268557110.11.0.0736384603908.issue8137@psf.upfronthosting.co.za>
Message-ID: <1268560519.48.0.934826569832.issue8137@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r78952.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8137>
_______________________________________

From report at bugs.python.org  Sun Mar 14 11:00:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 10:00:21 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1268560821.11.0.730888527023.issue7057@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Since there's no activity on this issue I committed the patch in r78950 (py3k) and r78951 (release31-maint).
I'm leaving the issue open and assigning it to Guilherme because there are still a few thing missing (see previous message).

----------
assignee: ezio.melotti -> gpolo
keywords:  -needs review, patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Sun Mar 14 11:59:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 10:59:42 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268564382.93.0.534990536236.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Currently "tree.write(file)" returns Unicode in 3.1 (and 3.x).
I would propose the following change:

>>> tree.write(file)
#  ==>  encode to ASCII without xml declaration (compatible 2.x)
>>> tree.write(file, encoding="utf-8")
#  ==>  encode to UTF-8 without xml declaration (compatible 2.x + 3.1)
>>> tree.write(file, encoding=False)
#  ==>  output Unicode, without xml declaration (compatible 3.1)

The "xml_declaration" keyword argument can be set to True explicitly.

For compatibility with lxml.etree, "encoding=str" returns the same as "encoding=False".

Functions tostring() and tostringlist() will inherit the same behavior.
This change could be backported to 2.7, because it is backward compatible.

See proposed patch for implementation details.

----------
keywords: +patch
Added file: http://bugs.python.org/file16543/issue8047_etree_encoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sun Mar 14 12:28:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 11:28:22 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1268566102.61.0.198495468382.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The cleanups have been committed in r78719 (trunk) and r78723 (py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sun Mar 14 12:28:39 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 14 Mar 2010 11:28:39 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1268566119.13.0.950955482522.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

That's a funny idea. I like that. +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sun Mar 14 12:52:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Mar 2010 11:52:35 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1268567555.69.0.719750194829.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch:

  - comparisons between a Decimal and float produce a result based
    on the numeric values of the Decimal and float

  - change Decimal.__hash__ so that floats and Decimals with (exactly)
    equal value have the same hash.  This preserves the rule that if
    two objects compare equal then they hash equal.

  - add tests, and update documentation.

Still open:  should this change be forward ported to py3k?  If not, then these comparisons should produce a DeprecationWarning.

----------
Added file: http://bugs.python.org/file16544/issue2531.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:24:24 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 12:24:24 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268569464.97.0.540117951264.issue8136@psf.upfronthosting.co.za>


Changes by Matt Giuca <matt.giuca at gmail.com>:


Removed file: http://bugs.python.org/file16542/urllib-unquote-explain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:25:25 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 12:25:25 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268569525.79.0.877132659651.issue8136@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

New version of "explain" patch -- fixed comment linking to the wrong bug ID -- now links to this bug ID (#8136).

----------
Added file: http://bugs.python.org/file16545/urllib-unquote-explain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:28:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 12:28:11 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268569691.56.0.571520564254.issue8136@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:30:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 12:30:41 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268569841.46.0.163402693484.issue8135@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:31:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 12:31:32 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1268569892.73.0.758865073965.issue1712522@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712522>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:35:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 12:35:15 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1268570115.35.0.116718455202.issue1652@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed an oversight on the switch None ==> -1 which prevents compilation on some buildbot. See r78961.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Sun Mar 14 13:38:19 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 12:38:19 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268570299.84.0.792845751498.issue8135@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> Note: I've also backported the remainder of the 'unquote' test cases
> from Python 3 but I found another bug, so I will report that separately,
> with a patch.

Filed under issue #8136.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Sun Mar 14 15:01:11 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 14 Mar 2010 14:01:11 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1268575271.88.0.736541820964.issue7774@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Sun Mar 14 15:09:48 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 14 Mar 2010 14:09:48 +0000
Subject: [issue7705] libpython2.6.so is not linked correctly on FreeBSD when
	threads are enabled
In-Reply-To: <1263535185.62.0.219430416726.issue7705@psf.upfronthosting.co.za>
Message-ID: <1268575788.59.0.0386084662428.issue7705@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7705>
_______________________________________

From report at bugs.python.org  Sun Mar 14 15:24:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Mar 2010 14:24:58 +0000
Subject: [issue7705] libpython2.6.so is not linked correctly on FreeBSD when
	threads are enabled
In-Reply-To: <1263535185.62.0.219430416726.issue7705@psf.upfronthosting.co.za>
Message-ID: <1268576698.95.0.687331533583.issue7705@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r78962.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7705>
_______________________________________

From report at bugs.python.org  Sun Mar 14 18:26:42 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 14 Mar 2010 17:26:42 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268587602.66.0.982842040601.issue8108@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:08:56 2010
From: report at bugs.python.org (Santiago Gala)
Date: Sun, 14 Mar 2010 18:08:56 +0000
Subject: [issue8138] wsgiref.simple_server.SimpleServer claims to be
	multithreaded
In-Reply-To: <1268590136.32.0.519225445448.issue8138@psf.upfronthosting.co.za>
Message-ID: <1268590136.32.0.519225445448.issue8138@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

In python 2.6, a server created with wsgiref.simple_server.make_server will
claim to be multithreaded and multiprocess through it wsgi environ. See  wsgi.multithread in the browser page after launching

  $ python /usr/lib/python2.6/wsgiref/simple_server.py

The bug is due to the default value in the constructor wsgiref.handlers.SimpleHandler, and it is misleading, as the servier is singlethreaded. It gives problems for any app that wants to change behavior or error on singlethreaded.

The problem can be fixed very simply by patching a "multithreaded=False" argument into the ServerHandler constructor in simple_server.

----------
messages: 101058
nosy: sgala
severity: normal
status: open
title: wsgiref.simple_server.SimpleServer claims to be multithreaded
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8138>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:11:33 2010
From: report at bugs.python.org (Santiago Gala)
Date: Sun, 14 Mar 2010 18:11:33 +0000
Subject: [issue8138] wsgiref.simple_server.SimpleServer claims to be
	multithreaded
In-Reply-To: <1268590136.32.0.519225445448.issue8138@psf.upfronthosting.co.za>
Message-ID: <1268590293.2.0.641368108245.issue8138@psf.upfronthosting.co.za>


Changes by Santiago Gala <sgala at apache.org>:


----------
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8138>
_______________________________________

From report at bugs.python.org  Sun Mar 14 19:56:05 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Mar 2010 18:56:05 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1268500723.58.0.771907659131.issue3871@psf.upfronthosting.co.za>
Message-ID: <4B9D313B.1080100@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Tarek Ziad? wrote:
> Roumen, I am moving all the new work in distutils into distutils2, and distutils is going to be frozen.

Last patch is uploaded as the previous patches  didn't apply cleanly (as 
compiler_obj is restored to compiler and etc.)

> Do you want to work on this feature in distutils2 ? (which is distutils code base before I started to revert things)

Yes.
Also I don't know where is distutils2 repository.

> Let me know so I mark this issue under "Distutils2"

No idea, because I expect Distutils2 to work with python 3+ and this 
patch is not tested(ported) to 3+.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:01:27 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Mar 2010 19:01:27 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268593286.99.0.123501424582.issue3928@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Some questions: 
- why patch don't update  posixmodule.c and remove  defined(HAVE_MAKEDEV) ?
- how is defined HAVE_DEVICE_MACROS in pyconfig.h

About changes in configure.in - I'm not sure that they are correct (more later).

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:11:04 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Mar 2010 19:11:04 +0000
Subject: [issue7705] libpython2.6.so is not linked correctly on FreeBSD when
	threads are enabled
In-Reply-To: <1263535185.62.0.219430416726.issue7705@psf.upfronthosting.co.za>
Message-ID: <1268593864.28.0.202355871682.issue7705@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

the applied patch is not correct - please replace " with '

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7705>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:14:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 14 Mar 2010 19:14:36 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268594076.28.0.985870073625.issue7808@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Jes?s, your patch looks good. I prefer your approach.
My use of the weakrefs was an ugly workaround, I admit.

Maybe the "close()" method in the C module should be in charge of DECREFing the handlers and freeing memory. I did not look further in this direction.

Attached patch is quite the same as yours. I just simplified the "dummy()" handler.

----------
Added file: http://bugs.python.org/file16546/issue7808_bsddb3_refleak_v2TOv3_mod.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:36:16 2010
From: report at bugs.python.org (Bertrand Janin)
Date: Sun, 14 Mar 2010 19:36:16 +0000
Subject: [issue8139] ossaudiodev not initializing its types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>


New submission from Bertrand Janin <tamentis at neopulsar.org>:

With Python 3.1.2-rc1, here is what happens when trying to open a mixer:

    Python 3.1.2rc1 (r312rc1:78737, Mar 14 2010, 15:17:09) 
    [GCC 4.3.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ossaudiodev
    >>> m = ossaudiodev.openmixer()
    >>> m.fileno()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'ossaudiodev.oss_mixer_device' object has no attribute 'fileno'

This seems to be due to the fact that the module does not initialize its types with PyType_Ready(), hence the Mixer type never gets its tp_getattro property from its parent type. I attached a small patch to fix this.

----------
components: Extension Modules
files: ossaudiodev.c.patch
keywords: patch
messages: 101063
nosy: tamentis
severity: normal
status: open
title: ossaudiodev not initializing its types
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16547/ossaudiodev.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8139>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:41:33 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 19:41:33 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

when byte-compiling files in a deb/rpm package distributed e.g. in a Linux distribution, it is sometimes wanted to only touch the files found in the deb/rpm, which can be a subset of the files in a directory. the attached patch now lets compileall accept files as arguments as well and adds the recognition of @<filelist> and @- to expand the arguments with the contents of the file (@- meaning to read for stdin). Is this ok for 2.7, and a port of that to 3.2?

----------
components: Library (Lib)
files: compileall.py.diff
keywords: patch
messages: 101064
nosy: doko
severity: normal
status: open
title: extend compileall to compile single files
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16548/compileall.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:42:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 19:42:20 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268595740.73.0.963861293858.issue8140@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:44:50 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 14 Mar 2010 19:44:50 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268595890.37.0.596719187423.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

> AFAICT, his proposed "quick fix" snippet should be good enough for us.

Depends on what we want.  It just suppresses information that's now available.  What we'd really like is for the caller to recognize that close() can fail, and should be re-tried if it does.  That requires that we signal the error back up and out of the ssl module.  It seems to me that any non-blocking code should recognize this and respect it.

Again, why does this failure only show up in the FTP test?  Why aren't we seeing it elsewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Mar 14 20:44:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Mar 2010 19:44:59 +0000
Subject: [issue8139] ossaudiodev not initializing its types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1268595899.57.0.0598959086018.issue8139@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8139>
_______________________________________

From report at bugs.python.org  Sun Mar 14 21:02:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 14 Mar 2010 20:02:50 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268596970.54.0.0106748268705.issue8108@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> close() can fail

Not close, unwrap() (shutdown()) ;-)

> Again, why does this failure only show up in the FTP test?

Maybe because only the FTP test uses an SSL socket in non blocking mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Sun Mar 14 22:56:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Mar 2010 21:56:32 +0000
Subject: [issue8141] test_asynchat & test_smtplib failures in 2.6 release
	branch
In-Reply-To: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>
Message-ID: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I svn up'd and rebuild the release26-maint branch today on my Mac (MacBook
Pro, OSX 10.5.8).  test_asynchat and test_smtplib both fail with 
unexpected output:

test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbecb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed28> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed50> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbee18> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed50> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedf0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedc8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbecb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedf0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbee40> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])

**********************************************************************


test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54647 at 0x30c2df0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54651 at 0x30c2c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54655 at 0x333fb48> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])

Not sure if this is critical.  Assigning to Barry as the release 
manager and marking as a blocker just in case.

S

----------
assignee: barry
components: Library (Lib)
messages: 101067
nosy: barry, skip.montanaro
priority: release blocker
severity: normal
status: open
title: test_asynchat & test_smtplib failures in 2.6 release branch
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8141>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:26:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Mar 2010 22:26:02 +0000
Subject: [issue8003] Fragile and unexpected error-handling in asyncore
In-Reply-To: <1266948464.33.0.330812797821.issue8003@psf.upfronthosting.co.za>
Message-ID: <1268605562.32.0.12407074661.issue8003@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola, josiah.carlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8003>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:27:19 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 22:27:19 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268605639.29.0.227307021537.issue6949@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

with this patch the following test cases fail. the tests need backports as well. with this patch there's still one test failure, which I do see with db4.7 as well.

will wait for test results on different platforms and then submit to the trunk. the setup.py change should go to the py3k branch as well.

======================================================================
ERROR: test02_DBEnv_dealloc (bsddb.test.test_basics.CrashAndBurn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_basics.py", line 1038, in test02_DBEnv_dealloc
    self.assertRaises(db.DBInvalidArgError, db.DBEnv, ~db.DB_RPCCLIENT)
AttributeError: 'module' object has no attribute 'DB_RPCCLIENT'

======================================================================
ERROR: test01_distributed_transactions (bsddb.test.test_distributed_transactions.DBTxn_distributed)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 53, in setUp
    return self._create_env(must_open_db=True)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 38, in _create_env
    self.db.set_re_len(db.DB_XIDDATASIZE)
AttributeError: 'module' object has no attribute 'DB_XIDDATASIZE'

======================================================================
ERROR: test01_distributed_transactions (bsddb.test.test_distributed_transactions.DBTxn_distributedSYNC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 53, in setUp
    return self._create_env(must_open_db=True)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 38, in _create_env
    self.db.set_re_len(db.DB_XIDDATASIZE)
AttributeError: 'module' object has no attribute 'DB_XIDDATASIZE'
======================================================================
ERROR: test01_distributed_transactions (bsddb.test.test_distributed_transactions.DBTxn_distributed_must_open_db)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 53, in setUp
    return self._create_env(must_open_db=True)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 38, in _create_env
    self.db.set_re_len(db.DB_XIDDATASIZE)
AttributeError: 'module' object has no attribute 'DB_XIDDATASIZE'

======================================================================
ERROR: test01_distributed_transactions (bsddb.test.test_distributed_transactions.DBTxn_distributedSYNC_must_open_db)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 53, in setUp
    return self._create_env(must_open_db=True)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_distributed_transactions.py", line 38, in _create_env
    self.db.set_re_len(db.DB_XIDDATASIZE)
AttributeError: 'module' object has no attribute 'DB_XIDDATASIZE'

----------
nosy: +doko
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file16549/python-support_bdb-4.8-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:27:54 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Mar 2010 22:27:54 +0000
Subject: [issue6768] asyncore file_wrapper leaking file descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1268605674.0.0.845277617918.issue6768@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:28:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Mar 2010 22:28:46 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1268605726.99.0.951540959187.issue6589@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:29:39 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 22:29:39 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268605779.76.0.617404750573.issue6949@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the remaining test failure is

test_bsddb3
Berkeley DB 4.8.24: (August 14, 2009)
Test path prefix:  /tmp/z-test_bsddb3-25705
Exception in thread reader 0:
Traceback (most recent call last):
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/test/test_thread.py", line 306, in readerThread
    rec = dbutils.DeadlockWrap(c.next, max_retries=10)
  File "/home/packages/python/2.6/python2.6-2.6.5~rc2/Lib/bsddb/dbutils.py", line 68, in DeadlockWrap
    return function(*_args, **_kwargs)
DBLockDeadlockError: (-30994, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Sun Mar 14 23:42:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Mar 2010 22:42:28 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268606548.38.0.645242929302.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Depends on what we want.  It just suppresses information that's now
> available.  What we'd really like is for the caller to recognize that
> close() can fail, and should be re-tried if it does.  That requires
> that we signal the error back up and out of the ssl module.  It seems
> to me that any non-blocking code should recognize this and respect it.

Well, first, it will break code which used to work perfectly well (as the failing tests show). That OpenSSL decided to break compatibility in what looks like a minor bugfix release (0.9.8m) doesn't mean we should propagate the breakage.

Second, I'm not an SSL expert, but it's not obvious to me that the application should have to ensure a "complete shutdown" before closing the socket. Often, stateful applicative protocols close their "session" anyway (*) before shutting down the transport layer, so I don't see what this additional precaution can buy (apart from code complication).

(*) for example, FTP has the "QUIT" command

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:25:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Mar 2010 23:25:09 +0000
Subject: [issue8141] test_asynchat & test_smtplib failures in 2.6 release
	branch
In-Reply-To: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>
Message-ID: <1268609109.28.0.775068668428.issue8141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Neither of these problems are new to Python 2.6.5: see Issue7037 (test_asynchat) and Issue7040 (test_smtplib).  They have been fixed in trunk (2.7).  Since both failures existed in previous Python 2.6.x releases, my recommendation is to not treat them as release blockers but it would be good to try to fix them before a subsequent 2.6.6 release.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8141>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:40:05 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 23:40:05 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

opening a report to track issues with the update of the internal libffi copy to 3.0.9.  will commit this update to the trunk, and later to the py3k branch.

----------
assignee: theller
components: ctypes
messages: 101072
nosy: doko, theller
severity: normal
status: open
title: libffi update to 3.0.9
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 15 00:46:55 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 23:46:55 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268610415.29.0.503085971054.issue8142@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
assignee: theller -> doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 15 01:05:23 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 15 Mar 2010 00:05:23 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268611523.98.0.0717255803016.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

> Maybe because only the FTP test uses an SSL socket in non blocking mode.

No, the SSL unit tests also do this.  I think Giampaolo is right, what we're seeing is bad error handling in the FTP test code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Mar 15 01:11:29 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 15 Mar 2010 00:11:29 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268611889.51.0.61208135897.issue8108@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

>> Depends on what we want.  It just suppresses information that's now
>> available.  What we'd really like is for the caller to recognize that
>> close() can fail, and should be re-tried if it does.  That requires
>> that we signal the error back up and out of the ssl module.  It seems
>> to me that any non-blocking code should recognize this and respect it.

> Well, first, it will break code which used to work perfectly well (as > the failing tests show). That OpenSSL decided to break compatibility
> in what looks like a minor bugfix release (0.9.8m) doesn't mean we
> should propagate the breakage.

I admit to being powerfully swayed by this argument.  Of course, you could also say that it exposes bugs in code which hasn't been tested enough.  Again, look at where this stack trace is coming from.  It's a default error handler in code that was written 10 years ago.  Perhaps that code needs more than just a default error handler; perhaps the handler in FTP_TLS should be more sophisticated.

> Second, I'm not an SSL expert, but it's not obvious to me that the
> application should have to ensure a "complete shutdown" before
> closing the socket. Often, stateful applicative protocols close
> their "session" anyway (*) before shutting down the transport layer,
> so I don't see what this additional precaution can buy
> (apart from code complication).

What it buys is the ability for careful code to properly shut down an SSL session when using non-blocking sockets.  If we apply the fix, we deny that, and I'm sure someone will immediately file a bug about it :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:06:49 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:06:49 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urlparse contains a complete copy of the urllib.unquote function. This is extremely nasty code duplication -- I have two patches pending on urllib.unquote (#8135 and #8136) and I only just realised that I missed urlparse.unquote!

The reason given for this is:
"Cannot use directly from urllib as it would create circular reference.
urllib uses urlparse methods ( urljoin)"

I don't see that as a reason for code duplication. The fix is to make a local import of unquote in parse_qsl, like this:

def parse_qsl(qs, keep_blank_values=0, strict_parsing=0):
    from urllib import unquote

I am aware that this possibly violates PEP 8 (all imports should be at the top of the module), but I'd say this is the lesser of two evils.

A patch is attached. Commit log: "urlparse: Removed duplicate of urllib.unquote. Replaced with a local import."

----------
components: Library (Lib)
files: urlparse-unquote.patch
keywords: patch
messages: 101075
nosy: mgiuca
severity: normal
status: open
title: urlparse has a duplicate of urllib.unquote
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16550/urlparse-unquote.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:08:31 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:08:31 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268615311.52.0.950778021057.issue8135@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Oh, I just discovered that urlparse contains a copy of unquote, which will also need to be patched. I've submitted a patch to remove the duplicate (#8143) -- if that is accepted first then there's no need to worry about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:09:33 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:09:33 +0000
Subject: [issue8136] urllib.unquote decodes percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268615373.64.0.0830630579904.issue8136@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Oh, I just discovered that urlparse contains a copy of unquote, which will also need to be patched. I've submitted a patch to remove the duplicate (#8143) -- if that is accepted first then there's no need to worry about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8136>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:10:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Mar 2010 01:10:15 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268615415.95.0.519390268052.issue8143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:51:06 2010
From: report at bugs.python.org (brandon)
Date: Mon, 15 Mar 2010 01:51:06 +0000
Subject: [issue8144] muliprocessing shutdown infinite loop
In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>
Message-ID: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>


New submission from brandon <drraid at gmail.com>:

Multiprocessing goes into an infinite loop during shutdown, trying to connect to a remote queue - I *think* during finalization. 

The actual loop appears to be the while(1) in connection.py line 251, and I think it is being called initially from manager.py finalization.

I can reliably reproduce but my code base is large and ugly, and I am still trimming down to a nice clean sample to submit.

----------
messages: 101078
nosy: drraid
severity: normal
status: open
title: muliprocessing shutdown infinite loop
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8144>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:52:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 15 Mar 2010 01:52:26 +0000
Subject: [issue8144] muliprocessing shutdown infinite loop
In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>
Message-ID: <1268617946.89.0.344578724421.issue8144@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8144>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:54:08 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:54:08 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268618048.55.0.65273737297.issue8135@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I thought more about it, and wrote a different patch which doesn't remove the dictionary. I just replaced the dictionary creation code -- now it includes keys for all combinations of upper and lower case (for two-letter hex codes). This dictionary isn't much bigger -- 484 entries where is previously had 412.

Therefore, here is a replacement patch (urllib-unquote-mixcase.patch2).

----------
Added file: http://bugs.python.org/file16551/urllib-unquote-mixcase.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:56:48 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:56:48 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268618208.02.0.232932123286.issue8135@psf.upfronthosting.co.za>


Changes by Matt Giuca <matt.giuca at gmail.com>:


Removed file: http://bugs.python.org/file16551/urllib-unquote-mixcase.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 02:58:29 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:58:29 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268618309.35.0.17530740868.issue8135@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Tiny fix to patch2 -- replaced list comprehension with generator expression in dictionary construction.

----------
Added file: http://bugs.python.org/file16552/urllib-unquote-mixcase.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:01:41 2010
From: report at bugs.python.org (brandon)
Date: Mon, 15 Mar 2010 02:01:41 +0000
Subject: [issue8144] muliprocessing shutdown infinite loop
In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>
Message-ID: <1268618501.99.0.949159087587.issue8144@psf.upfronthosting.co.za>


brandon <drraid at gmail.com> added the comment:

After getting into the infinite loop, here's exception from CTRL-C (posted just to show stack trace -- i am still working on getting come sample code together -- meant to show it is infact in that while(1) a 251 in connection.py):

KeyboardInterrupt
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 260, in _exit_function
    _run_finalizers(0)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 235, in _run_finalizers
    finalizer()
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/managers.py", line 773, in _decref
    conn = _Client(token.address, authkey=authkey)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/connection.py", line 134, in Client
    c = SocketClient(address)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/connection.py", line 258, in SocketClient
    time.sleep(0.01)
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 260, in _exit_function
    _run_finalizers(0)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 235, in _run_finalizers
    finalizer()
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/util.py", line 174, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/managers.py", line 773, in _decref
    conn = _Client(token.address, authkey=authkey)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/connection.py", line 134, in Client
    c = SocketClient(address)
  File "/home/drraid/code/fuzzer/fuzznet/multiprocessing/connection.py", line 258, in SocketClient
    time.sleep(0.01)
KeyboardInterrupt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8144>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:20:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 15 Mar 2010 02:20:24 +0000
Subject: [issue8123] TypeError in urllib when trying to use HTTP authentication
In-Reply-To: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>
Message-ID: <1268619624.46.0.717175298887.issue8123@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, that seems to be case. When username:password is present in the url string, opener bytes string not being passed to the base64encode function.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8123>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:26:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Mar 2010 02:26:42 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268620002.05.0.258164784357.issue8143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly, the problem with doing an import in a function is that there is an import lock which can cause various problem depending on how an application imports various things.  I've added Brett to the nosy list to see if he has a definitive opinion on this.

Note that this code is not duplicated in the py3 codebase.  It is probably best to just live with the code duplication in 2.7.  People may be importing unquote from the "wrong" module, and removing it would break their code.

----------
nosy: +brett.cannon, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:34:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 15 Mar 2010 02:34:34 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268620474.79.0.0600040627441.issue8143@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, the reason for having the unquote verbatim was it created a circular reference otherwise. This was done when parse_qsl was moved from cgi module to the urlparse module. I would also like to know more on what RDM points out, tough I have seem some modules having local imports.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:35:29 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 15 Mar 2010 02:35:29 +0000
Subject: [issue8141] test_asynchat & test_smtplib failures in 2.6 release
	branch
In-Reply-To: <1268609109.28.0.775068668428.issue8141@psf.upfronthosting.co.za>
Message-ID: <19357.40168.674348.891701@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Ned> Neither of these problems are new to Python 2.6.5: see Issue7037
    Ned> (test_asynchat) and Issue7040 (test_smtplib).

Thanks.  I searched for "asynchat" and "smtplib" but didn't see anything.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8141>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:36:12 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 15 Mar 2010 02:36:12 +0000
Subject: [issue8141] test_asynchat & test_smtplib failures in 2.6 release
	branch
In-Reply-To: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>
Message-ID: <1268620572.26.0.375870569126.issue8141@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8141>
_______________________________________

From report at bugs.python.org  Mon Mar 15 03:56:09 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 02:56:09 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268621769.03.0.498517170795.issue8143@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

If this patch is rejected, then at the very least, the urllib.unquote function needs a comment at the top explaining that it is duplicated in urlparse, so any changes should be made to both.

Note that urlparse.unquote is not a documented function, or in the __all__ export list, so people *shouldn't* be using it. But OK, I'll accept that some might.

If there is a problem with some kind of race condition importing (I don't see how there could be, but I'll accept it if someone confirms), or with people using urlparse.unquote directly, then I'd propose an alternate solution which removes the circular dependency entirely: Move unquote into a separate module _urlunquote, which is imported by both urllib and urlparse. No code breakage.

Patch attached. Commit log: "Fixed duplication of urllib.unquote in urlparse. Moved function to a separate module _urlunquote."

----------
Added file: http://bugs.python.org/file16553/urlparse-unquote-newmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Mon Mar 15 05:23:50 2010
From: report at bugs.python.org (Tom Loredo)
Date: Mon, 15 Mar 2010 04:23:50 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268627030.68.0.54029999058.issue8089@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

Attempted to build 2.6.5rc2 on Mac Pro (2006), OS 10.6.2, following instructions in Mac/README:

./configure --prefix=/usr/local/tmp --enable-framework --with-universal-archs=intel --enable-universalsdk=/

Results of "make test" are as expected from past experience (but what architecture is being tested?):

332 tests OK.
2 tests failed:
    test_asynchat test_smtplib
32 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_curses test_dl test_epoll test_gl
    test_imageop test_imgfile test_largefile test_linuxaudiodev
    test_normalization test_ossaudiodev test_pep277 test_py3kwarn
    test_smtpnet test_socketserver test_startfile test_sunaudiodev
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_zipfile64
1 skip unexpected on darwin:
    test_dl

Notably, test_tcl passes without incident.

Running the following within the installation directory runs the 64-bit pre-installation executable (judging by sys.maxint):

$ DYLD_FRAMEWORK_PATH=`pwd`: python.exe

Thus I presume it is the 64-bit version being run by "make test".

The installed IDLE still has the Tk new window freeze issue; sys.maxint indicates it's the 32-bit version that is running when launcing IDLE.  I have a setup.py patch that will detect a 32-bit 10.6 installation and link against Apple's Tcl/Tk-8.4 compatibility version if the user hasn't
installed their own Tcl/Tk frameworks, but it's an ugly hack and I'm not sure this is desirable; we should probably just encourage installing newer Tcl/Tk.  The hack does produce a working 32-bit IDLE, however.

Running "python" on the command line runs the 32-bit version; is this intended?  I think the default behavior for universal builds should be documented in the Mac/README, or at some location pointed to in the README.

I still see no way to access the two architectures.  My ./configure installs command line executables in /usr/local/tmp/bin, a non-existing directory before the install.  After installation, its contents are:

idle@             pydoc2.6@         python2.6@        pythonw2.6@
idle2.6@          python@           python2.6-config@ smtpd.py@
pydoc@            python-config@    pythonw@          smtpd2.6.py@

I was expecting something along the lines of python-32 and/or python-64 to be here; what is the intended mechanism for accessing the two architectures?

$ arch -i386 python
gives me the (default) 32-bit version.

$ arch -x86_64 python
arch: posix_spawnp: python: Bad CPU type in executable

Whereas before with a universal install like this I was getting a 64-bit default and no way to access 32-bit (IIRC), now I appear to be in the reverse scenario.

Is there an error in my build process, or is there still an installation bug for dual-architecture Intel installs?

----------
nosy: +tloredo
type:  -> behavior
versions: +Python 2.6 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 06:13:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Mar 2010 05:13:18 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268629998.46.0.710840447719.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

You need to run 'make install'.  The various "python-32" and "python-64" files are created and installed by the Mac/Makefile "install_python4way" target which should be getting called by the main Makefile "install" target as set by configure for the --with-universal-archs=intel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 09:56:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 15 Mar 2010 08:56:53 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268643413.2.0.485527255658.issue8135@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I reviewed the patch:

+_hexdig = '0123456789ABCDEFabcdef'
+_hextochr = dict((a+b, chr(int(a+b,16))) for a in _hexdig for b in _hexdig)

is really a neat way to generate the dict of mixed-case percent escape to use with to unquote. I shall commit the patch to trunk code.

yes, following the other bug on unquote and we should be able to fair conclusion on it and include this logic in there.

Thanks.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:01:45 2010
From: report at bugs.python.org (Laszlo Nagy)
Date: Mon, 15 Mar 2010 09:01:45 +0000
Subject: [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>


New submission from Laszlo Nagy <nagylzs at gmail.com>:

Clarify what isolation_level does, and how to use it, and why connections do not commit/rollback in some cases.

Details here:

http://mail.python.org/pipermail/python-list/2010-March/1239374.html

I'll paste code for ctx_manager_2.py here. This is a new file, I could not include it as a diff:

import sqlite3

class MyConn(sqlite3.Connection):
    def __enter__(self):
        self.execute("BEGIN")
        return self
    def __exit__(self,exc_type,exc_info,traceback):
        if exc_type is None:
            self.execute("COMMIT")
        else:
            self.execute("ROLLBACK")


conn = sqlite3.connect(':memory:',factory=MyConn)
conn.isolation_level = None
with conn:
    conn.execute("create table a ( i integer ) ")
    conn.execute("insert into a values (1)")
try:
    with conn:
        conn.execute("insert into a values (2)")
        conn.execute("savepoint sp1")
        conn.execute("insert into a values (3)")
        conn.execute("rollback to sp1")
        conn.execute("insert into a values (4)")
        print "Before rollback: 1,2,4"
        for row in conn.execute("select * from a"):
            print row[0] # prints 1,2,4
        raise Exception
except:
    pass
print "After rollback: 1"
for row in conn.execute("select * from a"):
    print row[0] # prints 1

----------
assignee: georg.brandl
components: Documentation
files: sqlite3.rst.diff
keywords: patch
messages: 101090
nosy: georg.brandl, nagylzs
severity: normal
status: open
title: Documentation about sqlite3 isolation_level
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file16554/sqlite3.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8145>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:03:54 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 15 Mar 2010 09:03:54 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268643834.15.0.497324446026.issue6081@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:06:57 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 09:06:57 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268644017.47.0.597024325279.issue8135@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Thanks very much. Importantly, note that unquote is currently duplicated between urllib and urlparse. I have a bug on it (#8143) but in the meantime, you will have to commit this fix to both modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 15 10:58:19 2010
From: report at bugs.python.org (Palluat de Besset)
Date: Mon, 15 Mar 2010 09:58:19 +0000
Subject: [issue8126] Python 3.1.2rc1 doesn't compile using the 10.4 sdk on
	a	10.6 Mac
In-Reply-To: <1268428867.32.0.454951586757.issue8126@psf.upfronthosting.co.za>
Message-ID: <131BEA76-4885-441A-897A-B7963D476405@Sophos.com>


Palluat de Besset <marc.palluatdebesset at sophos.com> added the comment:

Yes, sorry for the confusion. I'm trying to build a universal 32 bit version of Python that will be embedded in our software. we need it to run on 10.4 to 10.6 Mac systems, and would like to build it on a 10.6 machine. I've been trying with several versions of Python to try to achieve that ; version 3.1.1, version 3.1.2rc1 and py3k. None of these version would build a 10.4 compatible universal 32 bit on our 10.6 build machine. This is why I raised an issue.

Thanks,

Marc

On 12 Mar 2010, at 21:21, Ned Deily wrote:

Ned Deily <nad at acm.org<mailto:nad at acm.org>> added the comment:

Note: "Python.framework/Versions/3.2/Python".
You appear to be building from py3k (which will become 3.2), and not Python 3.1.2rc2.  There are pending fixes for py3k for OS X framework targeted builds and there is at least one as yet unmerged fix for 3.1.2.  At the moment, building any branch of Python on 10.6 and targeting earlier systems does not work correctly; extension module building should be OK as long as the 10.4u SDK is available and gcc 4.0 is used.  Until that is fixed, if you really need to target 10.3, you should build Python on 10.5 or 10.4, otherwise, build just for 10.6 on 10.6 (to do so you may need to set MACOSX_DEPLOYMENT_TARGET=10.6).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org<mailto:report at bugs.python.org>>
<http://bugs.python.org/issue8126>
_______________________________________

Marc Palluat de Besset
Mac Software Engineer

email : marc.palluatdebesset at sophos.com<mailto:marc.palluatdebesset at sophos.com>
tel : +44 1235 544056
loc : E2 floor 2

SOPHOS - simply secure

________________________________
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

----------
title: Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a 10.6 Mac -> Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a	10.6 Mac
Added file: http://bugs.python.org/file16555/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________
-------------- next part --------------
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Yes, sorry for the confusion. I'm trying to build a universal 32 bit version of Python that will be embedded in our software. we need it to run on 10.4 to 10.6 Mac systems, and would like to build it on a 10.6 machine. I've been trying with several versions
 of Python to try to achieve that ; version 3.1.1, version 3.1.2rc1 and py3k. None of these version would build a 10.4 compatible universal 32 bit on our 10.6 build machine. This is why I raised an issue.
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Marc<br>
<div><br>
</div>
<div><br>
<div>
<div>On 12 Mar 2010, at 21:21, Ned Deily wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div><br>
Ned Deily &lt;<a href="mailto:nad at acm.org">nad at acm.org</a>&gt; added the comment:<br>
<br>
Note: &quot;Python.framework/Versions/3.2/Python&quot;.<br>
You appear to be building from py3k (which will become 3.2), and not Python 3.1.2rc2. &nbsp;There are pending fixes for py3k for OS X framework targeted builds and there is at least one as yet unmerged fix for 3.1.2. &nbsp;At the moment, building any branch of Python
 on 10.6 and targeting earlier systems does not work correctly; extension module building should be OK as long as the 10.4u SDK is available and gcc 4.0 is used. &nbsp;Until that is fixed, if you really need to target 10.3, you should build Python on 10.5 or 10.4,
 otherwise, build just for 10.6 on 10.6 (to do so you may need to set MACOSX_DEPLOYMENT_TARGET=10.6).<br>
<br>
----------<br>
nosy: &#43;ned.deily<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8126">http://bugs.python.org/issue8126</a>&gt;<br>
_______________________________________<br>
</div>
</blockquote>
</div>
<br>
<div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decoration
 s-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -web
 kit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div><br class="Apple-interchange-newline">
<br>
</div>
<div><span class="Apple-style-span" style="font-size: 12px; ">Marc Palluat de Besset</span></div>
<div><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px; "><i><font class="Apple-style-span" color="#929292">Mac Software Engineer</font></i></span></font></div>
<div><font class="Apple-style-span" color="#929292"><br>
</font></div>
<div><font class="Apple-style-span" color="#929292">email :&nbsp;<span class="Apple-style-span" style="color: rgb(0, 0, 0); "><a href="mailto:marc.palluatdebesset at sophos.com">marc.palluatdebesset at sophos.com</a></span></font></div>
<div><font class="Apple-style-span" color="#929292">tel : &#43;44 1235 544056</font></div>
<div><font class="Apple-style-span" color="#929292">loc : E2 floor 2</font></div>
<div><font class="Apple-style-span" color="#929292"><br>
</font></div>
<div><font class="Apple-style-span" color="#6BC0E4"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 15px; "><b><span style="font-size: 10pt; font-family: 'Trebuchet MS', sans-serif; color: rgb(84, 141, 212); ">SOPHOS&nbsp;</span></b><b><span style="font-size: 10pt; font-family: 'Trebuchet MS', sans-serif; color: gray; ">-
 simply secure</span></b></span></font></div>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
</span></div>
</span></div>
</span></span></div>
<br>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1">Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.<br>
Company Reg No 2096520. VAT Reg No GB 348 3873 20.<br>
</font>
</body>
</html>

From report at bugs.python.org  Mon Mar 15 11:37:36 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Mar 2010 10:37:36 +0000
Subject: [issue8141] test_asynchat & test_smtplib failures in 2.6 release
	branch
In-Reply-To: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>
Message-ID: <1268649456.66.0.92551319058.issue8141@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8141>
_______________________________________

From report at bugs.python.org  Mon Mar 15 11:40:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Mar 2010 10:40:14 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268649614.08.0.647446486636.issue8089@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

As per msg100765, Ned confirms this is fixed for 2.6.5.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 12:00:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 11:00:16 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1268650816.62.0.0345200147577.issue6792@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

One issue to consider is pre/post-install actions. bdist_wininst loads pythonxy.dll from the target system, which would fail if it is a 32-bit installer process that tries to load a 64-bit python DLL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Mar 15 12:02:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Mar 2010 11:02:38 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268650958.56.0.846089569275.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Re-opening for 3.1.2: the corresponding fixes have not made it into 3.1.2 yet.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 12:03:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Mar 2010 11:03:18 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268650998.73.0.937790426301.issue8089@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:03:00 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 12:03:00 +0000
Subject: [issue8146] Latest version of Python for windows 98
In-Reply-To: <1268654580.81.0.265701964424.issue8146@psf.upfronthosting.co.za>
Message-ID: <1268654580.81.0.265701964424.issue8146@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://www.python.org/download/windows/

This page lacks information about which versions of Python were last supported for Windows 95, Windows 98 and Windows 2000. Which may run even though they are not supported on these platforms anymore.

----------
assignee: georg.brandl
components: Documentation
messages: 101096
nosy: georg.brandl, techtonik
severity: normal
status: open
title: Latest version of Python for windows 98

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8146>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:09:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 12:09:46 +0000
Subject: [issue8147] os.system and standard C function system() limitations
In-Reply-To: <1268654986.31.0.580181541721.issue8147@psf.upfronthosting.co.za>
Message-ID: <1268654986.31.0.580181541721.issue8147@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/os.html#os.system

...This is implemented by calling the Standard C function system(), and has the same limitations...

Which limitations?

BTW, is the Windows 98 comment can be dropped.

----------
assignee: georg.brandl
components: Documentation
messages: 101097
nosy: georg.brandl, techtonik
severity: normal
status: open
title: os.system and standard C function system() limitations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8147>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:36:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 12:36:22 +0000
Subject: [issue5459] msiexec not creating msvcr90.dll with python -2.6.1.msi
In-Reply-To: <1236606031.24.0.862626797597.issue5459@psf.upfronthosting.co.za>
Message-ID: <1268656582.89.0.299774115038.issue5459@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't reproduce this. If I run the file with msiexec, then select "install just for me", it will copy msvcr90.dll just fine.

----------
nosy: +loewis
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5459>
_______________________________________

From report at bugs.python.org  Mon Mar 15 13:52:16 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Mar 2010 12:52:16 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268657536.55.0.0411800229153.issue6949@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

checked in after testing on {arm,i486,x86_64,powerpc,sparc,ia64}-linux with no test failures.

fixed in r78974 on the trunk
fixed in r78975 on the py3k branch

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:02:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 13:02:26 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268658146.64.0.799196320168.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't report multiple issues in a single bug report; when people follow up claiming they saw "this", it's then not clear what exactly they saw.

I have now fixed problem 1 in r78976, and put an installer incorporating that change on

http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-2.7.14683.msi

Please confirm that this actually fixes the problem.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:06:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 13:06:13 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1268658373.79.0.58837985538.issue3621@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:07:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 13:07:22 +0000
Subject: [issue4982] Running python 3 as Non-admin User requests the Runtime
	to terminate in an unusual way.
In-Reply-To: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>
Message-ID: <1268658442.91.0.958861493691.issue4982@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing because of lack of response

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4982>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:21:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 13:21:06 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268659266.74.0.233978047288.issue6716@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Your MSI works for me and fixes problem 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:28:33 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Mar 2010 13:28:33 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268659713.5.0.718668120534.issue8142@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

updated on the trunk and the py3k branch

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:34:22 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 15 Mar 2010 13:34:22 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1268660062.94.0.351802261639.issue2960@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Greg, is this issue still pending?. Can we close it?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:43:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 13:43:21 +0000
Subject: [issue8147] os.system and standard C function system() limitations
In-Reply-To: <1268654986.31.0.580181541721.issue8147@psf.upfronthosting.co.za>
Message-ID: <1268660601.71.0.511373886084.issue8147@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That would depend on the implementation of the system() call on your platform. There are already two notes for Unix and Windows right below that paragraph.

Going further into lower level specifics of the system() call is outside the scope of that documentation and is a quick internet search away.

For example:
posix - http://www.opengroup.org/onlinepubs/000095399/functions/system.html
Windows - http://msdn.microsoft.com/en-us/library/277bwbdz.aspx

----------
nosy: +brian.curtin
priority:  -> low
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8147>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:49:30 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 15 Mar 2010 13:49:30 +0000
Subject: [issue7339] bsddb crashes when transaction limit occurs
In-Reply-To: <1258475951.23.0.0144447092049.issue7339@psf.upfronthosting.co.za>
Message-ID: <1268660970.32.0.722024481239.issue7339@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I found the very same bug recently, and solve it in pybsddb 4.8.3. My patch is exactly like this :).

The problem will be solved in 2.7 when I integrate pybsddb 4.8.3/4.8.4. Not sure about 2.6, though. Will try.

"""
changeset:   478:a35a9082ee26
user:        Jesus Cea <jcea at jcea.es>
date:        Wed Feb 17 01:58:31 2010 +0100
summary:     Solve a core dump if something bad happens trying to create a transaction object.
"""

I added tests too to check correct behaviour and solved some other "bad initialization" risks.

----------
assignee:  -> jcea
nosy: +jcea
resolution:  -> accepted
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7339>
_______________________________________

From report at bugs.python.org  Mon Mar 15 14:51:50 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Mar 2010 13:51:50 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1268661110.61.0.38427482387.issue7356@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed for 2.7, 3.1, 3.2, will fix for 2.6 after the 2.6.5 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:03:42 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Mon, 15 Mar 2010 14:03:42 +0000
Subject: [issue8148] logging.SyslogHandler.emit()
In-Reply-To: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>
Message-ID: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

In SyslogHandler class from logging package, emit() function calls socket.sendto() at line 785. Passing arguments are not in the right order due to flags parameter which is optional (@see http://docs.python.org/py3k/library/socket.html#socket.socket.sendto). It results in a TypeError exception when called -->

Traceback (most recent call last):
  File "C:\PROGRA~2\Python\31\lib\logging\handlers.py", line 785, in emit
    self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)

Thanks.

PS: seen on a Windows 7 with Python 3.1.1

----------
components: Library (Lib)
messages: 101110
nosy: Kain94
severity: normal
status: open
title: logging.SyslogHandler.emit()
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8148>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:10:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 14:10:05 +0000
Subject: [issue8146] Latest version of Python for windows 98
In-Reply-To: <1268654580.81.0.265701964424.issue8146@psf.upfronthosting.co.za>
Message-ID: <1268662205.61.0.534356145499.issue8146@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You'll want to look at http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets

Win 2000 is currently supported, although there have been rumblings of beginning to drop that support.

The info exists in PEP-11 for now, but I agree that a sentence would fit on that download page. The title of the page could also use an update.

>From PEP-11:
    Name:             Win9x, WinME, NT4
    Unsupported in:   Python 2.6 (warning in 2.5 installer)
    Code removed in:  Python 2.6

----------
nosy: +brian.curtin
priority:  -> low
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8146>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:11:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 14:11:54 +0000
Subject: [issue8148] logging.SyslogHandler.emit()
In-Reply-To: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>
Message-ID: <1268662314.19.0.0980292624952.issue8148@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +vinay.sajip
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8148>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:13:19 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 15 Mar 2010 14:13:19 +0000
Subject: [issue5073] bsddb/test/test_lock.py sometimes fails due to floating
	point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1268662399.51.0.507404199065.issue5073@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch up-ported to pybsddb 4.8.4.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5073>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:14:22 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 15 Mar 2010 14:14:22 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268662462.23.0.548072079344.issue7808@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch up-ported to pybsddb 4.8.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:15:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 14:15:31 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268662531.25.0.925207607635.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It is just a matter of running "makeunicodedata" affter changing "5.1" -> "5.2".

It generates the 3 db files:
 * Modules/unicodedata_db.h
 * Modules/unicodename_db.h
 * Objects/unicodetype_db.h

Then you adjust the "expectedchecksum" in "Lib/test/test_unicodedata.py".

I use UCD 5.2 since January, and everything works fine.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:19:33 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 15 Mar 2010 14:19:33 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268662773.0.0.0857682162397.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I just did the minimal change. I don't know if removing "defined(HAVE_MAKEDEV)" is safe.

"HAVE_DEVICE_MACROS" is defined if "configure" finds "makedev()" macro.

Clarify your comment about configure.in changes being wrong.

----------
nosy:  -barry, rpetrov
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:21:03 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 15 Mar 2010 14:21:03 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268662863.3.0.65421349461.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Here's a short benchmark for everyone who thinks that my original benchmark was somehow related to TCP behavior.   This one doesn't even involve sockets:

from threading import Thread
import time

def writenums(f,n):
    start = time.time()
    for x in range(n):
        f.write("%d\n" % x)
    end = time.time()
    print(end-start)

def spin():
    while True:
        pass

# Uncomment to add a thread
#t1 = Thread(target=spin)
#t1.daemon=True
#t1.start()

writenums(open("/tmp/nums","w"),1000000)


If I run this on my Macbook with no threads, it takes about 1.05 seconds.  If the one spinning thread is turned on, the time jumps to about 4.5 seconds.  What you're seeing is that the spinning thread unfairly hogs the CPU.

If I use my own patched version (new GIL with priorities), the threaded version drops back down to about 1.10 seconds.   I have not tried it with Antoine's latest patch, but would expect similar results as he is also using priorities.

Just to be clear, this issue is not specific to sockets or TCP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:21:08 2010
From: report at bugs.python.org (franck)
Date: Mon, 15 Mar 2010 14:21:08 +0000
Subject: [issue8139] ossaudiodev not initializing its types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1268662868.16.0.29694729614.issue8139@psf.upfronthosting.co.za>


Changes by franck <fluxspir at gmail.com>:


----------
nosy: +fluxspir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8139>
_______________________________________

From report at bugs.python.org  Mon Mar 15 15:32:11 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Mar 2010 14:32:11 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268663531.15.0.954058924849.issue8140@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

+1 on this functionality being added for 2.7 and 3.2.  You also mentioned in pvt email that it would be better to patch compileall.py than py_compile.py to take advantage of the quiet and force options (which seems good to me).

I have a few comments on the diff:

* It no longer applies cleanly to trunk.  There was a recent commit that removed an unnecessary catch of KeyboardInterrupt, and I think that's what's causing the hunk reject.

* I don't like @filename and @- as the syntax for reading the compilation list from a file.  Since -f is already taken, what about adding -i<file> which tells it where to take the list from?  Of course '-i -' would mean stdin.

* Please add tests for the new functionality to test_compileall.py

Bonus points for updating this to modern Python <wink>.  E.g. using True/False instead of 1/0, and 'OSError as error' instead of 'os.error, e'.  But don't worry about that too much; I'll probably take that on as part of my PEP 3147 work. ;)

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:06:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 15:06:39 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268665599.74.0.277882255447.issue7946@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

On some platforms the difference is not so important.
I ran it in Debian Lenny AMD64 "Core2 Duo P9600 @2.66GHz".

# Python 3.2a0 (py3k:78982M, Mar 15 2010, 15:40:42) 
# [GCC 4.3.4] on linux2

0.67s without thread
0.84s with spinning thread

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:10:28 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 15 Mar 2010 15:10:28 +0000
Subject: [issue8148] logging.SyslogHandler.emit()
In-Reply-To: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>
Message-ID: <1268665828.17.0.0653308659285.issue8148@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8148>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:22:42 2010
From: report at bugs.python.org (Tom Loredo)
Date: Mon, 15 Mar 2010 15:22:42 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268666562.96.0.375137289048.issue8089@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

Ned-

I *did* run "make install"; everything I reported was about the situation *after* running "make install".  In particular, I don't know any way to get access to IDLE without "make install"; what I described came from using the version in Applications/Python 2.6, which only appears after "make install".

Okay, now I see my misunderstanding---the arch-dependent executables are in the framework only, and not linked in the installation prefix.  Is that the intended behavior?  I do put my framework in my PATH so I do have access to the executables; but I was expecting them to be in /usr/local/... as well.

The version pointed to in /usr/local/... is the 32-bit version.  This should be documented somewhere; I believe it changes previous behavior.  It's not obvious to me what to expect here, which again argues that it should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:44:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 15:44:42 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268667882.31.0.71789595284.issue7946@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With line buffering, I see the issue.

 * 6 s without thread
 * 115 s with the spinning thread (varying: 60 s, 98 s)
 * 16 s with the spinning thread and the last "gilinter.patch"


# Modified version of the test case, with bufsize=1

from threading import Thread
import time

def writenums(f, n):
    start = time.time()
    for x in range(n):
        f.write("%d\n" % x)
    end = time.time()
    print(end-start)

def spin():
    while True:
        pass

t1 = Thread(target=spin)
t1.daemon=True
# Uncomment to add a thread
#t1.start()

# With line buffering
writenums(open("./nums", "w", 1), 1000000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 16:47:24 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 15 Mar 2010 15:47:24 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268668044.46.0.799873768235.issue8140@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:22:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Mar 2010 16:22:22 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1268662531.25.0.925207607635.issue8024@psf.upfronthosting.co.za>
Message-ID: <4B9E5EBA.3080601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
> It is just a matter of running "makeunicodedata" affter changing "5.1" -> "5.2".
> 
> It generates the 3 db files:
>  * Modules/unicodedata_db.h
>  * Modules/unicodename_db.h
>  * Objects/unicodetype_db.h
> 
> Then you adjust the "expectedchecksum" in "Lib/test/test_unicodedata.py".
> 
> I use UCD 5.2 since January, and everything works fine.

So the Unicode database format itself has not changed ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:24:31 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Mar 2010 16:24:31 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268670271.21.0.571830968698.issue8140@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

changed the @ syntax to an option -i, and added a test for compile_file/compile_dir.

----------
Added file: http://bugs.python.org/file16556/compileall.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:33:03 2010
From: report at bugs.python.org (Gustavo Narea)
Date: Mon, 15 Mar 2010 16:33:03 +0000
Subject: [issue8149] libffi's configure is not executable
In-Reply-To: <1268670783.69.0.0433801915612.issue8149@psf.upfronthosting.co.za>
Message-ID: <1268670783.69.0.0433801915612.issue8149@psf.upfronthosting.co.za>


New submission from Gustavo Narea <gustavonarea at 2degreesnetwork.com>:

Download Python 2.5.5 and run ./configure: "_ctypes.so" won't be compiled because the ./configure file for libffi in ctypes is not executable.

Here's the output:
====
env: Python-2.5.5/Modules/_ctypes/libffi/configure: Permission denied
Failed to configure _ctypes module
building '_ctypes_test' extension
====

----------
assignee: theller
components: ctypes
messages: 101123
nosy: Gustavo.Narea, theller
severity: normal
status: open
title: libffi's configure is not executable
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8149>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:34:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 16:34:03 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268670843.54.0.761385423529.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> So the Unicode database format itself has not changed ?

No. The changes listed below have no impact afai-have-tested.

--------- --------- --------- --------- --------- --------- ---------
F. Unicode Character Database Changes

The detailed listing of all changes to the contributory data files of the Unicode Character Database for Version 5.2.0 can be found in UAX #44, Unicode Character Database. The most significant changes include:

    * There are new case-related properties in DerivedCoreProperties.txt and DerivedNormalizationProps.txt. The new case-related derived properties are NFKC_Casefold, Case_Ignorable, Cased, Changes_When_Lowercased, Changes_When_Uppercased, Changes_When_Titlecased, Changes_When_Casemapped, Changes_When_Casefolded, and Changes_When_NFKC_Casefolded.
    * Contributory is considered to be a distinct status for a Unicode character property. Contributory properties are neither normative nor informative. The status of all character properties is listed in the property table in UAX #44, Unicode Character Database.
    * Two new joining groups, FARSI YEH and NYA, were added. These new joining groups may require an update to implementations of Arabic shaping rules.
    * There is a new data file in the Unicode Character Database, CJKRadicals.txt, which maps the radical numbers used in the Unicode Radical-Stroke Index to the actual Unicode code points for the corresponding radicals. Unlike other files, the first field is not a code point number.
    * The Unihan.txt file in Unihan.zip is split into 8 separate files within the zip file, organized by category. See UAX #38, Unicode Han Database (Unihan) for details.
--------- --------- --------- --------- --------- --------- ---------

See also:
http://www.unicode.org/reports/tr44/tr44-4.html#Change_History

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:38:49 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 15 Mar 2010 16:38:49 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268671129.72.0.69933709369.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Whoa, that's pretty diabolically evil with bufsize=1.  On my machine, doing that just absolutely kills the performance (13 seconds without the spinning thread versus 557 seconds with the thread!).  Or, put another way, the writing performance drops from about 0.5 Mbyte/sec down to 12 Kbytes/sec with the thread.   With my priority GIL, the time is about 29 seconds with the thread (consistent with your experiment using the gilinter patch).
  
One thing to think about with this example is the proper priority of I/O handling generally.  What if, instead of a file, this example code was writing on a pipe to another process?   For that, you would probably want that I/O thread to be able to blast its data to the receiver as fast as it reasonably can so that it can be done with it and get back to other work. 

In terms of practical relevance, this test again represents a simple situation where computation is overlapped with I/O processing.  Perhaps the program has just computed a big result which is now being streamed somewhere else by a background thread.  In the meantime, the program is now working on computing the next result (the spinning thread).  Think queues, actors, or any number of similar things---there are programs that try to operate like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:51:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Mar 2010 16:51:54 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1268670843.54.0.761385423529.issue8024@psf.upfronthosting.co.za>
Message-ID: <4B9E65A6.8070104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
>> So the Unicode database format itself has not changed ?
> 
> No. The changes listed below have no impact afai-have-tested.

Ok, so +1 for updating to 5.2.

The files that have changed are not used by Python (yet), so there's
no impact of those changes for the unicodedata module.

Thanks for checking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Mon Mar 15 17:53:50 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 15 Mar 2010 16:53:50 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268672030.02.0.174190102824.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Almost forgot--if I turn off one of the CPU cores, the time drops from 557 seconds to 32 seconds.   Gotta love it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:03:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Mar 2010 17:03:58 +0000
Subject: [issue8149] libffi's configure is not executable
In-Reply-To: <1268670783.69.0.0433801915612.issue8149@psf.upfronthosting.co.za>
Message-ID: <1268672638.75.0.0552177877068.issue8149@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.5 will no longer receive bug fixes (unless they are security-related). Closing this as "won't fix".

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8149>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:16:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 17:16:38 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268673398.04.0.60683190354.issue8024@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
title: upgrade to Unicode 5.2? -> upgrade to Unicode 5.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Mon Mar 15 18:24:03 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Mar 2010 17:24:03 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268673843.85.0.379393440272.issue8140@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Looks good to me, and should help distros, so +1.

----------
assignee:  -> doko
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:18:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 18:18:50 +0000
Subject: [issue7787] Add an argument to test_support.open_urlresource to
	invalidate the cache
In-Reply-To: <1264531271.23.0.207015207456.issue7787@psf.upfronthosting.co.za>
Message-ID: <1268677130.42.0.364769473042.issue7787@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done with r78986.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7787>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:19:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 18:19:07 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1268677147.83.0.200066358994.issue7783@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done with r78986.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:19:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 18:19:21 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1268677161.84.0.645320117915.issue7783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
priority:  -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:34:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 18:34:53 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1268678093.72.0.151852462674.issue767645@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file15842/issue767645_test_pep277.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Mon Mar 15 19:35:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 18:35:40 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1268678140.04.0.377423657897.issue767645@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

With r78594, test_pep277 is active on all platforms having Unicode-friendly filesystem encoding.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:15:06 2010
From: report at bugs.python.org (aalex)
Date: Mon, 15 Mar 2010 19:15:06 +0000
Subject: [issue8150] urllib needs ability to set METHOD for HTTP requests
In-Reply-To: <1268680506.54.0.712056752351.issue8150@psf.upfronthosting.co.za>
Message-ID: <1268680506.54.0.712056752351.issue8150@psf.upfronthosting.co.za>


New submission from aalex <andrewalex at gmail.com>:

urllib.request can not support many standard HTTP 1.1 METHODS including HEAD, PUT, DELETE.

Adding this would be trivial (either as a special header "METHOD") or its own paramater, creating additional use, with little or no drawback.

----------
components: Library (Lib)
messages: 101133
nosy: aalex
severity: normal
status: open
title: urllib needs ability to set METHOD for HTTP requests
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8150>
_______________________________________

From report at bugs.python.org  Mon Mar 15 20:15:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 15 Mar 2010 19:15:18 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268680518.33.0.0315363057473.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I noticed some failures on Sparc Solaris10 buildbots (both trunk and 3.x)

======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

----------------------------------------------------------------------
Ran 325 tests in 3.088s

FAILED (failures=1)
test test_ctypes failed -- Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

----------
nosy: +flox
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 15 21:39:37 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 15 Mar 2010 20:39:37 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268685577.29.0.157313380424.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:13:14 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 15 Mar 2010 22:13:14 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1268662773.0.0.0857682162397.issue3928@psf.upfronthosting.co.za>
Message-ID: <4B9EB0F3.5040702@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Jes?s Cea Avi?n wrote:
>
> Jes?s Cea Avi?n<jcea at jcea.es>  added the comment:
>
> I just did the minimal change. I don't know if removing "defined(HAVE_MAKEDEV)" is safe.

The python build system is full with minimal changes and result is a big 
mess. Did you found which revision add ".. defined(HAVE_MAKEDEV)" in 
posix*.c ?

> "HAVE_DEVICE_MACROS" is defined if "configure" finds "makedev()" macro.

And what is result on you platform ?

> Clarify your comment about configure.in changes being wrong.

Usually just adding #include <xxxx> will break test on platforms where 
xxxx is missing.

The correct implementation will depend from above.

Cases:
1) platform is no longer supported - it is save to remove test case from 
configure and defined(HAVE_MAKEDEV) from posixmodule.c

2) HAVE_DEVICE_MACROS is defined for you . Then check how is written 
test for HAVE_DEVICE_MACROS and make test for makedev similar.

Roumen

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Mar 15 23:29:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 22:29:57 +0000
Subject: [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://codereview.appspot.com/577041/show

Index: make.bat
===================================================================
--- make.bat	(revision 78986)
+++ make.bat	(working copy)
@@ -1,4 +1,4 @@
-@@echo off
+ at echo off
 setlocal
 
 set SVNROOT=http://svn.python.org/projects
Index: library/subprocess.rst
===================================================================
--- library/subprocess.rst	(revision 78986)
+++ library/subprocess.rst	(working copy)
@@ -185,7 +185,7 @@
    Run command with arguments.  Wait for command to complete, then return the
    :attr:`returncode` attribute.
 
-   The arguments are the same as for the Popen constructor.  Example::
+   The arguments are the same as for the :class:`Popen` constructor.  Example::
 
       retcode = call(["ls", "-l"])
 
@@ -197,7 +197,7 @@
    :exc:`CalledProcessError` object will have the return code in the
    :attr:`returncode` attribute.
 
-   The arguments are the same as for the Popen constructor.  Example::
+   The arguments are the same as for the :class:`Popen` constructor.  Example::
 
       check_call(["ls", "-l"])

----------
assignee: georg.brandl
components: Documentation
files: subprocess.call.doc.diff
keywords: patch
messages: 101136
nosy: georg.brandl, techtonik
severity: normal
status: open
title: [patch] convenience links for subprocess.call()
Added file: http://bugs.python.org/file16557/subprocess.call.doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8151>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:42:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 23:42:13 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1268696533.15.0.4591204039.issue7347@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16156/issue7347.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Tue Mar 16 00:43:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 15 Mar 2010 23:43:12 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1268696592.4.0.441878963574.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed a few a/an word changes and a few tab/space issues. Re-uploaded to Rietveld at http://codereview.appspot.com/580041

----------
Added file: http://bugs.python.org/file16558/issue7347.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:00:14 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 00:00:14 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268697614.79.0.995954389201.issue7092@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Checking the pybsddb 4.8.4devel with current trunk I still see this:

"""
Berkeley DB 4.8.26: (December 18, 2009)
bsddb.db.version():   (4, 8, 26)
bsddb.db.__version__: 4.8.4devel1
bsddb.db.cvsid:       $Id: _bsddb.c,v 6408a812f035 2010/03/15 19:15:06 jcea $
py module:            /home/pybsddb/build/lib.solaris-2.10-i86pc-2.7/bsddb3/__init__.pyc
extension module:     /home/pybsddb/build/lib.solaris-2.10-i86pc-2.7/bsddb3/__init__.pyc
python version:       2.7a4+ (trunk, Mar 16 2010, 00:50:35) 
[GCC 4.4.3]
My pid:               5068
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
............................................................................................................................................................................................................................................................................................................................................................................................................................................./usr/local/lib/python2.7/threading.py:575: DeprecationWarning: sys.exc_clear() not supported in 3.x; use except clauses
  self.__exc_clear()
.........................................
----------------------------------------------------------------------
Ran 470 tests in 7.605s

OK

"""

Python 2.6.4 has the same issue too.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:04:14 2010
From: report at bugs.python.org (Thijs Triemstra)
Date: Tue, 16 Mar 2010 00:04:14 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1268697854.67.0.382853600368.issue6142@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6142>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:06:05 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 16 Mar 2010 00:06:05 +0000
Subject: [issue8148] logging.SyslogHandler.emit()
In-Reply-To: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>
Message-ID: <1268697965.76.0.620931108016.issue8148@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This appears to be a duplicate of #5421.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8148>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:07:45 2010
From: report at bugs.python.org (Francois)
Date: Tue, 16 Mar 2010 00:07:45 +0000
Subject: [issue8152] Divide error on Windows 7 Home Premium 64 bits
In-Reply-To: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>
Message-ID: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>


New submission from Francois <duf.francois at gmail.com>:

On a freshly installed Python 2.6.4, the division / truncates the result to the lower integer as // should.

This occurs on both the current 32 and 64 bits builds.

This is shown in the attached picture.

----------
components: Interpreter Core, Windows
files: python_interpreter.png
messages: 101140
nosy: f_dufour
severity: normal
status: open
title: Divide error on Windows 7 Home Premium 64 bits
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16559/python_interpreter.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8152>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:11:54 2010
From: report at bugs.python.org (Francois)
Date: Tue, 16 Mar 2010 00:11:54 +0000
Subject: [issue8152] Divide error on Windows 7 Home Premium 64 bits
In-Reply-To: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>
Message-ID: <1268698314.3.0.495988503685.issue8152@psf.upfronthosting.co.za>


Changes by Francois <duf.francois at gmail.com>:


Removed file: http://bugs.python.org/file16559/python_interpreter.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8152>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:12:45 2010
From: report at bugs.python.org (Francois)
Date: Tue, 16 Mar 2010 00:12:45 +0000
Subject: [issue8152] Divide error on Windows 7 Home Premium 64 bits
In-Reply-To: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>
Message-ID: <1268698365.81.0.537846897545.issue8152@psf.upfronthosting.co.za>


Changes by Francois <duf.francois at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8152>
_______________________________________

From report at bugs.python.org  Tue Mar 16 01:59:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2010 00:59:42 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1268671129.72.0.69933709369.issue7946@psf.upfronthosting.co.za>
Message-ID: <20100315205933.6f176a57@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> One thing to think about with
> this example is the proper priority of I/O handling generally.  What
> if, instead of a file, this example code was writing on a pipe to
> another process?   For that, you would probably want that I/O thread
> to be able to blast its data to the receiver as fast as it reasonably
> can so that it can be done with it and get back to other work. 

We should be careful with statements such as "you want probably want
[...]". There may be situations where you want such a thing; others
where you don't really want (or care about) it.

While IO responsiveness and throughput can be an important measure of
performance, it is not the only one and depending on the situation it
actually may not matter at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:13:48 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Mar 2010 01:13:48 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268702028.29.0.284712997798.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Oh the situation definitely matters.   Although, in the big picture, most programmers would probably prefer to have fast I/O performance over slow I/O performance :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:19:42 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Mar 2010 01:19:42 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268702382.02.0.415175698899.issue8143@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So David's right that local commits are bad from a threading perspective. If you happen to have an import trigger a thread which itself triggers an import you will lock up the interpreter. Typically this is avoided by not importing anything in a thread and not launching a thread based on an import. But some people do and they eventually get bit by calling a function that they didn't realize would trigger an import as a side-effect.

Since the code duplication has been solved in Python 3 I say add a comment about the duplication and be done with it for ease of development and complete backwards-compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:22:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Mar 2010 01:22:09 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1268702028.29.0.284712997798.issue7946@psf.upfronthosting.co.za>
Message-ID: <20100315212200.0066f16d@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Oh the situation definitely matters.   Although, in the big picture,
> most programmers would probably prefer to have fast I/O performance
> over slow I/O performance :-).

Yes, of course. But that's not the point. We could try to improve GIL
behaviour in every thinkable situation, at the expense of code
complexity. But we don't want to make the code too complex and
delicate to maintain, and that's why I've asked for advice on
python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 02:27:30 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 01:27:30 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268702850.42.0.584338693033.issue8140@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed for 2.7 and 3.2

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Tue Mar 16 03:06:52 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Mar 2010 02:06:52 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268705212.92.0.233225624267.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I absolutely agree 100% that it is not worth trying to fix the GIL for every conceivable situation (although if you could, I wouldn't complain).

To me, there are really only two scenarios worth worrying about:

1. Get rid of all of that multicore lock thrashing that happens if there are multiple CPU-bound threads competing.  Python programmers should know that intentionally using threads like this won't offer a performance boost.  However, it would still be nice to avoid all of that needless overhead when it happens by design or by accident (the new GIL already addresses this).

2. Make sure that you can get reasonable I/O performance when there is *one* CPU-bound thread competing with some background I/O processing.  This covers the use case of overlapped I/O and computation as well as almost every practical problem related to communicating processes, multiprocessing, queuing, etc. 

As for everything else, it's probably not worth worrying about so much.  If someone is only doing I/O (e.g., a web server), their code is going to behave about the same as before (although maybe slightly better under heavy load if there's less GIL contention).  Situations where someone intentionally tries to set up multiple long-running CPU-bound threads seems pretty unlikely---the very presence of the GIL wouldn't make that kind of programming model attractive in the first place, so why would they do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 03:35:17 2010
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 16 Mar 2010 02:35:17 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268706917.48.0.489674444386.issue8143@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

What about the alternative (newmodule) patch? That doesn't have threading issues, or break backwards compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Tue Mar 16 03:36:35 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Mar 2010 02:36:35 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268706995.07.0.920646847998.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

You know, I almost wonder whether this whole issue could be fixed by just adding a user-callable function to optionally set a thread priority number.  For example:

    sys.setpriority(n)

Modify the new GIL code so that it checks the priority of the currently running thread against the priority of the thread that wants the GIL.  If the running thread has lower priority, it immediately drops the GIL. 

Other than having this added preemption, do nothing else---just throw it all back to the user to come up with the proper "priorities." 

If there was something like this, it would completely fix the overlapped  compute and I/O problem I mentioned.  I'd just set a higher priority on the background I/O threads and be done with it.  Problem solved.

Ok, it's only a thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 03:45:20 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 16 Mar 2010 02:45:20 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1268707520.89.0.524488118953.issue6164@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

BTW, 3.1.2rc1 does not contain this fix, but contains issue6163.

Any reason why this fix is missing in 3.1.2rc1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:19:51 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 03:19:51 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268709591.8.0.443341107677.issue6949@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am about to integrate pybsddb 4.8.4, that compiles against BDB 4.8.

Oracle is going to publish a new Berkeley DB lib in a month or less. I have the pybsddb release ready, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:24:07 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 03:24:07 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268709847.92.0.0511892350708.issue6949@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Doko, bsddb3 is suppose to be "out" of py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:32:33 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Mar 2010 03:32:33 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268710353.31.0.883138245783.issue8143@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You could break it out into a module, but that feels like overkill for some minor code duplication that is not going to be a problem once we stop caring about Python 2.x. I personally wouldn't bother going that far.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Tue Mar 16 04:54:07 2010
From: report at bugs.python.org (pds)
Date: Tue, 16 Mar 2010 03:54:07 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268711647.15.0.440609052812.issue6716@psf.upfronthosting.co.za>


pds <pirdirsir at gmail.com> added the comment:

To loewis:

I'm sorry for submitting multiple issues in a single bug report.
Also, currently, I'm afraid I don't have a testing environment for your MSI build.

To other members who might follow this issue:

Please specify problem numbers when reporting.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:17:32 2010
From: report at bugs.python.org (Frank Rene Schaefer)
Date: Tue, 16 Mar 2010 06:17:32 +0000
Subject: [issue8153] 'set' union() fails in specific use case
In-Reply-To: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>
Message-ID: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>


New submission from Frank Rene Schaefer <fschaef at gmail.com>:

The union operation fails in the following use case

Python 2.6.4 (r264:75706, Jan 30 2010, 22:50:05) 
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
>>> def func():
...     a = set([0])
...     a.pop()
...     b = set([1, 2])
...     a.union(b)
...     return a
... 
>>> func()
set([])

Note, that is does *not* fail if it is *not* inside a function, i.e.

>>> a = set([0])
>>> a.pop()
0
>>> b = set([1, 2])
>>> a.union(b)
set([1, 2])
>>>

----------
components: Interpreter Core
messages: 101154
nosy: fschaef2
severity: normal
status: open
title: 'set' union() fails in specific use case
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8153>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:47:08 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 06:47:08 +0000
Subject: [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1268722028.33.0.0527664437467.issue6949@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

jcea: yes, but we want _dbm be able to build with 4.8.x as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________

From report at bugs.python.org  Tue Mar 16 07:55:25 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Mar 2010 06:55:25 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268666562.96.0.375137289048.issue8089@psf.upfronthosting.co.za>
Message-ID: <AD689E9E-D4B4-4D23-AA12-4457352AFD58@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 15 Mar, 2010, at 16:22, Tom Loredo wrote:

> 
> Tom Loredo <loredo at astro.cornell.edu> added the comment:
> 
> Ned-
> 
> I *did* run "make install"; everything I reported was about the situation *after* running "make install".  In particular, I don't know any way to get access to IDLE without "make install"; what I described came from using the version in Applications/Python 2.6, which only appears after "make install".
> 
> Okay, now I see my misunderstanding---the arch-dependent executables are in the framework only, and not linked in the installation prefix.  Is that the intended behavior?  I do put my framework in my PATH so I do have access to the executables; but I was expecting them to be in /usr/local/... as well.
> 
> The version pointed to in /usr/local/... is the 32-bit version.  This should be documented somewhere; I believe it changes previous behavior.  It's not obvious to me what to expect here, which again argues that it should be documented.

This is not a regression in 2.6,  the python-32 executable has never been linked into /usr/local/bin.  I agree that they should be as long as we fill /usr/local/bin, but that can wait until 2.6.6.

I always add the framework to $PATH because distutils installs scripts into that location.   It would be worthwhile to change that for 2.7 and 3.2: tweak distutils to ensure that site-packages and scripts get installed in /Library/Python/2.7/... and install (links to) the public executables there as well.  That way the location of scripts and site-packages is easily found in the Finder, while keeping a versioned location.     I don't want to tweak distutils to install into /usr/local because I have several python trees and those should stay separate.

Ronald

> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8089>
> _______________________________________

----------
Added file: http://bugs.python.org/file16560/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100316/d838b4b7/attachment.bin>

From report at bugs.python.org  Tue Mar 16 08:42:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 07:42:27 +0000
Subject: [issue8153] 'set' union() fails in specific use case
In-Reply-To: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>
Message-ID: <1268725347.75.0.547421383777.issue8153@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

set.union doesn't change the first set (i.e. a), but returns a new sets (i.e. c):
>>> def func():
...   a = set([0])
...   a.pop()
...   print 'a:', a
...   b = set([1, 2])
...   c = a.union(b)
...   print 'a:', a
...   return c
...
>>> func()
a: set([])
a: set([])
set([1, 2])

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8153>
_______________________________________

From report at bugs.python.org  Tue Mar 16 09:10:26 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 16 Mar 2010 08:10:26 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1268727026.33.0.105304745944.issue5166@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

What about this example?
>>> from xml.dom import minidom
>>> doc = minidom.Document()
>>> el = doc.createElement("Test")
>>> el.setAttribute("with space", "False")
>>> doc.appendChild(el)
<DOM Element: Test at 0xba1440>
>>>
>>> #nahhh
... minidom.parseString(doc.toxml())
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Python26\lib\xml\dom\minidom.py", line 1928, in parseString
    return expatbuilder.parseString(string)
  File "C:\Python26\lib\xml\dom\expatbuilder.py", line 940, in parseString
    return builder.parseString(string)
  File "C:\Python26\lib\xml\dom\expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 33

>>>

Is it worth making another bug report?

----------
nosy: +nvetoshkin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:14:12 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 10:14:12 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1268734452.3.0.0956539111361.issue4961@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the patch works for me with tcl8.5

----------
nosy: +doko
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4961>
_______________________________________

From report at bugs.python.org  Tue Mar 16 11:54:42 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 10:54:42 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1268736882.08.0.615695388217.issue4961@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed for 2.7, 3.1, 3.2, commit pending for 2.6 until after the 2.6.5 release

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4961>
_______________________________________

From report at bugs.python.org  Tue Mar 16 12:04:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Mar 2010 11:04:22 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268737462.38.0.379289461551.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Merged last commit to py3k, as r78991.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:05:43 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 12:05:43 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

calling os.execlp('true') with the wrong number of arguments (missing 2nd arg), the interpreter crashes. fixed in 3.x, this is a backport of the patch to 2.x

----------
components: Extension Modules
files: p.diff
keywords: patch
messages: 101162
nosy: doko
severity: normal
status: open
title: os.execlp('true') crashes the interpreter on 2.x
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16561/p.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:27:47 2010
From: report at bugs.python.org (Eric Devolder)
Date: Tue, 16 Mar 2010 12:27:47 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268742467.17.0.990315620966.issue2698@psf.upfronthosting.co.za>


Eric Devolder <eric.devolder at gmail.com> added the comment:

Same problem on 3.1.2rc1.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:45:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Mar 2010 12:45:39 +0000
Subject: [issue8155] Incompoatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A bug report for the incompatibility I was trying to explain on the checkins list. The test_support module is the only part of the regression test suite that is officially documented, so we can't go changing behaviour that is visible to third parties at will.

Python 2.6.5rc2 (release26-maint:78987, Mar 16 2010, 19:48:42)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.test_support import check_warnings
>>> with check_warnings():
...   pass
...
>>>

Python 2.7a4+ (trunk:78987, Mar 16 2010, 19:48:39)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.test_support import check_warnings
>>> with check_warnings():
...   pass
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/home/ncoghlan/devel/python/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/home/ncoghlan/devel/python/Lib/test/test_support.py", line 568, in _filterwarnings
    missing[0])
AssertionError: filter ('', Warning) did not catch any warning
>>>

Third party test suites may want to use check_warnings() for both 2.6 and 2.7 and this change makes it unnecessarily difficult for them to do so.

Fixing this should just be a matter of flipping the default value of the new "quiet" parameter to True and updating the tests and documentation accordingly.

----------
assignee: flox
messages: 101164
nosy: flox, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Incompoatible change to test.test_support.check_warnings behaviour
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:45:48 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Mar 2010 12:45:48 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268743548.11.0.602386333957.issue8155@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Incompoatible change to test.test_support.check_warnings behaviour -> Incompatible change to test.test_support.check_warnings behaviour

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Tue Mar 16 13:55:37 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 12:55:37 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1268744137.8.0.110841576882.issue7808@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have problem getting your changes working in python 3.x. Yes, pybsddb supports py3k.

The problem is line "sys.exc_traceback = sys.last_traceback = None", that throws the following error under python 3.x:

"""
File "/home/pybsddb/build/lib.solaris-2.10-i86pc-3.1/bsddb3/tests/test_compare.py", line 215, in verifyStderr
    sys.exc_info()[2] = sys.last_traceback = None
TypeError: 'tuple' object does not support item assignment
"""

The line is automatically translated by "2to3".

Any suggestion?.

I guess in 3.x we can change the line to "sys.exc_clear()", and forget about the "None" asignment. What do you think?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:12:24 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 13:12:24 +0000
Subject: [issue8156] pybsddb 4.8.3+ integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

This issue tracks the progress of integration of pybsddb 4.8.3+ and centralize related discussion.

I have integrated all bsddb related patches until r78988, in pybsddb 4.8.3+, with the following caveats:

- The new code supports BDB 4.8, but drops support for 4.0. Berkeley DB 4.0 was released in 2001...

- Revert issue6949 (the 2.7 part). This integration work supercedes it.

- issue6462 is not integrated in pybsddb, but will be retained in the code integrated in python. I will try to resolve it in a permanent way after integration.

- issue3892 is not integrated in pybsddb, but will be retained in the code integrated in python. I will try to resolve it in a permanent way after integration.

- issue7975: I can't reproduce this bug with current pybsddb version. I will keep the patch around, but first integration test will not include it, unless we still can reproduce.

Some changes in bsddb testsuite require 2.7/3.2. I have decided to keep the changes, so I have to backport some code and use conditional execution, because I must support python 2.3-2.7 and 3.0-3.2.

----------
assignee: jcea
components: Extension Modules
messages: 101166
nosy: jcea
severity: normal
stage: patch review
status: open
title: pybsddb 4.8.3+ integration
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8156>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:14:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2010 13:14:45 +0000
Subject: [issue8152] Divide error on Windows 7 Home Premium 64 bits
In-Reply-To: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>
Message-ID: <1268745285.12.0.669268337286.issue8152@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I see that you already closed this;  but just for completeness:

This is expected behaviour:  in 2.x, the '/' operator does floor division unless you've done a 'from __future__ import division', in which case it does true division.

In 3.x, '/' always does floor division.

----------
nosy: +mark.dickinson
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8152>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:19:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Mar 2010 13:19:50 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268745590.62.0.358686807342.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Problem 2 is resolved as of r78992

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Tue Mar 16 14:31:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 16 Mar 2010 13:31:08 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268746268.75.0.182606408803.issue8155@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:01:34 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 16 Mar 2010 14:01:34 +0000
Subject: [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1268748094.96.0.395951434457.issue8145@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8145>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:23:30 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 16 Mar 2010 14:23:30 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1268749410.95.0.874063976629.issue3621@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Moving the target to Distutils2, as Distutils is now feature frozen.

----------
components: +Distutils2 -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Tue Mar 16 15:58:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_Duc=C3=A1r?=)
Date: Tue, 16 Mar 2010 14:58:59 +0000
Subject: [issue8157] test_doctest.py fails with unexpected results in
	doctest.testfile
In-Reply-To: <1268751539.87.0.456644234876.issue8157@psf.upfronthosting.co.za>
Message-ID: <1268751539.87.0.456644234876.issue8157@psf.upfronthosting.co.za>


New submission from Martin Duc?r <ducarm1 at gmail.com>:

During python regrtest.py i have found that doctest test module does not count with expected output when using testfile test_doctest.txt. Example output of the test:
---------------------------------------------------------------------
File "/usr/lib/python2.6/test/test_doctest.py", line 2146, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt') # doctest: +ELLIPSIS
Expected:
    **********************************************************************
    File "...", line 6, in test_doctest.txt
    Failed example:
        favorite_color
    Exception raised:
        ...
        NameError: name 'favorite_color' is not defined
    **********************************************************************
    1 items had failures:
       1 of   2 in test_doctest.txt
    ***Test Failed*** 1 failures.
    TestResults(failed=1, attempted=2)
Got:
    Trying:
        favorite_color
    Expecting:
        'blue'
    **********************************************************************
    File "/usr/lib/python2.6/test/test_doctest.txt", line 6, in test_doctest.txt
    Failed example:
        favorite_color
    Exception raised:
        Traceback (most recent call last):
          File "/usr/lib/python2.6/doctest.py", line 1241, in __run
            compileflags, 1) in test.globs
          File "<doctest test_doctest.txt[0]>", line 1, in <module>
            favorite_color
        NameError: name 'favorite_color' is not defined
    Trying:
        if 1:
           print 'a'
           print
           print 'b'
    Expecting:
        a
        <BLANKLINE>
        b
    ok
    **********************************************************************
    1 items had failures:
       1 of   2 in test_doctest.txt
    2 tests in 1 items.
    1 passed and 1 failed.
    ***Test Failed*** 1 failures.
    TestResults(failed=1, attempted=2)
---------------------------------------------------------------------
There are two test cases  in that file and it count's only with the output of the one, another similar failed testcases from test_doctest.py are:
---------------------------------------------------------------------
File "/usr/lib/python2.6/test/test_doctest.py", line 2168, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs)
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2173, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs,
                     extraglobs=extraglobs) # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2193, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs,
                     module_relative='test')
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2227, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', name='newname')
    # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2238, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', report=False)
    # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2264, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest4.txt') # doctest: +ELLIPSIS
---------------------------------------------------------------------



---------------------------------------------------------------------
# cat /usr/lib/python2.6/test/test_doctest.py
This is a sample doctest in a text file.

In this example, we'll rely on a global variable being set for us
already:

  >>> favorite_color
  'blue'

We can make this fail by disabling the blank-line feature.

  >>> if 1:
  ...    print 'a'
  ...    print
  ...    print 'b'
  a
  <BLANKLINE>
  b
---------------------------------------------------------------------

This fails on python version 2.6.4. OS tried Arch linux and OpenSolaris, failed on both the same way. Full log in attachment

Testsuite run with -v argument:
# python2.6 /usr/lib/python2.6/test/test_doctest.py -v

----------
components: Library (Lib)
files: python26_test_doctest.log
messages: 101170
nosy: Martin.Duc?r
severity: normal
status: open
title: test_doctest.py fails with unexpected results in doctest.testfile
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16562/python26_test_doctest.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8157>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:43:15 2010
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 16 Mar 2010 15:43:15 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268754195.63.0.930273628077.issue8089@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

> the python-32 executable has never been linked into /usr/local/bin.

What I meant by "the version pointed to" is:  The "python" command
in 2.6.4 produced by an "intel" universal build (whether in the
framework or the install prefix) executed as 64-bit.  I
don't believe it linked to either python-32 or -64; I don't think those
were even installed in 2.6.4.  I think it was a bundle that just
happened to execute as 64-bit (and provided no access to 32-bit
python).  So the "python" command-line behavior under 2.6.5rc2 is
different from what it was for 2.6.4.  I don't think this is a 
significant regression, as the previous behavior was never documented 
and was actually somewhat problematic.  I'm just pointing it out for 
documentation purposes.

> I always add the framework to $PATH because distutils installs scripts into that location.

Yes, I do the same.  Still, I think your proposed plans for linking in the prefix in 2.7/3.2 make a lot of sense.

----------
versions: +Python 2.6 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar 16 16:56:38 2010
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 16 Mar 2010 15:56:38 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1268754998.94.0.123441590967.issue2636@psf.upfronthosting.co.za>


Alex Willmer <alex at moreati.org.uk> added the comment:

I've adapted the Python 2.6.5 test_re.py as follows, 

 from test.test_support import verbose, run_unittest
-import re
-from re import Scanner
+import regex as re
+from regex import Scanner

and run it against regex-2010305. Three tests failed, and the report is attached.

----------
Added file: http://bugs.python.org/file16563/regex_test-20100316

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:21:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Mar 2010 16:21:08 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1268756468.23.0.124483967323.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Problem 3 is now fixed in r78994.

Leaving this report open for backporting the changes to 2.6/3.1

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Tue Mar 16 17:37:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Mar 2010 16:37:28 +0000
Subject: [issue8157] test_doctest.py fails with unexpected results in
	doctest.testfile
In-Reply-To: <1268751539.87.0.456644234876.issue8157@psf.upfronthosting.co.za>
Message-ID: <1268757448.6.0.687494800934.issue8157@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 1729305.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_doctest fails when run in verbose mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8157>
_______________________________________

From report at bugs.python.org  Tue Mar 16 18:21:49 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 16 Mar 2010 17:21:49 +0000
Subject: [issue5594] IDLE startup configuration
In-Reply-To: <1238311210.52.0.532490988344.issue5594@psf.upfronthosting.co.za>
Message-ID: <1268760109.72.0.901081011145.issue5594@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

Editing a block of code from inside the config dialog (and storing it in the config file?) seems a bad idea because you lose all the power of the normal IDLE editor.

Instead, you should edit the startup code in the editor, save it to a file and point the IDLESTARTUP or PYTHONSTARTUP environment variable to it (http://docs.python.org/library/idle.html#startup).

[Unfortunately, these envvars currently don't work after restart; http://bugs.python.org/issue5233 has patches to fix that.]

What does make sense is having a way to set the startup file from the  config dialog, instead of environment variables.  I suspect nobody cares enough to implement this if you don't.

----------
nosy: +cben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5594>
_______________________________________

From report at bugs.python.org  Tue Mar 16 18:39:26 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 16 Mar 2010 17:39:26 +0000
Subject: [issue5594] IDLE startup configuration
In-Reply-To: <1238311210.52.0.532490988344.issue5594@psf.upfronthosting.co.za>
Message-ID: <1268761166.4.0.545252876021.issue5594@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

(Another point I forgot to mention is that you must also run idle with the -s command-line option to look at these envvars.  This was silly and is also fixed by the #5233 patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5594>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:21:07 2010
From: report at bugs.python.org (Simon Anders)
Date: Tue, 16 Mar 2010 18:21:07 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>


New submission from Simon Anders <anders at embl.de>:

The class optparse.OptionParser supports a number of useful keyword arguments to the initializer, which are not documented in the Python Standard Library documentation, here: http://docs.python.org/library/optparse.html

This is a bit unfortunate. For example, I wanted to add a description to the top of my script's help page and a copyright notice to the foot, and was already about to subclass OptionParser in order to override the format_help method, when I noticed that optional keyword arguments 'description' and 'epilog' are provided for precisely this purpose.

The 'epilog' attribute is at least mentioned in the class's docstring, while the 'description' argument is completely undocumented. I doubt that this was done on purpose.

I'd suggest to go over the documentation page for optparse and fill in the missing bits; at minimum, list all keyword arguments to optparse.OptionParser.__init__.

----------
assignee: georg.brandl
components: Documentation
messages: 101177
nosy: georg.brandl, sanders
severity: normal
status: open
title: documentation of 'optparse' module incomplete
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:36:02 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Tue, 16 Mar 2010 18:36:02 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1268764562.73.0.627142412942.issue1103213@psf.upfronthosting.co.za>


Irmen de Jong <irmen at users.sourceforge.net> added the comment:

Sure, I'll give it another go.

I've not done any c-development for quite a while though, so I have to pick up the pieces and see how far I can get. Also, I don't have any compiler for Windows so maybe I'll need someone else to validate the patch on Windows for me, once I've got something together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1103213>
_______________________________________

From report at bugs.python.org  Tue Mar 16 19:42:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 16 Mar 2010 18:42:25 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1268764945.45.0.656629222209.issue8158@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:17:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Mar 2010 19:17:32 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1268767052.87.0.856751406298.issue8158@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Would you care to submit a patch?  The docs are in the svn repository in the 'Doc' subdirectory.  See http://www.python.org/dev for how to get a checkout and create a patch.

That said, note that 2.7/3.2 will have argparse, which is pretty much a superset of optparse and recommended for use instead of optparse, and it does document those options.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:25:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Mar 2010 19:25:38 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268767538.14.0.771903400854.issue8133@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Brett:  any thoughts on this?  Should imp.find_module automatically apply NFD normalization to the given string on OS X?

It seems to me that doing this properly is a bit nasty, since the correct condition isn't that the OS is OS X, but that the relevant filesystem is HFS+;  presumably a single call to imp.find_module could end up checking directories with differing filesystems.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:31:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 19:31:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1268767885.59.0.217642263157.issue2636@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Does regex.py have its own test suite (which also includes tests for all the problems reported in the last few messages)?
If so, the new tests could be merged in re's test_re. This will simplify the testing of regex.py and will improve the test coverage of re.py, possibly finding new bugs. It will also be useful to check if the two libraries behave in the same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Mar 16 20:50:45 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 16 Mar 2010 19:50:45 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1268769045.87.0.9038801424.issue2704@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

History access by Up/Down is important because it makes IDLE history much more discoverable.  Most users instinctively expect Up/Down to work; moving back through the text of the session is nice but they probably won't guess that you can press Enter to reuse old commands; and it's not an efficient way to access history anyway.

The problem is increased by the fact that Alt+P/N *don't appear anywhere in the menus*, so a user will never discover them!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:15:11 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 16 Mar 2010 20:15:11 +0000
Subject: [issue5233] Enhance 2.7 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on
	restart
In-Reply-To: <1234478082.8.0.463106292983.issue5233@psf.upfronthosting.co.za>
Message-ID: <1268770511.64.0.790679455484.issue5233@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

Oops!  Mitchell's patch didn't actually run the startup code after restart.  Fixed patch attached (updated against 2.7 trunk).  Also added some doc updates.  Too lazy to produce a 3.2 version now.

[Apology to Mitchell: I removed most of your comments explaining the change and attributing it to you.  Nothing personal, just that's we have version control to store that info.]

Open questions / doubts:

* I described it in Lib/idlelib/NEWS.txt - correct?

* There is much duplication between the Doc/library/idle.rst, the command-line help string in PyShell.py and the option parsing code.  Maybe it should be rewritten with optparse?  [Doesn't block this patch.]

* There is much duplication between begin()/start_subprocess() and restart_subprocess().  These pieces of the code have a history of being fragile, and having subtle differences between them is a bad idea :-(  I didn't dare refactor them as I can't test such changes widely enough, so the startup call is duplicated.

* When a script is being run, should the startup file run before or after it (or at all)?  Currently it runs before the script, which is good because it can e.g. set the excepthook, and bad because it's different from running in a clean Python.   (Python doesn't run PYTHONSTARTUP at all when running a script, even in -i mode.)
Opinions?  Anyway, it's hard to implement otherwise with currect runcode().

[Unrelated to the patch but bothering me: it seems that runcode() sometimes restart the shell and sometimes not, and is used in both capacities?!  This is very confusing.  Or am I just reading it wrong?]

----------
nosy: +cben
Added file: http://bugs.python.org/file16564/startup-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5233>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:19:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 20:19:04 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1268770744.02.0.64726205145.issue7319@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The silencing of DeprecationWarnings should also be advertised, so that who writes the code knows that now -Wd should be used explicitly while testing the code. A warning in the "What's new" would be a good place where to start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:21:36 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 16 Mar 2010 20:21:36 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1268770896.49.0.353717113494.issue6584@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have created a small patch, that introduces BadGzipFile exception. It is a subclass of IOError, so it would be backward compatible and will be still caught by old code, but this way is distinct from IOError.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file16565/6584_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:21:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Mar 2010 20:21:53 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268770913.33.0.139270916162.issue8133@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Trying to get this right is nasty as mixed filesystem stuff is always tricky, especially since NFD is still UTF-8 as is NFC so sys.getdefaultencoding() doesn't help.

Without some way to get that extra bit of info about what form of UTF-8 encoding is being used for the filesystem, I think the test should be modified to use os.listdir() to find the name as encoded by the filesystem and use that as the argument to imp.find_module() instead of assuming the filesystem didn't tweak what it was given.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:47:37 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 16 Mar 2010 20:47:37 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1268772457.58.0.233491104585.issue6584@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Modified patch with test, that catches both BadGzipFile and IOError exceptions.

----------
Added file: http://bugs.python.org/file16566/6584_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:48:58 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Mar 2010 20:48:58 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268772538.9.0.230705635785.issue8089@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Unless you vehemently disagree, I am not making this a release blocker for 2.6.5.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:49:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Mar 2010 20:49:30 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268772570.78.0.966620582021.issue8154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Looks ok, but I think it needs a test, and it looks like execve suffers from the same problem.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Tue Mar 16 21:50:42 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Mar 2010 20:50:42 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268772642.11.0.16865699716.issue3928@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

jcea, why did  you make this a release blocker for 2.6.5?

----------
nosy: +barry
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:09:41 2010
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 16 Mar 2010 21:09:41 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268773781.92.0.228863299499.issue8089@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

> Unless you vehemently disagree, I am not making this a release blocker for 2.6.5.

I'm not sure who you are asking (I doubt it was me!), but I don't consider this a release blocker.  The only possible substantive issue is whether "python" should run 32-bit or 64-bit Python after a universal framework install.  Previously it ran 64-bit, but that was probably accidental.  I don't have a strong opinion about this; others should weigh in appropriately.

I think a change in behavior here would only negatively impact a very small number of users (those who built from source on OS X, and who built universal versions on a 64-bit platform, and who count on 64-bit default behavior).  For example, they may have built 64-bit extensions that could appear broken after an update to 2.6.5 if they don't know they should use "python-64".

In my opinion the main part of the "source" at issue here is not really source but the Mac/README file; but this is certainly not the only subtlety of Python-on-OS X that is not yet covered there!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:17:33 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 16 Mar 2010 21:17:33 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268774253.82.0.248764035922.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I tried Florent's modification to the write test and did not see the effect on my machine with an updated revision of Python32.

I am running Ubuntu Karmic 64 bit.
7s - no background threads.
20s - one background thread.

According to the following documentation the libc condition is using scheduling policy when waking a thread and not FIFO order:
The following documentation suggests ordering in Linux is not FIFO:
http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_timedwait.html#tag_03_518_08_06

I upload a quick and dirty patch (linux-7946.patch) to the new GIL just to reflect this by avoiding the timed waits.  

On my machine it behaves reasonably both with the TCP server and with the write test, but so does unpatched Python 3.2.

I noticed high context switching rate with dave's priority GIL - with both tests it goes above 40K/s context switches.

----------
Added file: http://bugs.python.org/file16567/linux-7946.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:37:51 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 16 Mar 2010 21:37:51 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1268775471.57.0.412266458296.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I am not sure about the testsuite for this regex module, but it seems to me, that many of the problems reported here probably don't apply for the current builtin re, as they are connected with the new features of regex.
After the suggestion in msg91462. I briefly checked the re testsuite and found it very comprehensive, given the featureset. Of course, most/all? re tests should apply for regex, but probably not vice versa.
vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:41:26 2010
From: report at bugs.python.org (Razan Abbass)
Date: Tue, 16 Mar 2010 21:41:26 +0000
Subject: [issue8159] a11
In-Reply-To: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>
Message-ID: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>


New submission from Razan Abbass <raz71abb6 at yahoo.ca>:

a11

----------
components: None
messages: 101194
nosy: raz71abb6
severity: normal
status: open
title: a11
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:41:51 2010
From: report at bugs.python.org (Razan Abbass)
Date: Tue, 16 Mar 2010 21:41:51 +0000
Subject: [issue8159] a11
In-Reply-To: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>
Message-ID: <1268775711.61.0.533628619679.issue8159@psf.upfronthosting.co.za>


Changes by Razan Abbass <raz71abb6 at yahoo.ca>:


Added file: http://bugs.python.org/file16568/ooo1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:41:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 21:41:59 +0000
Subject: [issue8159] a11
In-Reply-To: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>
Message-ID: <1268775719.73.0.227589555784.issue8159@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16568/ooo1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:42:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 21:42:05 +0000
Subject: [issue8159] a11
In-Reply-To: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>
Message-ID: <1268775725.88.0.978306187369.issue8159@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:42:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 21:42:09 +0000
Subject: [issue8159] a11
Message-ID: <1268775729.26.0.00687777568165.issue8159@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 22:42:51 2010
From: report at bugs.python.org (Razan Abbass)
Date: Tue, 16 Mar 2010 21:42:51 +0000
Subject: [issue8159] a11
Message-ID: <1268775771.58.0.434094699803.issue8159@psf.upfronthosting.co.za>


Changes by Razan Abbass <raz71abb6 at yahoo.ca>:


Added file: http://bugs.python.org/file16569/o11

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Tue Mar 16 23:34:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Mar 2010 22:34:21 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268778861.0.0.595651157572.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

As far as I can tell, it does not *crash* the interpreter.  Instead, it replaces the python interpreter process with a "true" utility.

$ ./python.exe 
Python 2.7a4+ (trunk:78816M, Mar  9 2010, 18:57:13) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os; os.execlp('true')
$ echo $?
0
$ ./python.exe 
Python 2.7a4+ (trunk:78816M, Mar  9 2010, 18:57:13) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os; os.execlp('false')
air:trunk sasha$ echo $?
1

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Tue Mar 16 23:35:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Mar 2010 22:35:27 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268778927.94.0.529217805839.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I forgot to add that this behavior is documented:

os.execlp = execlp(file, *args)
    execlp(file, *args)
    
    Execute the executable file (which is searched for along $PATH)
    with argument list args, replacing the current process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Tue Mar 16 23:36:58 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 16 Mar 2010 22:36:58 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1268779018.61.0.81458610817.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I updated the patch with a small fix and increased the ticks countdown-to-release considerably. This seems to help the OS classify CPU bound threads as such and actually improves IO performance.

----------
Added file: http://bugs.python.org/file16570/linux-7946.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Mar 16 23:38:30 2010
From: report at bugs.python.org (tejas)
Date: Tue, 16 Mar 2010 22:38:30 +0000
Subject: [issue8160] platform.platform() throws exception on modified debian
	distribution
In-Reply-To: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>
Message-ID: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>


New submission from tejas <tejas81 at gmail.com>:

I am calling platform.linux_distribution() and platform.platform() on a modified Debian distribution with Python 2.6.
FWIW the file /etc/debian_version exists on this machine, but is empty.

On calling platform.platform(), it seems to try to read the linux version from /etc/debian_version, but crashes with the following exception:

Python 2.6 (r26:66714, Mar  4 2010, 13:02:59)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.platform()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/platform.py", line 1524, in platform
    distname,distversion,distid = dist('')
  File "/usr/local/lib/python2.6/platform.py", line 361, in dist
    full_distribution_name=0)
  File "/usr/local/lib/python2.6/platform.py", line 333, in linux_distribution
    _distname, _version, _id = _parse_release_file(firstline)
  File "/usr/local/lib/python2.6/platform.py", line 269, in _parse_release_file
    return '', version, id
UnboundLocalError: local variable 'version' referenced before assignment

----------
components: Library (Lib)
messages: 101198
nosy: tejas81
severity: normal
status: open
title: platform.platform() throws exception on modified debian distribution
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8160>
_______________________________________

From report at bugs.python.org  Tue Mar 16 23:46:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Mar 2010 22:46:12 +0000
Subject: [issue8160] platform.platform() throws exception on modified debian
	distribution
In-Reply-To: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>
Message-ID: <1268779572.08.0.134071539544.issue8160@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> lemburg
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8160>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:19:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Mar 2010 23:19:03 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268781543.97.0.445794343038.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The original report, issue1039 has a better problem description:

"In a windows debug build, an assertion is triggered when os.execvpe is
called with an empty argument list:

self.assertRaises(OSError, os.execvpe, 'no such app-', [], None)"

The patch, file8338/os.diff is complete with a test and should be easy to apply to the trunk.

I would be -0 on the change.  On one hand, POSIX seems to require a non-empty argument list, on the other hand at least Linux and MacOS X appear to be happy with os.execlp('true').  Furthemore, the proposed change will change the exception from os.execlp('no such program') from OSError to ValueError, which is not a backward compatible change.  As such it is certainly not appropriate for bug-fix releases.

As far as 3x series are concerned, I think ValueError exception should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:19:47 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 16 Mar 2010 23:19:47 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1268781587.89.0.618143414366.issue6164@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

and restore of distutils in trunk abandon it.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:24:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Mar 2010 23:24:38 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268781878.41.0.128626610386.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Adding Thomas.

Thomas,

Do you remember why your patch for issue1039 was not backported?

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:31:15 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 16 Mar 2010 23:31:15 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1268782275.51.0.471301948556.issue6164@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ah, I see. I am just re-opening this bug hoping to see it get fixed by 3.1.2.

----------
status: closed -> open
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:46:42 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 23:46:42 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268783202.06.0.353152883783.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

it does crash:

$ python
Python 2.6.5rc2 (r265rc2:78822, Mar 11 2010, 13:01:50) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.execlp('true')
Segmentation fault (core dumped)

arg[0] (the command name) must be part of the second parameter.


side notice: the execlpe looks inconsistent (both 2.x and 3.x).

>>> os.execlpe('true')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/os.py", line 335, in execlpe
    env = args[-1]
IndexError: tuple index out of range

shouldn't this be a ValueError as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:48:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 23:48:04 +0000
Subject: [issue8159] a11
Message-ID: <1268783284.49.0.872279055736.issue8159@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16569/o11

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Wed Mar 17 00:48:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Mar 2010 23:48:31 +0000
Subject: [issue8159] spam
Message-ID: <1268783311.88.0.665576104457.issue8159@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
title: a11 -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8159>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:02:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Mar 2010 00:02:53 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268783202.06.0.353152883783.issue8154@psf.upfronthosting.co.za>
Message-ID: <d38f5331003161702y65e84d5fjc2a202c72141e012@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Mar 16, 2010 at 7:46 PM, Matthias Klose <report at bugs.python.org> wrote:
..
> it does crash:

Strange.  Can you report your Linux version and the stack trace from the crash?

On Ubuntu, 2.6.24-27-generic #1 SMP Wed Jan 27 23:54:28 UTC 2010 i686
GNU/Linux, I see no crash.

Moreover, I've just checked that the following C program works just fine:

#include <unistd.h>

int
main()
{
  execlp("ls", NULL);
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:05:26 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 17 Mar 2010 00:05:26 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1268784326.62.0.299318216249.issue6164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes, the revert put back distutils in its initial 2.6.x state but I guess this can be added back since it doesn't change the original behavior.

----------
priority:  -> high
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:14:01 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Wed, 17 Mar 2010 00:14:01 +0000
Subject: [issue1103213] Adding the missing socket.recvall() method
Message-ID: <1268784841.95.0.507228299608.issue1103213@psf.upfronthosting.co.za>


Irmen de Jong <irmen at razorvine.net> added the comment:

Ok I've looked at it again and think I can build an acceptable patch this time. However there are 2 things that I'm not sure of:

1) how to return the partial data to the application if the recv() loop fails before completion. Because the method will probably raise an exception on failure, as usual, it seems to me that the best place to put the partial data is inside the exception object. I can't think of another easy and safe way for the application to retrieve it otherwise. But, how is this achieved in code? I'll be using set_error() to return an error from my sock_recvall function I suppose.

2) the trunk is Python 2.7, should I make a separate patch for 3.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1103213>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:20:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 17 Mar 2010 00:20:26 +0000
Subject: [issue8153] 'set' union() fails in specific use case
In-Reply-To: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>
Message-ID: <1268785226.45.0.081120088326.issue8153@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Frank, try using "update" instead of "union".

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8153>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:24:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Mar 2010 00:24:03 +0000
Subject: [issue8160] platform.platform() throws exception on modified debian
	distribution
In-Reply-To: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>
Message-ID: <1268785443.99.0.0298769074491.issue8160@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8160>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:34:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Mar 2010 00:34:46 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268786086.5.0.901368840427.issue8154@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It does not crash on Gentoo, either:

rdmurray at maestro:~>uname -a
Linux maestro 2.6.31-gentoo-r3 #1 SMP PREEMPT Thu Oct 22 20:13:19 EDT 2009 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

rdmurray at maestro:~/python/release26-maint>./python
Python 2.6.5rc2 (release26-maint:79008, Mar 16 2010, 20:29:24) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[36856 refs]
>>> os.execlp('false')
rdmurray at maestro:~/python/release26-maint>echo $?
1

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 01:40:05 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Mar 2010 00:40:05 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268786405.71.0.923776969669.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

crash seen on both Debian unstable and recent Ubuntu lucid.

(gdb) run
Starting program: /home/doko/a.out 
process 30155 is executing new program: /bin/ls
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
strrchr () at ../sysdeps/i386/strrchr.S:178
178	../sysdeps/i386/strrchr.S: No such file or directory.
	in ../sysdeps/i386/strrchr.S
(gdb) bt
#0  strrchr () at ../sysdeps/i386/strrchr.S:178
#1  0x080524d2 in ?? ()
#2  0x0804fb2c in ?? ()
#3  0x00170bd6 in __libc_start_main (main=0x804fb10, argc=0, 
    ubp_av=0xbffff534, init=0x805bd60, fini=0x805bd50, 
    rtld_fini=0x11e0b0 <_dl_fini>, stack_end=0xbffff52c) at libc-start.c:226
#4  0x08049cf1 in ?? ()

stack trace from lucid; glibc-2.11.1, linux 2.6.32

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Wed Mar 17 02:08:50 2010
From: report at bugs.python.org (Brian)
Date: Wed, 17 Mar 2010 01:08:50 +0000
Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and
	ElementTree
In-Reply-To: <1266327672.06.0.678108016802.issue7214@psf.upfronthosting.co.za>
Message-ID: <4a3ced361003161808n4df04215q91604db93968c40f@mail.gmail.com>


Brian <brian at merrells.org> added the comment:

What solution did you chose?  While matching cElementTree to the ElementTree
is the simplest solution I think there is some ambiguity as to the what the
preferred behavior as outlined in my original post.

-brian

On Tue, Feb 16, 2010 at 9:41 AM, Florent Xicluna <report at bugs.python.org>wrote:

>
> Changes by Florent Xicluna <laxyf at yahoo.fr>:
>
>
> ----------
> components: +XML -Library (Lib)
> nosy: +flox
> priority:  -> normal
> stage:  -> test needed
> versions: +Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7214>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16571/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7214>
_______________________________________
-------------- next part --------------
What solution did you chose? ??While matching cElementTree to the ElementTree is the simplest solution I think there is some ambiguity as to the what the preferred behavior as outlined in my original post.<div><br></div><div>

-brian<br><br><div class="gmail_quote">On Tue, Feb 16, 2010 at 9:41 AM, Florent Xicluna <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Changes by Florent Xicluna &lt;<a href="mailto:laxyf at yahoo.fr">laxyf at yahoo.fr</a>&gt;:<br>
<br>
<br>
----------<br>
components: +XML -Library (Lib)<br>
nosy: +flox<br>
priority: ??-&gt; normal<br>
stage: ??-&gt; test needed<br>
versions: +Python 2.7<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7214" target="_blank">http://bugs.python.org/issue7214</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Wed Mar 17 03:05:51 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 17 Mar 2010 02:05:51 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1268791551.18.0.993914807203.issue8077@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This doesn't look like a documentation bug to me - handling of uploaded files via CGI *should* work, even if CGI is not the best way to do that.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Wed Mar 17 04:17:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 17 Mar 2010 03:17:30 +0000
Subject: [issue8160] platform.platform() throws exception on modified debian
	distribution
In-Reply-To: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>
Message-ID: <1268795850.65.0.374454605581.issue8160@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #7773 which was fixed with r77735.

----------
nosy: +brian.curtin
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8160>
_______________________________________

From report at bugs.python.org  Wed Mar 17 04:22:42 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 17 Mar 2010 03:22:42 +0000
Subject: [issue5879] multiprocessing - example "pool of http servers " fails
	on windows "socket has no attribute fromfd"
In-Reply-To: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
Message-ID: <1268796162.54.0.0838895786924.issue5879@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5879>
_______________________________________

From report at bugs.python.org  Wed Mar 17 09:47:00 2010
From: report at bugs.python.org (Frank Rene Schaefer)
Date: Wed, 17 Mar 2010 08:47:00 +0000
Subject: [issue8153] 'set' union() fails in specific use case
In-Reply-To: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>
Message-ID: <1268815620.44.0.165630942103.issue8153@psf.upfronthosting.co.za>


Frank Rene Schaefer <fschaef at gmail.com> added the comment:

Thanks, for the comments. I got it. 

In German we would say 'I was standing on the water hose' ... 
That is, something was choking the flow of my thoughts.

Best Regards

Frank

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8153>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:09:47 2010
From: report at bugs.python.org (Jackson Yang)
Date: Wed, 17 Mar 2010 09:09:47 +0000
Subject: [issue8161] inconsistency behavior in ctypes.c_char_p dereferencing
In-Reply-To: <1268816987.2.0.0650705594073.issue8161@psf.upfronthosting.co.za>
Message-ID: <1268816987.2.0.0650705594073.issue8161@psf.upfronthosting.co.za>


New submission from Jackson Yang <jackson.yang at augmentum.com>:

# Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40)
# [MSC v.1500 32 bit (Intel)] on win32
import ctypes

class T(ctypes.Structure):
	_fields_ = (
		('member', ctypes.c_char * 16),
	)

# dereference a c_char_Array variable would return <bytes>
print('%r'%((ctypes.c_char * 16)()[:]))
# dereference from a c_char_Array member would return <str>, which is buggy
print('%r'%(T().member[:]))

----------
assignee: theller
components: ctypes
messages: 101214
nosy: nullnil, theller
severity: normal
status: open
title: inconsistency behavior in ctypes.c_char_p dereferencing
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8161>
_______________________________________

From report at bugs.python.org  Wed Mar 17 10:50:27 2010
From: report at bugs.python.org (Dan)
Date: Wed, 17 Mar 2010 09:50:27 +0000
Subject: [issue6541] SpooledTemporaryFile breakages
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1268819427.43.0.440181396594.issue6541@psf.upfronthosting.co.za>


Changes by Dan <daniel at ohuiginn.net>:


----------
nosy: +danohuiginn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:06:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 17 Mar 2010 10:06:36 +0000
Subject: [issue8162] logging.disable() incoherency
In-Reply-To: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>
Message-ID: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

I see some trouble in the semantic of logging.disable(lvl) :
according to the doc (and docstrings), it's the same as a logger.setLevel(lvl) called on all logger, but in reality it doesn't act the same way : when we call logger.setLevel(lvl), log messages at level lvl WILL be logged, whereas with logger.disable(lvl), they will NOT be logged (CF method below from logging/__init__.py).

So maybe the best would be to explain that disable() also disable the target level itself, and to set by default this disabling level to -1 (and not 0 as currently), so that by default ALL messages get loged, even those set to level 0.

    def isEnabledFor(self, level):
        """
        Is this logger enabled for level 'level'?
        """
        if self.manager.disable >= level:
            return 0
        return level >= self.getEffectiveLevel()

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 101215
nosy: georg.brandl, pakal
severity: normal
status: open
title: logging.disable() incoherency
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8162>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:22:49 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 17 Mar 2010 10:22:49 +0000
Subject: [issue8163] DictionaryServices module broken in python2.6 and later
In-Reply-To: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>
Message-ID: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

I am able to call DictionaryServices module from python2.5 and later. However it works correctly only on python2.5. Below is the stack-trace on using DictionaryServices on python2.5, python2.6 and python2.7

Shashwat-Anands-MacBook-Pro:PyObjCTest l0nwlf$ python2.5
Python 2.5.4 (r254:67916, Jul  7 2009, 23:51:24) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
>>> word = "lone wolf"
>>> DictionaryServices.DCSCopyTextDefinition(None, word, (0, len(word))) 
u'noun \na person who prefers to act or be alone. \n'
>>> 

Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
>>> word = "lone wolf"
>>> DictionaryServices.DCSCopyTextDefinition(None, word, (0, len(word)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: NSRangeException - *** -[OC_PythonString _createSubstringWithRange:]: Range or index out of bounds
>>> 

Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python2.7
Python 2.7a4+ (trunk:78750, Mar  7 2010, 08:09:00) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named DictionaryServices

----------
assignee: ronaldoussoren
components: Macintosh
messages: 101216
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: DictionaryServices module broken in python2.6 and later
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8163>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:32:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 17 Mar 2010 10:32:46 +0000
Subject: [issue8163] DictionaryServices module broken in python2.6 and later
In-Reply-To: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>
Message-ID: <1268821966.96.0.674085208026.issue8163@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This module is not part of Python stdlib. MacOSX might have bundled it by default. Reporting it to Apple might help.

----------
nosy: +orsenthil
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8163>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:35:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 10:35:35 +0000
Subject: [issue8163] DictionaryServices module broken in python2.6 and later
In-Reply-To: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>
Message-ID: <1268822135.79.0.676719068172.issue8163@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See also:
 * http://pypi.python.org/pypi/pyobjc-framework-DictionaryServices/

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8163>
_______________________________________

From report at bugs.python.org  Wed Mar 17 11:53:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 10:53:10 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268823190.08.0.474098921183.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

re-opened to track the issue on Sparc Solaris

----------
resolution: fixed -> 
stage:  -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:16:59 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 17 Mar 2010 11:16:59 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1268824619.04.0.919992274827.issue3783@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:18:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 17 Mar 2010 11:18:25 +0000
Subject: [issue1275] bsddb closing a DB object before all DBCursors using it
	are closed crashes
In-Reply-To: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za>
Message-ID: <1268824705.71.0.532589264289.issue1275@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1275>
_______________________________________

From report at bugs.python.org  Wed Mar 17 12:38:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 11:38:35 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1268825915.99.0.483109347734.issue3783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:28:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 12:28:28 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268828908.15.0.609793830314.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Checking the pybsddb 4.8.4devel with current trunk I still see this:

It is because the "test_early_close" module calls resetwarnings().
It defeats the filter in the "threading" module.

You may change the test case with a context manager:

  with warnings.catch_warnings():
      warnings.resetwarnings()
      # test the warning

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:44:07 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Mar 2010 12:44:07 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268829847.95.0.625888551795.issue8142@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

no access to solaris hardware. please could you run the libffi testsuite on this machine? make sure that expect is installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Wed Mar 17 13:56:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 12:56:21 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268830581.22.0.2100851945.issue8155@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

here come the patch.

----------
components: +Tests
keywords: +easy, patch
stage: test needed -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file16572/issue8155_check_warnings_quiet.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:38:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 17 Mar 2010 13:38:17 +0000
Subject: [issue8162] logging.disable() incoherency
In-Reply-To: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>
Message-ID: <1268833097.99.0.698805805984.issue8162@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +vinay.sajip
priority:  -> normal
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8162>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:54:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Mar 2010 13:54:33 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268834073.95.0.217793341892.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I took part of Florent latest patch, changed a few things and committed it in r79023.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Wed Mar 17 14:57:18 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Mar 2010 13:57:18 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268834238.89.0.642051449668.issue8155@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On a quick read through, the patch looks fine to me.

I actually agree it would be nice if we could keep the "quiet=True" default (since it is a better match for the feature set we want in our own tests), but I see the compatibility issue as a deal breaker for that idea.

It's probably worth adding a comment to that effect at the top of the function implementation to help people coming along later and asking "why did they choose the 'wrong' default value?".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:06:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 14:06:07 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268834767.49.0.500124198549.issue8155@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I hesitate to do it differently:

with check_warnings(('', RuntimeWarning)):
 ==> translate to check_warnings(('', RuntimeWarning), quiet=False)

with check_warnings():
 ==> translate to check_warnings(quiet=True)

If the developer passes some arguments to the function, it means that he expects some warnings, and he should not need to add "quiet=False" each time.
And it preserves backward compatibility for existing code.

I guess that we push same behavior for 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:08:48 2010
From: report at bugs.python.org (Jim Smyth)
Date: Wed, 17 Mar 2010 14:08:48 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1268834928.46.0.703156561838.issue3890@psf.upfronthosting.co.za>


Jim Smyth <jimsmyth at gmail.com> added the comment:

Is there any chance of this being resolved in time for any 2.x release? I have a non-blocking application that I recently switched over to SSL and ran into this bug. I can work around it by trying to shorten the messages and beefing up the buflen, but these solutions are not ideal.

----------
nosy: +jimsmyth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Mar 17 15:15:19 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Mar 2010 14:15:19 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268835319.11.0.265724278249.issue8155@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On a second look, there are a couple of things missing:
- the default value didn't actually get changed!
- we should add an explicit test that the no argument behaviour doesn't raise a warning by default

Since we don't really have an existing test suite for the support code, I'd suggest coopting test_sundry.py for the purpose.

I agree that an exception should be raised if the user passes in an expected warning but no warning at all is encountered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:07:14 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 15:07:14 +0000
Subject: [issue8162] logging.disable() incoherency
In-Reply-To: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>
Message-ID: <1268838434.7.0.793025404598.issue8162@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've updated the docstring and documentation to be more precise (r79026).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8162>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:08:58 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 15:08:58 +0000
Subject: [issue8034] logging: Improve error handing in
	RotatingFileHandler.doRollover()
In-Reply-To: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>
Message-ID: <1268838538.98.0.648348144221.issue8034@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closing, as no feedback received. Please feel free to reopen when you have the answer to my question!

----------
resolution:  -> invalid
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8034>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:27:06 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Mar 2010 15:27:06 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268839626.06.0.390477251026.issue8142@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the ports which are maintained separately still need an update:

libffi_msvc
  libffi trunk now has a port to x86/msvc. might require some
  extra updates from libffi.

libffi_osx:
  3.0.9 has support for darwin on powerpc and x86

libffi_wince:
  same, support seems to be included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:32:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Mar 2010 15:32:22 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1268839942.03.0.881533236999.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For anyone interested, there's an ongoing python-dev discussion about how to resolve this at

http://mail.python.org/pipermail/python-dev/2010-March/098437.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Wed Mar 17 16:34:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 17 Mar 2010 15:34:01 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1268840041.88.0.932096060006.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Sorry, Barry. Don't know what happened. Probably write a followup without reloading the page and "undid" previous changes.

I keep my issues permanently open in firefox tabs. I will try to be more careful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Wed Mar 17 17:28:32 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 17 Mar 2010 16:28:32 +0000
Subject: [issue8164] (lambda:"foo").func_doc
In-Reply-To: <1268843312.05.0.864222300962.issue8164@psf.upfronthosting.co.za>
Message-ID: <1268843312.05.0.864222300962.issue8164@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Lambdas are a bit confused about their docstrings.  Usually they don't have any, but:

    >>> (lambda x: "foo"+x).func_doc

    'foo'

----------
keywords: easy
messages: 101233
nosy: arigo
priority: low
severity: normal
status: open
title: (lambda:"foo").func_doc
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8164>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:14:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:14:33 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1268846073.3.0.615754142228.issue7512@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
nosy: +pitrou
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:17:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:17:28 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1268846248.84.0.717175281345.issue7512@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this seems to break Mercurial on NFS-mounted repositories:
http://www.selenic.com/pipermail/mercurial/2010-March/030716.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:20:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:20:07 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1268846407.67.0.326883728226.issue7512@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry, I suppose this doesn't warrant being a release blocker for 2.6.5, but in any case you're welcome to advise.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:27:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:27:50 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1268846870.05.0.129472723663.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Will apply after 2.6.5.

----------
assignee:  -> pitrou
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:28:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:28:42 +0000
Subject: [issue7682] Optimisation of if with constant expression
In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>
Message-ID: <1268846922.39.0.25220410563.issue7682@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7682>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:29:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:29:32 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1268846972.44.0.852479264047.issue2746@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox
resolution: accepted -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2746>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:31:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:31:01 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1268847061.03.0.755080747127.issue3783@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:33:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:33:24 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1268847204.87.0.389958239944.issue3580@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:33:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:33:46 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1268847226.45.0.947958973757.issue3581@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:36:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:36:35 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1268847395.58.0.687417444718.issue1518@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There probably isn't any point in such a complication, until perhaps we have a JIT that magnifies the improvement.
(but I assume the JIT will be able to treat references to globals and builtins as "frozen" using its own logic)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:41:58 2010
From: report at bugs.python.org (Collin Winter)
Date: Wed, 17 Mar 2010 17:41:58 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1268847718.18.0.140845200766.issue1518@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Antoine: yes, this optimization is already implemented in the Unladen JIT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:43:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:43:06 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1268847786.71.0.636633966698.issue1518@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks Collin, recommend closing then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:45:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:45:38 +0000
Subject: [issue477863] New gc work
Message-ID: <1268847938.74.0.510092021215.issue477863@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue477863>
_______________________________________

From report at bugs.python.org  Wed Mar 17 18:46:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 17:46:04 +0000
Subject: [issue477863] Print warning at shutdown if gc.garbage not empty
Message-ID: <1268847964.58.0.696132640518.issue477863@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
title: New gc work -> Print warning at shutdown if gc.garbage not empty
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue477863>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:14:55 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 17 Mar 2010 18:14:55 +0000
Subject: [issue8162] logging.disable() incoherency
In-Reply-To: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>
Message-ID: <1268849695.89.0.449126088247.issue8162@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Thanks you B-)

I guess it's not important if messages of severity 0 will allways be ignored with the current semantic ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8162>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:46:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 18:46:59 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268851619.97.0.904757405888.issue8155@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16572/issue8155_check_warnings_quiet.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 19:50:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 17 Mar 2010 18:50:21 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268851821.97.0.509031515963.issue8155@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch updated.

----------
Added file: http://bugs.python.org/file16573/issue8155_check_warnings_quiet_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 20:58:12 2010
From: report at bugs.python.org (Eli Courtwright)
Date: Wed, 17 Mar 2010 19:58:12 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>


New submission from Eli Courtwright <eli.courtwright at gmail.com>:

Here's a summary of the issue (also presented at http://stackoverflow.com/questions/2465073)

When I run the following code

{{{
import logging
from logging.handlers import RotatingFileHandler

rfh = RotatingFileHandler("testing.log", delay=True)
logging.getLogger().addHandler(rfh)
logging.warning("Boo!")
}}}

then the last line throws "AttributeError: RotatingFileHandler instance has no attribute 'level'".  So I add the line

{{{
rfh.setLevel(logging.DEBUG)
}}}

before the call to addHandler, and then the last line throws "AttributeError: RotatingFileHandler instance has no attribute 'filters'". So if I manually set filters to be an empty list, then it complains about not having the attribute "lock", etc.

When I remove the delay=True, the problem completely goes away.

So one of the parent __init__ methods somewhere up the class hierarchy isn't getting called when delay is set. Examining the source code to the file logging/__init__.py, I see the following code in the FileHandler.__init__ method:

{{{
if delay:
    self.stream = None
else:
    stream = self._open()
    StreamHandler.__init__(self, stream)
}}}

It looks like the FileHandler.emit method checks for un-opened streams and finishes initialization when logging is performed:

{{{
if self.stream is None:
    stream = self._open()
    StreamHandler.__init__(self, stream)
StreamHandler.emit(self, record)
}}}

So the problem is that in the BaseRotatingHandler.emit method, the shouldRollover and doRollover methods are called before emit-ing the record. This causes methods to be called which themselves assumed that the __init__ process has completed.

Unfortunately, I don't have time right now to submit a patch, though I might be able to find the time within the next few months if no one else gets to it first.  Hopefully this report is detailed enough to easily convey the problem.

----------
components: Library (Lib)
messages: 101242
nosy: Eli.Courtwright
severity: normal
status: open
title: logging.handlers.RotatingFileHandler fails when delay parameter is set to True
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:39:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Mar 2010 20:39:26 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268858366.62.0.142561054285.issue8165@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Wed Mar 17 21:43:21 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Mar 2010 20:43:21 +0000
Subject: [issue8164] (lambda:"foo").func_doc
In-Reply-To: <1268843312.05.0.864222300962.issue8164@psf.upfronthosting.co.za>
Message-ID: <1268858601.32.0.944863435563.issue8164@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79034.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8164>
_______________________________________

From report at bugs.python.org  Wed Mar 17 22:44:58 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Mar 2010 21:44:58 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268862298.04.0.64621706901.issue8155@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, I didn't notice that there were already tests for this in test_warnings (that's what I get for commenting late at night).

Updated patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Wed Mar 17 23:22:56 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 22:22:56 +0000
Subject: [issue8162] logging.disable() incoherency
In-Reply-To: <1268849695.89.0.449126088247.issue8162@psf.upfronthosting.co.za>
Message-ID: <912209.76282.qm@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

----- Original Message ----

> From: Pascal Chambon <report at bugs.python.org>

> I guess it's not important if messages 
> of severity 0 will allways be ignored with the current semantic 
> ?

Levels are supposed to be positive integers, zero is a special value indicating a level that isn't set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8162>
_______________________________________

From report at bugs.python.org  Wed Mar 17 23:51:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Mar 2010 22:51:11 +0000
Subject: [issue8104] socket.recv_into doesn't support a memoryview as an
	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268866271.18.0.176654792406.issue8104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in trunk, and additional tests ported to py3k.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8104>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:05:14 2010
From: report at bugs.python.org (Joerg Sonnenberger)
Date: Wed, 17 Mar 2010 23:05:14 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1268867114.5.0.179678635154.issue7512@psf.upfronthosting.co.za>


Joerg Sonnenberger <joerg at NetBSD.org> added the comment:

A better approach might be to change the function to:

def copystat(src, dst):
  st = os.stat(src)
  st_dst = os.stat(dst)
  mode = stat.S_IMODE(st.st_mode)
  mode_dst = stat.S_IMODE(st_dst.st_mode)
  if hasattr(os, 'utime'):
    if st.st_atime != st_dst.st_atime or st.st_mtime != st_dst.st_mtime
      os.utime(dst, (st.st_atime, st.st_mtime))
  if hasattr(os, 'chmod'):
    if mode != mode_dst:
      os.chmod(dst, mode)
  if hasattr(os, 'chflags') and hasattr(st, 'st_flags'):
    if st.st_flags != st_dst.st_flags:
      os.chflags(dst, st.st_flags)

This avoids the system calls for the (common) case of not having to change anything at all. Given that the flags are normally not set, it also avoids the problem with NFS.

----------
nosy: +joerg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:32:08 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 23:32:08 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268868728.18.0.289579179019.issue8165@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Please check that there is nothing wrong with your Python installation. I get this result:

vinay at eta-jaunty:~/projects/scratch$ ls testing.log
ls: cannot access testing.log: No such file or directory
vinay at eta-jaunty:~/projects/scratch$ cat rfhtest.py 
import logging
from logging.handlers import RotatingFileHandler

rfh = RotatingFileHandler("testing.log", delay=True)
logging.getLogger().addHandler(rfh)
logging.warning("Boo!")

vinay at eta-jaunty:~/projects/scratch$ python --version
Python 2.6.2
vinay at eta-jaunty:~/projects/scratch$ python rfhtest.py
vinay at eta-jaunty:~/projects/scratch$ cat testing.log
Boo!
vinay at eta-jaunty:~/projects/scratch$ 

I'll mark this issue as pending for now, it certainly doesn't fail for me as it does for you, can you give more information about the problem?

I'll investigate the issue based on your analysis - can you tell me more about the platform you're on? Is there an existing log file when you get the error?

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:43:16 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 23:43:16 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268869396.33.0.163780317152.issue8165@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've investigated: this issue was fixed in r68829 dated 20 Jan, 2009. This was after the release of 2.6.1 but before the release of 2.6.2.

Please upgrade to Python 2.6.2.

----------
resolution: works for me -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:45:29 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 23:45:29 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268869529.25.0.103421296263.issue8165@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've investigated: this issue was fixed in r68829 dated 20 Jan, 2009. This was after the release of 2.6.1 but before the release of 2.6.2.

Please upgrade to Python 2.6.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Thu Mar 18 00:45:47 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 17 Mar 2010 23:45:47 +0000
Subject: [issue8165] logging.handlers.RotatingFileHandler fails when delay
	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268869547.07.0.836522867752.issue8165@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8165>
_______________________________________

From report at bugs.python.org  Thu Mar 18 04:53:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 03:53:17 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

3.1.2 Release Blocker

If Python 3.1.2rc1 is built with openssl 0.9.7 (which lacks support for sha256 and sha512), hashlib is supposed to substitute use of built-in C implementations for them.  With 3.1.2rc1, the "built-in" versions are available via hashlib.new() but not by their "always available" constructor functions.  This causes major test failures in test_hashlib, test_hmac, and test_pep247.  The problem is critical for OS X installer builds because both OS X 10.4 and 10.5 ship with openssl 0.9.7 but the problem should show up on other platforms using 0.9.7 as well.

The following comparison between 2.6.5rc2 and 3.1.2rc1 demonstrates the problem:

Python 2.6.5rc2 (release26-maint, Mar 15 2010, 00:15:31) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0xd0560>
>>> hashlib.sha1()
<sha1 HASH object @ 0xd04c0>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x6b3a0>
>>> hashlib.sha512()
<_sha512.sha512 object at 0x6b480>
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1', 'openssl_sha224', 'openssl_sha256', 'openssl_sha384', 'openssl_sha512']
 
Python 3.1.2rc1+ (release31-maint, Mar 17 2010, 12:38:35) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0x11d740>
>>> hashlib.sha1()
<sha1 HASH object @ 0x11da20>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x9d640>
>>> hashlib.sha512()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'sha512'
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1']

It appears the cause of the problem was a mismatch of merges to 3.1.  In response to Issue6281, some major cleanup to hashlib.py went into trunk in r74479 and py3k in r74482 but was not backported to 2.6 or 3.1.  Later, r77608 to trunk added some conditional compilation tests in _hashopenssl.c based on openssl version, which was fine on top of the hashlib.py cleanup.  Still later, r77408 was auto-merged to py3k in r77937 (OK) *and* 3.1 in r77938 which is NOT OK, because the old hashlib.py in (3.1 and 2.6) indirectly depends on all of the openssl_* names being defined in _hashlib.

Probably the best solution for 3.1 at this point is to revert the conditional tests in _hashopenssl.c.

----------
messages: 101251
nosy: benjamin.peterson, gregory.p.smith, ned.deily, ronaldoussoren
severity: normal
status: open
title: hashlib constructors for sha224, sha256, sha384, sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Thu Mar 18 05:14:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 04:14:59 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268885699.61.0.667364978508.issue8166@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Should be: "Still later, r77608 was auto-merged [...]"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Thu Mar 18 10:09:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 09:09:39 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268903379.11.0.738556057598.issue8133@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Test failing on 3.1.2rc1.  Should this be considered a release blocker?  Perhaps just disable temporarily?

----------
nosy: +benjamin.peterson, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Thu Mar 18 10:34:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 18 Mar 2010 09:34:29 +0000
Subject: [issue8118] PYTHON_API_VERSION needs to be bumped?
In-Reply-To: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>
Message-ID: <1268904869.78.0.55249497471.issue8118@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

But should PYTHON_API_VERSION be increased for the 2.7 release?  

I think it should because of the binary incompatible differences between 2.5 and 2.6. In a perfect world that would have resulted in an increase of PYTHON_API_VERSION for the 2.6.0 release, but that's something that slipped through the cracks. By increasing the value in 2.7.0 users that switch from 2.5 to 2.7 get warnings that should help then find why their compiled extension stopped working (users migrating from 2.6 to 2.7 would also get the warning while it is technically not necessary, but that's harmless because you shouldn't reuse extensions  anyway).

The primary reason for posting this issue was that a colleague ran into this problem: he compiled an extension on a machine with python2.5 and ran the result on a machine with python2.6 and that misteriously didn't work  (in his defense: he thought that both machines ran the same version of python).  A warning at import would have made it more clear what was going wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8118>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:19:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Mar 2010 10:19:27 +0000
Subject: [issue8118] PYTHON_API_VERSION needs to be bumped?
In-Reply-To: <1268904869.78.0.55249497471.issue8118@psf.upfronthosting.co.za>
Message-ID: <1268907670.3373.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But should PYTHON_API_VERSION be increased for the 2.7 release?  

Sounds like a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8118>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:20:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 10:20:18 +0000
Subject: [issue8167] test_tk, test_ttk_guionly,
	and test_ttk_textonly crash when run from install directory
In-Reply-To: <1268907618.55.0.5671075009.issue8167@psf.upfronthosting.co.za>
Message-ID: <1268907618.55.0.5671075009.issue8167@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When installation tests are run on a user system using the OS X installer, the three tests fail with a crash.  Similar results would be expected on other unix-y platforms when tests are run from the install destination, and not the source or build directories (which do not exist on user systems using installers). On 3.1.2rc1 and py3k, each crashes on an import error:

  test test_{tk,ttk_guionly,ttk_textonly} crashed -- <class 'ImportError'>: No module named test

On trunk (2.7), they crash with;
  test test_{tk,ttk_guionly,ttk_textonly} crashed -- <type 'exceptions.ImportError'>: No module named runtktests

The problem is that the test subdirectories are not being installed by the libinstall Makefile target.  For 3.1.2rc1 and py3k, adding the directories to LIBSUBDIRS should get them installed:
  LIBSUBDIRS= tkinter site-packages test test/output test/data \
    tkinter/test tkinter/test/test_tkinter tkinter/test/test_ttk \
    test/decimaltestdata \ {...}
(Trunk is slightly different.)

----------
components: Tests
messages: 101256
nosy: benjamin.peterson, gpolo, ned.deily
severity: normal
status: open
title: test_tk, test_ttk_guionly, and test_ttk_textonly crash when run from install directory
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8167>
_______________________________________

From report at bugs.python.org  Thu Mar 18 11:43:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 10:43:01 +0000
Subject: [issue8168] python3 py_compile does not ignore UTF-8 BOM characters
In-Reply-To: <1268908981.24.0.215404983461.issue8168@psf.upfronthosting.co.za>
Message-ID: <1268908981.24.0.215404983461.issue8168@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

$ cat bom3.py
# coding: utf-8
print("BOM BOOM!")
$ file bom3.py 
bom3.py: UTF-8 Unicode (with BOM) text
$ python3.1
Python 3.1.1+ (r311:74480, Jan 20 2010, 00:37:31) 
[GCC 4.4.3 20100108 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bom3
BOM BOOM!
>>> import py_compile
>>> py_compile.compile("bom3.py")
  File "bom3.py", line 1
    ?# coding: utf-8
      ^
SyntaxError: invalid character in identifier

The same test does not fail with python2.6.4.
(Same results on OS X.)

----------
components: Library (Lib)
messages: 101257
nosy: ned.deily
severity: normal
status: open
title: python3 py_compile does not ignore UTF-8 BOM characters
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8168>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:06:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 11:06:08 +0000
Subject: [issue8169] SyntaxError messages during install due to compilation of
	lib2to3 test files
In-Reply-To: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>
Message-ID: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

On Python 3.1.2rc1 and py3k, "make install" results in two identical spurious error messages:

Compiling /path/to/lib/python3.1/lib2to3/tests/data/bom.py ...
***   File "/usr/local/lib/python3.1/lib2to3/tests/data/bom.py", line 1
    ?# coding: utf-8
      ^
SyntaxError: invalid character in identifier

The messages are triggered by the libinstall Makefile which calls compileall twice to generate .pyc and .pyo files for all modules in the installed library.  compileall uses py_compile which, due to the problem documented in Issue8168, stumbles over the lib2to3 data file bom.py.  While fixing that issue would make this problem go away, it seems like it would be better to avoid compiling the lib2to3 test files altogether.  Modifying the '-x" regexp on the two relevant calls to compileall in Makefile.pre.in accomplishes this:

-x 'bad_coding|badsyntax|site-packages|py2_test_grammar|crlf|different_encoding|lib2to3/tests' \

A similar change should be considered for trunk and 2.6 as well.

----------
components: Installation
messages: 101258
nosy: benjamin.peterson, ned.deily
severity: normal
status: open
title: SyntaxError messages during install due to compilation of lib2to3 test files
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8169>
_______________________________________

From report at bugs.python.org  Thu Mar 18 12:55:33 2010
From: report at bugs.python.org (Robin Becker)
Date: Thu, 18 Mar 2010 11:55:33 +0000
Subject: [issue8170] Wrong Paths for distutils build --plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>


New submission from Robin Becker <rgbecker at users.sourceforge.net>:

When building extensions on win32 distutils with --plat-name=win-amd64 adds PCBuild/AMD64 in the wrong place.

This patch ensures the AMD64 location comes first

----------
assignee: tarek
components: Distutils
files: patch.txt
messages: 101259
nosy: rgbecker, tarek
severity: normal
status: open
title: Wrong Paths for distutils build --plat-name=win-amd64
versions: Python 2.6
Added file: http://bugs.python.org/file16574/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8170>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:05:11 2010
From: report at bugs.python.org (Robin Becker)
Date: Thu, 18 Mar 2010 12:05:11 +0000
Subject: [issue8171] bdist_wininst builds wrongly for --plat-name=win-amd64
In-Reply-To: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>
Message-ID: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>


New submission from Robin Becker <rgbecker at users.sourceforge.net>:

I notice this from win32 setup.py bdist_wininst --plat-name=win-amd64

> running bdist_wininst
> running build
> running build_py
> creating build
> creating build\lib.win32-2.6
> creating build\lib.win32-2.6\reportlab
> copying src\reportlab\rl_config.py -> build\lib.win32-2.6\reportlab
......
> C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nolog

followed by errors related to a missing library (the amd64 version won't work with a win32 build).

I do have the x86_amd64 stuff installed and after applying a patch to fix another small cross compile error I do see a proper build ie

setup.py build --plat-name=win-amd64

and then use

setup.py bdist_wininst --plat-name=win-amd64 --skip-build 

does work. I believe that bdist_wininst is wrongly relying on build to get the right plat_name, but that isn't happening.

The attached patch seems to make things work for me by forcing plat_name down from the top

----------
assignee: tarek
components: Distutils
files: patch.txt
messages: 101260
nosy: rgbecker, tarek
severity: normal
status: open
title: bdist_wininst builds wrongly for --plat-name=win-amd64
versions: Python 2.6
Added file: http://bugs.python.org/file16575/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8171>
_______________________________________

From report at bugs.python.org  Thu Mar 18 13:29:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Mar 2010 12:29:11 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268915351.56.0.857030207893.issue8135@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed this in r79047. If we are to backport this to release26-maint, we need barry's approval. Barry, any thoughts? The change is a minor improvement, we have lived with normal case percent escape for long, mixed case would be bonus in release26.

----------
nosy: +barry
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Thu Mar 18 15:24:36 2010
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 18 Mar 2010 14:24:36 +0000
Subject: [issue8172] Documentation of Property needs example
In-Reply-To: <1268922275.96.0.934351255031.issue8172@psf.upfronthosting.co.za>
Message-ID: <1268922275.96.0.934351255031.issue8172@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Strangely, the extensive documentation of the property function in the "Built-in Functions" of the documentation has no example of the use of a property. Readers unfamiliar with properties should be told that obj.x invokes the getter, obj.x=value the setter, etc. The lack of parentheses is particularly significant.

----------
assignee: georg.brandl
components: Documentation
messages: 101262
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of Property needs example
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8172>
_______________________________________

From report at bugs.python.org  Thu Mar 18 16:44:06 2010
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Mar 2010 15:44:06 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268839626.06.0.390477251026.issue8142@psf.upfronthosting.co.za>
Message-ID: <4BA24A40.9010704@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> the ports which are maintained separately still need an update:
> 
> libffi_msvc
>   libffi trunk now has a port to x86/msvc. might require some
>   extra updates from libffi.

I'll take care of this one.
Would it be a good idea to upgrade to libffi trunk
in Modules/_ctypes/libffi, and get rid of the libffi_msvc
fork completely (by applying an additional small patch)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Thu Mar 18 16:48:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Mar 2010 15:48:28 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268927308.15.0.187168209187.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> no access to solaris hardware. please could you run the libffi
> testsuite on this machine? make sure that expect is installed.

I don't have access to such hardware.
I noticed the buildbot failures since libffi was upgraded.

----------
keywords: +buildbot
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Thu Mar 18 17:17:06 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 18 Mar 2010 16:17:06 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268929026.29.0.262829264626.issue6081@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have created a small patch, that adds method that formats using a dict. It's the first time I have written anything in python implementation, so I would very appreciate any advice. Change allows the following:

>>> m = Mapping(a='b')
>>> '{a} {c}'.format_using_mapping(m)
'b c'
>>>

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file16576/6081_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 18 17:46:22 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 18 Mar 2010 16:46:22 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268930782.63.0.112441089217.issue2698@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I'm seeing this on Python 2.6.4 on Windows XP with the latest MinGW/msys.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Mar 18 17:47:26 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 18 Mar 2010 16:47:26 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268930846.67.0.381383115482.issue2698@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Re-opening.

----------
keywords: +26backport
priority: high -> normal
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Mar 18 18:16:37 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 18 Mar 2010 17:16:37 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268932597.78.0.665489643404.issue2698@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

My bad.  Adding --compiler=mingw32 eliminates this error.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:19:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Mar 2010 18:19:44 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268936384.84.0.116403414712.issue6081@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch. It would be nice if you could include unit tests too.

----------
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:32:47 2010
From: report at bugs.python.org (Jesus Rivero)
Date: Thu, 18 Mar 2010 18:32:47 +0000
Subject: [issue7713] implement ability to disable automatic search path
	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1268937167.66.0.861955977373.issue7713@psf.upfronthosting.co.za>


Changes by Jesus Rivero <jesus.riveroa at gmail.com>:


----------
nosy: +Neurogeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:34:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Mar 2010 18:34:42 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268937282.66.0.803133908804.issue8154@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Crash reproduced under Mandriva Linux 2010.0 (glibc-2.10.1-6.2mnb2). Stack trace is as follows:

(gdb) bt
#0  0x00007fb59f2eba9a in strrchr () from /lib64/libc.so.6
#1  0x00000000004010ae in ?? ()
#2  0x0000000000400ff3 in ?? ()
#3  0x00007fb59f29091d in __libc_start_main () from /lib64/libc.so.6
#4  0x0000000000400d79 in ?? ()
#5  0x00007fff00162fa8 in ?? ()
#6  0x000000000000001c in ?? ()
#7  0x0000000000000000 in ?? ()

Also, please add the missing test when backporting the patch.

----------
nosy: +pitrou
priority:  -> high
stage:  -> patch review
type:  -> crash
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Thu Mar 18 19:47:43 2010
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Mar 2010 18:47:43 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268781878.41.0.128626610386.issue8154@psf.upfronthosting.co.za>
Message-ID: <4BA27540.3000801@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Thomas,
> 
> Do you remember why your patch for issue1039 was not backported?

Probably an oversight only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Thu Mar 18 20:11:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Mar 2010 19:11:21 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268939481.58.0.0210271459573.issue6081@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think this patch satisfies Raymond's request.  It is explicitly checking for a __missing__ attribute, but Raymond was talking about a more general facility whereby you can pass in an arbitrary object that implements the mapping interface.  Using the __missing__ facility was just an example of why this would be useful.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 18 20:27:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 18 Mar 2010 19:27:55 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268940475.15.0.888125043001.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with David.

Although it's not clear to my why the code doesn't just work with the addition of do_string_format_using_mapping and without the other code. It's possible the existing code is too dict-specific and should be calling a more generic PyObject interface, like PyMapping_GetItemString instead of PyDict_GetItem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 18 20:32:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Mar 2010 19:32:13 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268940733.04.0.863127480117.issue8154@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that this should be fixed, since we presumably want to be "strictly conforming" to the posix standards, but it looks like this is a regression in either linux or glibc.  From the standard's rational section:

Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Thu Mar 18 20:49:26 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Mar 2010 19:49:26 +0000
Subject: [issue8156] pybsddb 4.8.3+ integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1268941766.1.0.389468282038.issue8156@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

issue7975 finally reproduced. Solved in pybsddb 4.8.3+, and added relevant testcases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8156>
_______________________________________

From report at bugs.python.org  Thu Mar 18 20:50:10 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Mar 2010 19:50:10 +0000
Subject: [issue7975] dbshelve.py throws exception: AttributeError: 'DB' object
	has no attribute '__iter__'
In-Reply-To: <1266767057.06.0.0487468056966.issue7975@psf.upfronthosting.co.za>
Message-ID: <1268941810.17.0.543910710919.issue7975@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This bug was introduced in pybsddb 4.7.2, when migration to ABC (Abstract Base Classes).

I have solved it in 4.8.3+, and added relevant testcases.

I plan to integrate 4.8.3+ in Python 2.7. See issue8156.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:01:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Mar 2010 20:01:53 +0000
Subject: [issue8155] Incompatible change to test.test_support.check_warnings
	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268942513.4.0.218618670253.issue8155@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79049 and r79050.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8155>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:19:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Mar 2010 20:19:02 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268940733.04.0.863127480117.issue8154@psf.upfronthosting.co.za>
Message-ID: <d38f5331003181318p3421fe0dh70fd8136c97cfbf1@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Thu, Mar 18, 2010 at 3:32 PM, R. David Murray <report at bugs.python.org> wrote:
..
> I agree that this should be fixed, since we presumably want to be "strictly conforming" to the posix standards,
> but it looks like this is a regression in either linux or glibc. ?From the standard's rational section:
>

Let me add just make a few observations without drawing a conclusion:

1.  This is not a crash of python.  As far as I can tell, it is the
executed program that crashes attempting to dereference argv[0]
without checking argc first.   On the platforms that support execution
with argc=0, this is a bug in the application or in the C library.

2. Currently 3.x and 2.x python throw different exceptions from
os.execlp('xyz') if xyz does not exist.   Maybe os.execlp(one_arg)
should raise OSError instead of ValueError.

3. Another alternative would be to change the signature from
os.execlp(path, ...) to os.execlp(path, name, ...) and make
os.execlp() raise TypeError if name is not supplied.   This is an
attractive possibility because it can be done by a trivial change in
os.py while preserving the ability to exec with argc=0 for those who
know what they are doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:27:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 20:27:10 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268944030.72.0.807147389633.issue8166@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:37:28 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Mar 2010 20:37:28 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268944648.74.0.885250475774.issue7092@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Florent you are right, good catch. I can not use context managers because "with" is invalid syntax in python 2.3 and 2.4, that I must support for a while.

I have implemented a context manager manually, following the description in PEP 343. This change is available in pybsddb 4.8.3+. I plan to integrate pybsddb 4.8.3, see issue8156.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:38:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Mar 2010 20:38:01 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268944681.99.0.856916532239.issue7092@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Thu Mar 18 21:38:17 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 18 Mar 2010 20:38:17 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1268944697.13.0.701476865543.issue7092@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Florent you are right, good catch. I can not use context managers because "with" is invalid syntax in python 2.3 and 2.4, that I must support for a while.

I have implemented a context manager manually, following the description in PEP 343. This change is available in pybsddb 4.8.3+. I plan to integrate pybsddb 4.8.3+, see issue8156.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:01:58 2010
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 18 Mar 2010 21:01:58 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1268946118.35.0.0784800542732.issue1083@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I see the same problem when "from __future__ import division" on the 2.x series. Seem like the timedelta objects is missing the __truediv__ method.

----------
nosy: +tebeka
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:02:20 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 18 Mar 2010 21:02:20 +0000
Subject: [issue8156] pybsddb 4.8.3+ integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1268946140.77.0.364143489115.issue8156@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8156>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:21:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 21:21:25 +0000
Subject: [issue8169] SyntaxError messages during install due to compilation of
	lib2to3 test files
In-Reply-To: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>
Message-ID: <1268947285.15.0.218939868102.issue8169@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Hopefully fixed in r79051. Can you try the 3.1 branch?

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8169>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:23:34 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 21:23:34 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268947414.52.0.48312311396.issue8166@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:25:55 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Thu, 18 Mar 2010 21:25:55 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1268947555.41.0.290182208907.issue6081@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

My first intention was simply to push mapping from args to kwargs, just like Eric suggested, but that didn't help with __missing__, only with accepting a dict instead of pushing keyword arguments.

I didn't like explicitly asking for __missing__ either, but since I have little knowledge of what should be called, I didn't know what to use. I too believe something else the PyDict_GetItem should be called, something that would take care of __missing__ and other possibilities (I don't know what exactly and really would like to know what these are) internally.

I am going to check, whether PyMapping_GetItemString is going to help. But can this really be called on a dict (or a subclass of dict)? What about retrieving getitem method from the given object and simply calling it? Wouldn't that do the trick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:27:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 21:27:52 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268947672.77.0.261964810463.issue8166@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Nice catch! Reverted in r79054.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:33:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 21:33:20 +0000
Subject: [issue8167] test_tk, test_ttk_guionly,
	and test_ttk_textonly crash when run from install directory
In-Reply-To: <1268907618.55.0.5671075009.issue8167@psf.upfronthosting.co.za>
Message-ID: <1268948000.31.0.804875848895.issue8167@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79056.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8167>
_______________________________________

From report at bugs.python.org  Thu Mar 18 22:49:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Mar 2010 21:49:23 +0000
Subject: [issue8173] test_subprocess leaks
In-Reply-To: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>
Message-ID: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_subprocess has been leaking since the recent changes in py3k:

test_subprocess leaked [2, 2] references, sum=4

----------
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 101286
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_subprocess leaks
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8173>
_______________________________________

From report at bugs.python.org  Thu Mar 18 23:13:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Mar 2010 22:13:04 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268950384.77.0.530359456309.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done with r79059 and r79062.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Thu Mar 18 23:39:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 22:39:32 +0000
Subject: [issue8168] python3 py_compile does not ignore UTF-8 BOM characters
In-Reply-To: <1268908981.24.0.215404983461.issue8168@psf.upfronthosting.co.za>
Message-ID: <1268951972.85.0.542492071144.issue8168@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79068.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8168>
_______________________________________

From report at bugs.python.org  Thu Mar 18 23:53:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 22:53:40 +0000
Subject: [issue8169] SyntaxError messages during install due to compilation of
	lib2to3 test files
In-Reply-To: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>
Message-ID: <1268952820.06.0.604782138949.issue8169@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

'bad_coding' is still needed in the -x regexp.  BTW, it's easy enough to test by doing something like:
   make install DESTDIR=/tmp/p/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8169>
_______________________________________

From report at bugs.python.org  Thu Mar 18 23:57:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Mar 2010 22:57:18 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268953038.07.0.946507521953.issue7643@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file15806/issue7643_remove_deprecation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Thu Mar 18 23:58:00 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 18 Mar 2010 22:58:00 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268953080.95.0.570149789421.issue7643@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:01:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 23:01:53 +0000
Subject: [issue8169] SyntaxError messages during install due to compilation of
	lib2to3 test files
In-Reply-To: <1268952820.06.0.604782138949.issue8169@psf.upfronthosting.co.za>
Message-ID: <1afaf6161003181601q5ece3f77h36685f75e5f94dfc@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/3/18 Ned Deily <report at bugs.python.org>:
>
> Ned Deily <nad at acm.org> added the comment:
>
> 'bad_coding' is still needed in the -x regexp. ?BTW, it's easy enough to test by doing something like:
> ? make install DESTDIR=/tmp/p/

Ok. :) Refixed in r79076.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8169>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:13:16 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Mar 2010 23:13:16 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1268953996.44.0.42111857676.issue6837@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Promoted warning to full DeprecationWarning in r79078.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6837>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:21:19 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 23:21:19 +0000
Subject: [issue8166] hashlib constructors for sha224, sha256, sha384,
	sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268954479.23.0.194747519834.issue8166@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fix verified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8166>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:46:06 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 18 Mar 2010 23:46:06 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268955966.3.0.985875356184.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

This bug was confirmed to no longer be present for Python 2.6.4, however it is still present for Python 3.1.1. Could someone with "open" privileges re-open this please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 00:48:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Mar 2010 23:48:19 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268956099.88.0.791167935366.issue7643@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file15807/issue7643_use_LineBreak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Mar 19 01:31:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 00:31:02 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268958662.39.0.686646187747.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Cleanup committed as r78982

Patch for LineBreak.txt updated after UCD upgrade to 5.2.
See details: http://bugs.python.org/issue7643#msg97483

Tests added to test_unicodedata.

Backward compatibility concern:
 * it adds VT u'\x0b' and FF u'\x0c' as line breaks.

The choice is either to preserve backward compatibility, or to comply with the specification (UAX #14).

----------
priority:  -> normal
Added file: http://bugs.python.org/file16577/issue7643_use_LineBreak_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Mar 19 02:14:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Mar 2010 01:14:54 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268961294.04.0.58433296713.issue2698@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 02:25:34 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 19 Mar 2010 01:25:34 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1268961934.12.0.503996955845.issue2445@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Shouldn't the import library name end with .lib?  I've run up against this building PyLucene with MinGW.  There seems to be code to figure this out already in CygwinCCompiler, but it's commented out (and arguably incomplete).

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Fri Mar 19 02:30:52 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 19 Mar 2010 01:30:52 +0000
Subject: [issue8173] test_subprocess leaks
In-Reply-To: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>
Message-ID: <52dc1c821003181830s69e10224mebfdc8954154c8ff@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Pretty sure I know off the top of my head what this is.  Ill fix it.

----------
Added file: http://bugs.python.org/file16578/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8173>
_______________________________________
-------------- next part --------------
<p>Pretty sure I know off the top of my head what this is.?? Ill fix it.</p>
<p>--<br>
Tapped out or dictated on my Nexus One.</p>
<p><blockquote type="cite">On Mar 18, 2010 2:49 PM, &quot;Antoine Pitrou&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
New submission from Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt;:<br>
<br>
test_subprocess has been leaking since the recent changes in py3k:<br>
<br>
test_subprocess leaked [2, 2] references, sum=4<br>
<br>
----------<br>
assignee: gregory.p.smith<br>
components: Library (Lib), Tests<br>
messages: 101286<br>
nosy: gregory.p.smith, pitrou<br>
priority: normal<br>
severity: normal<br>
stage: needs patch<br>
status: open<br>
title: test_subprocess leaks<br>
type: resource usage<br>
versions: Python 3.2<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8173" target="_blank">http://bugs.python.org/issue8173</a>&gt;<br>
_______________________________________<br>
</blockquote></p>

From report at bugs.python.org  Fri Mar 19 02:34:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 01:34:04 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268962444.4.0.0935644393252.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Reverted in 3.x: it triggers some failures.

Symptoms:
 * repr('\uaaa') gives an empty string
 * test_bigmem fails

----------
resolution: fixed -> accepted
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 02:57:36 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 01:57:36 +0000
Subject: [issue8174] Misleading reported number of given arguments on function
	call TypeError
In-Reply-To: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>
Message-ID: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

The following exception message seems misleading, or at least not obvious:

>>> def f(a,b,c): pass
... 
>>> f(c=0,a=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 3 non-keyword arguments (1 given)

Why "1 given" ? One could argue for either 0 or 2 given arguments but I fail to see how 1 is a reasonable answer.

----------
components: Interpreter Core
messages: 101298
nosy: gsakkis
severity: normal
status: open
title: Misleading reported number of given arguments on function call TypeError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8174>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:41:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Mar 2010 02:41:10 +0000
Subject: [issue8174] Misleading reported number of given arguments on function
	call TypeError
In-Reply-To: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>
Message-ID: <1268966470.82.0.787823946893.issue8174@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #6474.

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8174>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:41:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Mar 2010 02:41:59 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1268966519.97.0.445417708396.issue6474@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, gsakkis
superseder:  -> Misleading reported number of given arguments on function call TypeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:42:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Mar 2010 02:42:52 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1268966572.19.0.10652945087.issue6474@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
superseder: Misleading reported number of given arguments on function call TypeError -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:43:41 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 19 Mar 2010 02:43:41 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268966621.68.0.916311874472.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Craig, 

did you run the command like this under 3.x ? :

$ python setup.py build --compiler=mingw32 --verbose

Also, what is your gcc version ? and your PATH environment ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 03:56:14 2010
From: report at bugs.python.org (Craig McQueen)
Date: Fri, 19 Mar 2010 02:56:14 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268967374.86.0.704069191966.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I ran it as follows:

    \python31\python.exe setup.py build --compiler=mingw32 --verbose

and got:

running build
running build_py
running build_ext
building 'cobs._cobsext' extension
error: Unable to find vcvarsall.bat

If I run:

    gcc --version

I get:

gcc (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Path:
PATH=C:\Program Files\CollabNet\Subversion Server;C:\WINNT\Microsoft.NET\Framewo
rk\v1.1.4322\;C:\WINNT\system32;C:\WINNT;C:\Program Files\Microsoft Visual Studi
o 8\VC\bin;C:\Program Files\Subversion\bin;C:\Program Files\IVI Foundation\IVI\b
in;C:\Program Files\IVI Foundation\VISA\WinNT\Bin\;C:\PROGRA~1\IVIFOU~1\VISA\Win
NT\Bin;C:\Program Files\IVI Foundation\VISA\WinNT\Bin;c:\python26\;C:\Program Fi
les\TortoiseSVN\bin;C:\Program Files\TortoiseHg;c:\MinGW\bin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 04:02:28 2010
From: report at bugs.python.org (Craig McQueen)
Date: Fri, 19 Mar 2010 03:02:28 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268967748.46.0.496987130726.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

And, I should add, doing nearly the same thing, except with Python 2.6.4, works fine. Same machine, same console window, same path:

    \python26\python.exe setup.py build --compiler=mingw32 --verbose

running build
running build_py
running build_ext
building 'cobs._cobsext' extension
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python26\include -IC:\Pytho
n26\PC -c src/_cobsext2.c -o build\temp.win32-2.6\Release\src\_cobsext2.o
writing build\temp.win32-2.6\Release\src\_cobsext.def
c:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\src\_co
bsext2.o build\temp.win32-2.6\Release\src\_cobsext.def -LC:\Python26\libs -LC:\P
ython26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\cobs\_cobsext.pyd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 04:30:32 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 03:30:32 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1268969432.95.0.460103941222.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

I reverted the function to the original API (return just the dict with the bindings), cleaned it up, wrote thorough unit tests and made a patch against Python 2.7a4.

----------
keywords: +patch
Added file: http://bugs.python.org/file16579/getcallargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:28:15 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 19 Mar 2010 04:28:15 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1268972895.02.0.0128207094759.issue8068@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Does this still affect 2.6 then?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar 19 05:32:04 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 19 Mar 2010 04:32:04 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1268973124.83.0.560095661888.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Benjamin, can I fix this bug before you tag 3.1.2 ?

Basically, I'll apply on 3.1 what was applied on 2.6 :

MacZiade:release31-maint tarek$ svn di
Index: Lib/distutils/command/build_ext.py
===================================================================
--- Lib/distutils/command/build_ext.py  (r?vision 79090)
+++ Lib/distutils/command/build_ext.py  (copie de travail)
@@ -310,7 +310,7 @@
 
         # Setup the CCompiler object that we'll use to do all the
         # compiling and linking
-        self.compiler = new_compiler(compiler=None,
+        self.compiler = new_compiler(compiler=self.compiler,
                                      verbose=self.verbose,
                                      dry_run=self.dry_run,
                                      force=self.force)


Then, after you have tagged 3.1, I will revert distutils in py3 branch so it's back to 3.1 state then frozen, like what I am doing for 2.7.

----------
nosy: +benjamin.peterson
resolution: rejected -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:01:53 2010
From: report at bugs.python.org (Chris Carter)
Date: Fri, 19 Mar 2010 05:01:53 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268974913.02.0.921484189978.issue7643@psf.upfronthosting.co.za>


Chris Carter <jesdisciple at gmail.com> added the comment:

unwatched

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:05:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Mar 2010 05:05:33 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1268975133.04.0.505900221719.issue3135@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:09:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Mar 2010 05:09:02 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1268975342.15.0.38706254178.issue6474@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:09:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Mar 2010 05:09:30 +0000
Subject: [issue8174] Misleading reported number of given arguments on function
	call TypeError
In-Reply-To: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>
Message-ID: <1268975370.74.0.872557774293.issue8174@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8174>
_______________________________________

From report at bugs.python.org  Fri Mar 19 06:24:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Mar 2010 05:24:29 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1268976269.48.0.568343517724.issue3690@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:08:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 06:08:55 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1268978935.94.0.705200703033.issue8068@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This does not need to be a release blocker for 2.6.5; it can safely be applied post-release.  The 2.6 version of the installer script has had the most attention paid to it since the most recent Python releases - and the only ones since OS X 10.6 was released - have been 2.6.x ones.  These patches make all four versions identical going forward and add the latest 2.6 fixes to the others.  It should be a release blocker for 3.1.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:09:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 19 Mar 2010 06:09:08 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1268978948.24.0.88884269574.issue8068@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Barry: these patches affect 2.6, but can easily wait for 2.6.6: its basically sync-ing the OSX package-building infrastructure between the 4 active Python branches. This does not directly affect anything seen by users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar 19 07:57:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 06:57:07 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1268981827.86.0.396594403064.issue7643@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy:  -Chris.Carter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Mar 19 08:17:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 19 Mar 2010 07:17:31 +0000
Subject: [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1268983051.59.0.302804177514.issue8151@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8151>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:31:01 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2010 08:31:01 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1268962444.4.0.0935644393252.issue8024@psf.upfronthosting.co.za>
Message-ID: <4BA33641.1040907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
> Reverted in 3.x: it triggers some failures.
> 
> Symptoms:
>  * repr('\uaaa') gives an empty string
>  * test_bigmem fails

repr() for Unicode doesn't use the Unicode database. Are you sure that
those errors are related to the upgrade ?

Looking closer at the patch, you also changed the unicodetype mappings
and since this removes a lot of entries, it looks like the Unicode
consortium either moved some mappings out of the UCD file into a
separate file or made some massive changes to the code point properties
(which is unlikely).

If that's the case, please also revert the Python 2.7 checkin.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:36:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Mar 2010 08:36:31 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1268987791.62.0.119724670422.issue3690@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't think there's anything worth fixing here.  It's true that getsizeof is sometimes going to return results that are too small, because there are a good few places in the longobject internals where it's not predictable in advance exactly how much space is needed, so memory is overallocated.

The case of the small int 0 is one example of this, but it's far from the only one.  For example, if you multiply a 2-limb long by another 2-limb long the code will always allocate 4 limbs for the result, even though it'll often turn out that the result fits in 3 limbs.  Should sys.getsizeof return base_size + 4 * sizeof_limb in that case, instead of base_size + 3 * sizeof_limb?  That would be difficult to achieve, since long objects don't currently know how much space was actually allocated to hold them.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Fri Mar 19 09:48:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 08:48:43 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268988523.39.0.930486500121.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The bug was a side-effect of the update. Code point "\uAAAA" is now assigned to a printable character:

  AAAA;TAI VIET LETTER LOW VO;Lo;0;L;;;;;N;;;;;

And test_bigmem relies on this code point being non-printable.
I changed it for a char in the Low surrogates range, which is guaranteed not printable. See attached patch.

The regression test suite passes flawlessly.

I will do further tests before merging back in 3.x

----------
keywords: +patch
Added file: http://bugs.python.org/file16580/issue8024_UCD_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:09:28 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Fri, 19 Mar 2010 09:09:28 +0000
Subject: [issue8048] doctest assumes sys.displayhook hasn't been touched
In-Reply-To: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>
Message-ID: <1268989768.92.0.204052672432.issue8048@psf.upfronthosting.co.za>


Noam Yorav-Raphael <noamraph at gmail.com> added the comment:

Here is a better and much shorter patch: I use sys.__displayhook__ instead of implementing it in Python, which has the nice side effect of not changing pdb behaviour.

----------
Added file: http://bugs.python.org/file16581/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8048>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:20:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Mar 2010 09:20:43 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1268990443.03.0.263372584968.issue3690@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing this as "won't fix", then.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:21:45 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 19 Mar 2010 09:21:45 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1268990505.32.0.750134805869.issue8024@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Looking closer at the patch, you also changed the unicodetype mappings
> and since this removes a lot of entries, it looks like the Unicode
> consortium either moved some mappings out of the UCD file into a
> separate file or made some massive changes to the code point
> properties (which is unlikely).

Does it? On the contrary, it seems to me that with r79059, unicodetype_db.h grown by 200 lines.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:25:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2010 09:25:37 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1268988523.39.0.930486500121.issue8024@psf.upfronthosting.co.za>
Message-ID: <4BA34319.3060809@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
> The bug was a side-effect of the update. Code point "\uAAAA" is now assigned to a printable character:
> 
>   AAAA;TAI VIET LETTER LOW VO;Lo;0;L;;;;;N;;;;;
> 
> And test_bigmem relies on this code point being non-printable.
> I changed it for a char in the Low surrogates range, which is guaranteed not printable. See attached patch.

That's better.

You wrote about '\?aaa' (3 'a's) in your previous post
on the ticket and I didn't understand why that would change with the
patch, since it's basically a SyntaxError which doesn't have anything
to do with the Unicode types or database.

> The regression test suite passes flawlessly.
> 
> I will do further tests before merging back in 3.x

Please also check what happened to all those code points that were
removed by the patch in unicodetype_db.h.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:27:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Mar 2010 09:27:10 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1268990505.32.0.750134805869.issue8024@psf.upfronthosting.co.za>
Message-ID: <4BA34377.5050108@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> Looking closer at the patch, you also changed the unicodetype mappings
>> and since this removes a lot of entries, it looks like the Unicode
>> consortium either moved some mappings out of the UCD file into a
>> separate file or made some massive changes to the code point
>> properties (which is unlikely).
> 
> Does it? On the contrary, it seems to me that with r79059, unicodetype_db.h grown by 200 lines.

Ooops :-) I now realized that I was looking at the patch reverting
the change.

Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:36:45 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 09:36:45 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268991405.76.0.518330870002.issue8089@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Fri Mar 19 10:54:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 09:54:48 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268992488.16.0.072507290012.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Per discussion with Ronald and Benjamin, attaching a revised patch (issue-sl-configure-32-31-rev3.txt) for 3.1 which ports the changes committed in r78813 and r78816 along with the Mac/README changes.

In the process of producing the revised 3.1 patch, I discovered that the 2.6 changes as committed produce a build error for the 10.5 --with-universal-archs=all (4-way) variant.  The 3.1 revised patch corrects that error.  Since 2.6.5 is now frozen, I am opening a new issue with patch for 2.6.5.

I recommend that, once the 3.1 patch is applied for 3.1.2, this issue be closed and any new or remaining issues be tracked in new or other existing issues.

----------
Added file: http://bugs.python.org/file16582/issue-sl-configure-32-31-rev3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Fri Mar 19 11:10:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 10:10:20 +0000
Subject: [issue8175] 2.6.5 OS X 10.5 --with-universal-archs=all (4-way) fails
	building pythonw-64
In-Reply-To: <1268993420.16.0.372615905731.issue8175@psf.upfronthosting.co.za>
Message-ID: <1268993420.16.0.372615905731.issue8175@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

A change made to Mac/Makefile in r78813 for 2.6.5 does not work correctly
when the --with-universal-archs=all (4-way) framework configure option is selected.  The build of pythonw-64 fails with an incorrect gcc command: "gcc-4.0   64 -arch x86_64".  The attached patch corrects the problem.

Note, as documented in the 2.6.5 Mac/README file, the "all" variant can currently only be built on OS X 10.5.
         
Run autoconf after applying to update configure.

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: issue-universal-archs-all-26.txt
messages: 101318
nosy: barry, ned.deily, ronaldoussoren
severity: normal
status: open
title: 2.6.5 OS X 10.5 --with-universal-archs=all (4-way) fails building pythonw-64
versions: Python 2.6
Added file: http://bugs.python.org/file16583/issue-universal-archs-all-26.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8175>
_______________________________________

From report at bugs.python.org  Fri Mar 19 11:14:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 10:14:17 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268993657.06.0.491630765139.issue8089@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(2.6.5 -> Issue8175)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Fri Mar 19 11:41:08 2010
From: report at bugs.python.org (Carlos Ribeiro)
Date: Fri, 19 Mar 2010 10:41:08 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>


New submission from Carlos Ribeiro <carribeiro at gmail.com>:

I was running Django in development mode (python manage.py runserver 0.0.0.0:8002). I saved a python source file; Django automatically detected the change and reloaded the module (that's the usual behavior). Then a backtrace from glibc appeared in the middle of the log. Django web server kept running, so I assume that the bug hit a separate thread. I also assume that this is a Python bug due to the nature of the trace (came from glibc). That's all information that I have.

---- python version ----
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

---- trace ----
Django version 1.1.1, using settings 'camg.settings'
Development server is running at http://0.0.0.0:8002/
Quit the server with CONTROL-C.
[18/Mar/2010 22:50:23] "GET / HTTP/1.1" 200 27012
[18/Mar/2010 22:50:23] "GET /static/css/camg.css HTTP/1.1" 304 0
[18/Mar/2010 22:50:23] "GET /static/images/consorciomg.png HTTP/1.1" 304 0
[18/Mar/2010 22:52:01] "GET /andar/SEC1-3/ HTTP/1.1" 200 6441
[18/Mar/2010 22:52:06] "GET /switch/SEC1-3-3A-SA01/ HTTP/1.1" 200 6546
[18/Mar/2010 22:52:11] "GET /sala/3/ HTTP/1.1" 500 69619
[18/Mar/2010 22:52:13] "GET /switch/SEC1-3-3A-SA01/ HTTP/1.1" 200 6546
*** glibc detected *** /usr/bin/python: double free or corruption (out): 0xb7651b80 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0x17aff1]
/lib/tls/i686/cmov/libc.so.6[0x17c6f2]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x17f7cd]
/usr/bin/python[0x80b9ceb]
/usr/bin/python[0x808e622]
/usr/bin/python[0x808e634]
/usr/bin/python[0x806a42b]
/usr/bin/python[0x808e634]
/usr/bin/python[0x808cf19]
/usr/bin/python(PyDict_SetItem+0x87)[0x808f377]
/usr/bin/python(_PyModule_Clear+0x99)[0x8090c49]
/usr/bin/python(PyImport_Cleanup+0x459)[0x80edaf9]
/usr/bin/python(Py_Finalize+0xa5)[0x80fa305]
/usr/bin/python[0x80f9daf]
/usr/bin/python(PyErr_PrintEx+0x18d)[0x80f9f9d]
/usr/bin/python(PyErr_Print+0x12)[0x80fa1d2]
/usr/bin/python(PyRun_SimpleFileExFlags+0x1ab)[0x80facfb]
/usr/bin/python(Py_Main+0xaa8)[0x805c8d8]
/usr/bin/python(main+0x1b)[0x805baeb]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x126b56]
/usr/bin/python[0x805ba31]
======= Memory map: ========
00110000-0024e000 r-xp 00000000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
0024e000-0024f000 ---p 0013e000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
0024f000-00251000 r--p 0013e000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
00251000-00252000 rw-p 00140000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
00252000-00255000 rw-p 00000000 00:00 0 
00255000-00382000 r-xp 00000000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
00382000-0038a000 r--p 0012c000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
0038a000-00397000 rw-p 00134000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
00397000-0039b000 rw-p 00000000 00:00 0 
0039b000-003bc000 r-xp 00000000 08:01 1749       /usr/lib/libpq.so.5.2
003bc000-003bd000 r--p 00020000 08:01 1749       /usr/lib/libpq.so.5.2
003bd000-003be000 rw-p 00021000 08:01 1749       /usr/lib/libpq.so.5.2
003be000-003c0000 r-xp 00000000 08:01 560        /lib/libcom_err.so.2.1
003c0000-003c1000 r--p 00001000 08:01 560        /lib/libcom_err.so.2.1
003c1000-003c2000 rw-p 00002000 08:01 560        /lib/libcom_err.so.2.1
003c2000-003e8000 r-xp 00000000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003e8000-003e9000 ---p 00026000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003e9000-003ea000 r--p 00026000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003ea000-003eb000 rw-p 00027000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003eb000-003f1000 r-xp 00000000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f1000-003f2000 r--p 00005000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f2000-003f3000 rw-p 00006000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f3000-00400000 r-xp 00000000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00400000-00401000 r--p 0000c000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00401000-00402000 rw-p 0000d000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00402000-0041a000 r-xp 00000000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041a000-0041b000 r--p 00017000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041b000-0041c000 rw-p 00018000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041c000-004bf000 r-xp 00000000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004bf000-004c3000 r--p 000a2000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004c3000-004c4000 rw-p 000a6000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004c4000-004d0000 r-xp 00000000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d0000-004d1000 r--p 0000b000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d1000-004d2000 rw-p 0000c000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d2000-004e5000 r-xp 00000000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e5000-004e6000 r--p 00012000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e6000-004e7000 rw-p 00013000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e7000-004e9000 rw-p 00000000 00:00 0 
004e9000-004f2000 r-xp 00000000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f2000-004f3000 r--p 00008000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f3000-004f4000 rw-p 00009000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f9000-0053a000 r-xp 00000000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053a000-0053b000 ---p 00041000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053b000-0053c000 r--p 00041000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053c000-0053f000 rw-p 00042000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053f000-005b8000 r-xp 00000000 08:01 581        /lib/libgcrypt.so.11.5.2
005b8000-005b9000 r--p 00078000 08:01 581        /lib/libgcrypt.so.11.5.2
005b9000-005bb000 rw-p 00079000 08:01 581        /lib/libgcrypt.so.11.5.2
005bb000-005d7000 r-xp 00000000 08:01 3077       /lib/libgcc_s.so.1
005d7000-005d8000 r--p 0001b000 08:01 3077       /lib/libgcc_s.so.1
005d8000-005d9000 rw-p 0001c000 08:01 3077       /lib/libgcc_s.so.1
005e9000-005ea000 r-xp 00000000 00:00 0          [vdso]
00639000-00642000 r-xp 00000000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00642000-00643000 r--p 00008000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00643000-00644000 rw-p 00009000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00644000-0066b000 rw-p 00000000 00:00 0 
0068e000-00690000 r-xp 00000000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00690000-00691000 r--p 00001000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00691000-00692000 rw-p 00002000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00697000-00699000 r-xp 00000000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
00699000-0069a000 r--p 00001000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
0069a000-0069b000 rw-p 00002000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
00774000-00788000 r-xp 00000000 08:01 681        /lib/libz.so.1.2.3.3
00788000-00789000 r--p 00013000 08:01 681        /lib/libz.so.1.2.3.3
00789000-0078a000 rw-p 00014000 08:01 681        /lib/libz.so.1.2.3.3
00841000-00851000 r-xp 00000000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00851000-00852000 r--p 00010000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00852000-00853000 rw-p 00011000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00853000-00855000 rw-p 00000000 00:00 0 
0089f000-008a1000 r-xp 00000000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008a1000-008a2000 r--p 00001000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008a2000-008a3000 rw-p 00002000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008ea000-00905000 r-xp 00000000 08:01 67         /lib/ld-2.10.1.so
00905000-00906000 r--p 0001a000 08:01 67         /lib/ld-2.10.1.so
00906000-00907000 rw-p 0001b000 08:01 67         /lib/ld-2.10.1.so
00940000-00950000 r-xp 00000000 08:01 4761       /usr/lib/libtasn1.so.3.1.5

----------
components: Interpreter Core
messages: 101320
nosy: Carlos.Ribeiro
severity: normal
status: open
title: Interpreter crash with "double free or corruption" message
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Fri Mar 19 11:46:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Mar 2010 10:46:51 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1268995611.39.0.345685824585.issue8176@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python was displaying an error: did you saw the error? I don't know where Django logs stderr.

Could you also run Python in verbose mode? Set PYTHONVERBOSE=2 environment variable. It should write useful informations before the crash.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Fri Mar 19 12:17:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 11:17:48 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268997468.76.0.434098504446.issue8142@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Adding Ronald for OS X.)

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 12:18:18 2010
From: report at bugs.python.org (Carlos Ribeiro)
Date: Fri, 19 Mar 2010 11:18:18 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995611.39.0.345685824585.issue8176@psf.upfronthosting.co.za>
Message-ID: <864d37091003190417k28243a50r2b5f6cda8c37f94d@mail.gmail.com>


Carlos Ribeiro <carribeiro at gmail.com> added the comment:

I know I have little information but unfortunately I couldn't reproduce the
crash. Seems like a racing condition or something similar. I'll see what I
can do about it.

On Fri, Mar 19, 2010 at 07:46, STINNER Victor <report at bugs.python.org>wrote:

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> Python was displaying an error: did you saw the error? I don't know where
> Django logs stderr.
>
> Could you also run Python in verbose mode? Set PYTHONVERBOSE=2 environment
> variable. It should write useful informations before the crash.
>
> ----------
> nosy: +haypo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8176>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16584/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________
-------------- next part --------------
I know I have little information but unfortunately I couldn&#39;t reproduce the crash. Seems like a racing condition or something similar. I&#39;ll see what I can do about it.<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 07:46, STINNER Victor <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
STINNER Victor &lt;<a href="mailto:victor.stinner at haypocalc.com">victor.stinner at haypocalc.com</a>&gt; added the comment:<br>
<br>
Python was displaying an error: did you saw the error? I don&#39;t know where Django logs stderr.<br>
<br>
Could you also run Python in verbose mode? Set PYTHONVERBOSE=2 environment variable. It should write useful informations before the crash.<br>
<br>
----------<br>
nosy: +haypo<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8176" target="_blank">http://bugs.python.org/issue8176</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Carlos Ribeiro<br>Consultoria em Projetos<br>twitter: <a href="http://twitter.com/carribeiro">http://twitter.com/carribeiro</a><br>blog: <a href="http://rascunhosrotos.blogspot.com">http://rascunhosrotos.blogspot.com</a><br>

mail: <a href="mailto:carribeiro at gmail.com">carribeiro at gmail.com</a><br>

From report at bugs.python.org  Fri Mar 19 14:10:53 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 19 Mar 2010 13:10:53 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269004253.69.0.463384661929.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I believe this patch fixes the issue. Tests and documentation are still needed, of course.

----------
Added file: http://bugs.python.org/file16585/issue6081.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:16:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 19 Mar 2010 13:16:44 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269004604.01.0.733023676795.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Added a comment to explain the change.

----------
Added file: http://bugs.python.org/file16586/issue6081.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:16:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 19 Mar 2010 13:16:49 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269004609.32.0.348463790673.issue6081@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file16585/issue6081.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:20:33 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 13:20:33 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269004833.81.0.841693933946.issue3135@psf.upfronthosting.co.za>


Changes by George Sakkis <george.sakkis at gmail.com>:


Removed file: http://bugs.python.org/file16579/getcallargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:22:58 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 13:22:58 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269004978.94.0.687252154213.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Renamed the Testcase classes to conform with the rest in test_inspect.py, added a few more tests for tuple args and patched against the latest trunk (r79086).

----------
Added file: http://bugs.python.org/file16587/getcallargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 14:51:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Mar 2010 13:51:03 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269006663.09.0.682036941104.issue3135@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch will also need docs in inspect.rst.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 15:45:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 14:45:57 +0000
Subject: [issue8024] upgrade to Unicode 5.2
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1269009957.95.0.198645727396.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Merged with r79093

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Mar 19 15:46:02 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 19 Mar 2010 14:46:02 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269009962.91.0.749580070816.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

commited to the trunk, commit to the 2.6 branch pending

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:04:06 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 19 Mar 2010 15:04:06 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1269011046.8.0.0361314077907.issue8142@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

On 18.03.2010 16:44, Thomas Heller wrote:
> 
> Thomas Heller<theller at ctypes.org>  added the comment:
> 
>> the ports which are maintained separately still need an update:
>>
>> libffi_msvc
>>    libffi trunk now has a port to x86/msvc. might require some
>>    extra updates from libffi.
> 
> I'll take care of this one.
> Would it be a good idea to upgrade to libffi trunk
> in Modules/_ctypes/libffi, and get rid of the libffi_msvc
> fork completely (by applying an additional small patch)?

I'm attaching the patch for an update from the trunk; it passes the ctypes tests and the libffi testsuite on i486-linux-gnu.

We should revert the following chunk for configure.ac to generate the Makefile's again, so that we are able to run the testsuite at least with dejagnu:

-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/ffi.h)

----------
keywords: +patch
Added file: http://bugs.python.org/file16588/libffi-update2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:17:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 19 Mar 2010 15:17:31 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1269011851.26.0.953998620997.issue7860@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#7347 depends on this for proper testing, and arch_misrepresented.diff seems to have been labeled as acceptable. Would anyone be willing to check it in?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Fri Mar 19 16:51:20 2010
From: report at bugs.python.org (Ghislain Hivon)
Date: Fri, 19 Mar 2010 15:51:20 +0000
Subject: [issue8177] Incoherent error with keyword argument follow by
	unpacking argument lists
In-Reply-To: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>
Message-ID: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>


New submission from Ghislain Hivon <jahed_g at hotmail.com>:

Take a fonction with a parameter and  *args
def foo(bar, args*)
  pass

then call it like this
myargs = [1, 2, 3, 4, 5]
foo(bar=1, *myargs)

The call produce this error : 
TypeError: foo() got multiple values for keyword argument 'bar'

Sould the error be more like : 
SyntaxError: non-keyword arg after keyword arg

the same error if foo was called like this : 
foo(bar=1, myargs)
or
foo(bar=1, 1, 2, 3, 4, 5)

----------
components: Interpreter Core
messages: 101332
nosy: GhislainHivon
severity: normal
status: open
title: Incoherent error with  keyword argument follow by unpacking argument lists
versions: Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8177>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:20:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 19 Mar 2010 16:20:09 +0000
Subject: [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1269015609.96.0.416964233286.issue8151@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This was fixed in r78206 for trunk, but it doesn't look like it made it's way into any of the other branches.

----------
nosy: +brian.curtin
priority:  -> low
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8151>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:32:01 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 16:32:01 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1269016321.54.0.917463035694.issue6474@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Which version are you running ? I don't get the "positional" word in 2.6 and 2.7a4.

In my opinion it should report how many required arguments are passed, regardless of how they are passed (positionally or by name). So in your example it should say "1 given" in both examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:34:21 2010
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 19 Mar 2010 16:34:21 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1269011046.8.0.0361314077907.issue8142@psf.upfronthosting.co.za>
Message-ID: <4BA3A786.1050507@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> We should revert the following chunk for configure.ac to generate the Makefile's again, so that we are able to run the testsuite at least with dejagnu:
> 
> -AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc)
> +AC_CONFIG_FILES(include/ffi.h)

Can you make this change, run autoconf (I have only version 2.64 but 2.65 is needed), and commit please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 17:54:08 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 19 Mar 2010 16:54:08 +0000
Subject: [issue8173] test_subprocess leaks
In-Reply-To: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>
Message-ID: <1269017648.46.0.490350012382.issue8173@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

py3k r79097

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8173>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:25:25 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 17:25:25 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1269019525.38.0.196783506469.issue6474@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Attached patch for displaying the number of missing required arguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file16589/6474.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:53:40 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 19 Mar 2010 17:53:40 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1269021220.07.0.533210731723.issue8142@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> Can you make this change, run autoconf, and commit please?

done, and updated the patch for the merge from the trunk.

----------
Added file: http://bugs.python.org/file16590/libffi-update3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 18:53:55 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 19 Mar 2010 17:53:55 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1269021235.22.0.325925288037.issue8142@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


Removed file: http://bugs.python.org/file16588/libffi-update2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:13:03 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 18:13:03 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269022383.49.0.743204425923.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

- Added docs in inspect.rst
- Fixed TypeError message for zero-arg functions ("takes no arguments" instead of "takes exactly 0 arguments") + added test.

----------
Added file: http://bugs.python.org/file16591/getcallargs2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 19:41:57 2010
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 19 Mar 2010 18:41:57 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1269021220.07.0.533210731723.issue8142@psf.upfronthosting.co.za>
Message-ID: <4BA3C570.7090807@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> done, and updated the patch for the merge from the trunk.
> 
> ----------
> Added file: http://bugs.python.org/file16590/libffi-update3.diff

This patch passes the ctypes tests and libffi testsuite on this system:

  Linux tubu64 2.6.24-27-generic #1 SMP Fri Mar 12 00:52:19 UTC 2010 x86_64 GNU/Linux

Please apply.  And thanks for all the help...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Fri Mar 19 21:57:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Mar 2010 20:57:08 +0000
Subject: [issue8133] test_imp fails on OS X 10.6; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269032228.25.0.804256566099.issue8133@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> brett.cannon
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:34:49 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Mar 2010 21:34:49 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269034489.07.0.164327107183.issue3135@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Would you upload this patch to Rietveld for review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:39:03 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 19 Mar 2010 21:39:03 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269034743.66.0.257096894838.issue6081@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Could you point me, where to add tests and documentation? I would happily add those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:39:24 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Mar 2010 21:39:24 +0000
Subject: [issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in
	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1269034764.04.0.585268988921.issue8089@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed 3.1 in r79117.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8089>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:40:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 21:40:07 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269034807.3.0.537061189337.issue8133@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(BTW, the problem exists on other versions of OS X, not just 10.6.)

----------
title: test_imp fails on OS X 10.6; filename normalization issue. -> test_imp fails on OS X; filename normalization issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:43:21 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Mar 2010 21:43:21 +0000
Subject: [issue8068] OS X Installer: merge python2 and python3
	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1269035001.56.0.461552937185.issue8068@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I applied the update in r79119. Thanks!

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8068>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:49:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 19 Mar 2010 21:49:00 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269035340.05.0.0220963571544.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

http://docs.python.org/library/stdtypes.html#str.format, for starters. This is in Doc/library/stdtypes.rst.

For tests, probably in Lib/test/test_unicode.py.

I'm not sure if we should add this to 2.7 (or even 3.2, for that matter), but if so, we should start by patching trunk and then porting to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 22:58:23 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 19 Mar 2010 21:58:23 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1269035903.18.0.467963529564.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Done for 3.1.x in r79121.

I am now waiting for 3.1.2 to be taggued, then I'll revert the 3.x branch into a state the closest possible to 3.1.x.

Next, Distutils will be feature-frozen in 3.x like it is in 2.x, as things are now happening in distutils2. Only bugs fixes will happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:31:14 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 22:31:14 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269037874.73.0.429692317365.issue3135@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Uploaded at http://codereview.appspot.com/659041/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:33:15 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Fri, 19 Mar 2010 22:33:15 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269037995.09.0.914469944818.issue6081@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Ok, unfortunately this code won't work for certain tests. Take those:

        self.assertEqual("My name is {0}".format('Fred'), "My name is Fred")

We pass only one argument, which is a dict and this won't satisfy such test. We need to think about a different way of passing those arguments there. We can do one of two thins:
* the last argument of args tuple would be an object that can be subscripted for format values
* keyword with above object

I believe the second version is more explicit and therefore better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Fri Mar 19 23:58:08 2010
From: report at bugs.python.org (Stein Magnus Jodal)
Date: Fri, 19 Mar 2010 22:58:08 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1269039488.16.0.612532388408.issue4892@psf.upfronthosting.co.za>


Changes by Stein Magnus Jodal <stein.magnus at jodal.no>:


----------
nosy: +jodal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Sat Mar 20 00:12:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 19 Mar 2010 23:12:12 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1269040332.16.0.0698898198877.issue7755@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Sat Mar 20 00:12:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 19 Mar 2010 23:12:23 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1269040343.34.0.193397630459.issue3928@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Sat Mar 20 00:54:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 23:54:56 +0000
Subject: [issue8178] test_thread fails on POSIX
In-Reply-To: <1269042896.82.0.574285527551.issue8178@psf.upfronthosting.co.za>
Message-ID: <1269042896.82.0.574285527551.issue8178@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The test fails randomly on POSIX platforms since r78527 (fixing issue #7242).
The failure is in the new TestCase: TestForkInThread.


 $ ./python -m test.regrtest -uall -R :: test_thread
test_thread
beginning 9 repetitions
123456789
Unhandled exception in thread started by <function thread1 at 0x26c3f78>
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 218, in thread1
    os.close(self.write_fd)
OSError: [Errno 9] Bad file descriptor
.Unhandled exception in thread started by <function thread1 at 0x2863ae0>
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 218, in thread1
    os.close(self.write_fd)
OSError: [Errno 9] Bad file descriptor
test test_thread failed -- Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 120, in test__count
    self.assertEquals(thread._count(), orig + 1)
AssertionError: 1 != 2

1 test failed:
    test_thread
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

----------
components: Library (Lib), Tests
messages: 101350
nosy: flox, gregory.p.smith, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_thread fails on POSIX
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8178>
_______________________________________

From report at bugs.python.org  Sat Mar 20 01:22:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 00:22:04 +0000
Subject: [issue8178] test_thread fails on POSIX
In-Reply-To: <1269042896.82.0.574285527551.issue8178@psf.upfronthosting.co.za>
Message-ID: <1269044524.09.0.839098532606.issue8178@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79127 and r79128.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8178>
_______________________________________

From report at bugs.python.org  Sat Mar 20 02:24:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Mar 2010 01:24:11 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1269048251.12.0.2438638281.issue7860@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think it is actually pretty straightforward to write a *unit* test for this.  We just need to check that the logic works correctly given the expected presence or absence of the environment variables.  That doesn't test whether or not the right thing happens in the environment when you actually run a WOW64, but I don't think it is Python's responsibility to test that.  If Microsoft changes the API, platform will break and the tests won't notice, but I don't think there's anything we can do about that, since as you say the API is the only way to find out what to expect for results.

Test patch attached.  Brian, if you can confirm that this test fails before your patch and succeeds afterward, I will commit both patches.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
Added file: http://bugs.python.org/file16592/uname_WOW64_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:11:50 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 02:11:50 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1269051110.96.0.60860452732.issue2548@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

The final word on this seems to be this:

   - Wait until when we aren't in a beta release.  (DONE)

   - Quoting:

   Well, For Py3K at least we might need to consider going through the C
   API and fixing it so that these incorrect assumptions that functions
   like PyDict_GetItem() make are no longer made by introducing some new
   functions that behave in a "better" way.

   And for the recursion issue, I think it stems from corners that are
   cut in the C API by us. We inline functions all over the place, assume
   that Python's implementation underneath the hood is going to make
   calls that stay in C, etc. But as time has gone on and we have added
   flexibility to Python, more and more places have a chance to call
   Python code and trigger issues.

from Brett's e-mail at:

   http://mail.python.org/pipermail/python-dev/2008-August/082107.html

Anyone up to trying to make the C API changes required to get this
resolved?

Sean

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:19:15 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 20 Mar 2010 02:19:15 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269051555.26.0.334802676643.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

committed to the 2.6 branch as well

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:19:54 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 02:19:54 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1269051594.36.0.531060636638.issue7443@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Andrew: There have been changes committed within the last week to #7712, which Florent suggested might be related.  Can you please re-test this to see if it still exists, and if it does, bug me and I'll try to get some more movement on this.

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7443>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:20:22 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 20 Mar 2010 02:20:22 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1269051622.89.0.361146436316.issue4961@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

committed to the 2.6 branch as well

----------
assignee: gpolo -> 
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4961>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:21:22 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 20 Mar 2010 02:21:22 +0000
Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on
	the locale
In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za>
Message-ID: <1269051682.04.0.369456450848.issue7356@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

committed to the 2.6 branch as well

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7356>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:41:43 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 02:41:43 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1269052903.55.0.436264944592.issue2356@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I've posted to python-dev asking for a reviewer for this, the thread is at http://mail.python.org/pipermail/python-dev/2010-March/098597.html

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:44:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Mar 2010 02:44:39 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1269053079.63.0.538563360749.issue2356@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Sean, are you referring to the warning or the 2to3 fixer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:44:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Mar 2010 02:44:52 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1269053092.88.0.73522106423.issue2356@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: collinwinter -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:53:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 02:53:17 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

On Mac OS X 10.6.2


======================================================================
ERROR: test_realpath (__main__.MacCommonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-back/Lib/test/test_genericpath.py", line 213, in test_realpath
    self.assertIn("foo", self.pathmodule.realpath("foo"))
  File "/compile/python-back/Lib/macpath.py", line 209, in realpath
    path = Carbon.File.FSResolveAliasFile(path, 1)[0].as_pathname()
Error: (-43, 'File not found')

----------------------------------------------------------------------
Ran 19 tests in 0.087s

FAILED (errors=1, skipped=1)
Traceback (most recent call last):
  File "Lib/test/test_macpath.py", line 57, in <module>
    test_main()
  File "Lib/test/test_macpath.py", line 53, in test_main
    test_support.run_unittest(MacPathTestCase, MacCommonTest)
  File "/compile/python-back/Lib/test/test_support.py", line 1031, in run_unittest
    _run_suite(suite)
  File "/compile/python-back/Lib/test/test_support.py", line 1014, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/compile/python-back/Lib/test/test_genericpath.py", line 213, in test_realpath
    self.assertIn("foo", self.pathmodule.realpath("foo"))
  File "/compile/python-back/Lib/macpath.py", line 209, in realpath
    path = Carbon.File.FSResolveAliasFile(path, 1)[0].as_pathname()
Error: (-43, 'File not found')

----------
assignee: ronaldoussoren
messages: 101360
nosy: michael.foord, ronaldoussoren
severity: normal
stage: needs patch
status: open
title: Test failure in test_macpath.py test_realpath (Mac OS X)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:56:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 02:56:03 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I'm *assuming* this is a Mac OS X issue. (10.6.2)

./python.exe Lib/test/test_pep277.py
test_directory (__main__.UnicodeFileTests) ... ok
test_failures (__main__.UnicodeFileTests) ... ok
test_listdir (__main__.UnicodeFileTests) ... FAIL
test_open (__main__.UnicodeFileTests) ... ok
test_rename (__main__.UnicodeFileTests) ... ok

======================================================================
FAIL: test_listdir (__main__.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 92, in test_listdir
    self.assertEqual(sf2, set(self.files))
AssertionError: Items in the first set but not the second:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03b1\u0301-\u03c3\u03b1\u03c2'
u'@test_969_tmp/Gru\u0308\xdf-Gott'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0438\u0306\u0442\u0435'
u'@test_969_tmp/\u306b\u307b\u309a\u3093'
Items in the second set but not the first:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'
u'@test_969_tmp/Gr\xfc\xdf-Gott'
u'@test_969_tmp/\u306b\u307d\u3093'

----------------------------------------------------------------------
Ran 5 tests in 0.021s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 120, in <module>
    test_main()
  File "Lib/test/test_pep277.py", line 115, in test_main
    test_support.run_unittest(UnicodeFileTests)
  File "/compile/python-back/Lib/test/test_support.py", line 1031, in run_unittest
    _run_suite(suite)
  File "/compile/python-back/Lib/test/test_support.py", line 1014, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 92, in test_listdir
    self.assertEqual(sf2, set(self.files))
AssertionError: Items in the first set but not the second:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03b1\u0301-\u03c3\u03b1\u03c2'
u'@test_969_tmp/Gru\u0308\xdf-Gott'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0438\u0306\u0442\u0435'
u'@test_969_tmp/\u306b\u307b\u309a\u3093'
Items in the second set but not the first:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'
u'@test_969_tmp/Gr\xfc\xdf-Gott'
u'@test_969_tmp/\u306b\u307d\u3093'

----------
assignee: ronaldoussoren
messages: 101361
nosy: michael.foord, ronaldoussoren
severity: normal
status: open
title: Unicode File Test failures (PEP 277 on Mac OS X)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 03:56:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 02:56:27 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269053787.35.0.0132430161578.issue8180@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
stage:  -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 04:03:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 03:03:36 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1269054216.05.0.0472676461381.issue7832@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed in revision 79132.

For Python 2.7 I renamed assertSameElements to assertItemsEqual (assertSameElements has never been released on 2.X). In 3.2 assertItemsEqual will be new and assertSameElements will be de-documented / deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Sat Mar 20 06:10:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Mar 2010 05:10:26 +0000
Subject: [issue5649] OS X Installer: only include PythonSystemFixes package if
	target includes 10.3
In-Reply-To: <1238600445.94.0.804009523794.issue5649@psf.upfronthosting.co.za>
Message-ID: <1269061826.67.0.763952781665.issue5649@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the installer build updates referenced by Issue8068, PythonSystemFixes is now only included in installers targeted for 10.3.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5649>
_______________________________________

From report at bugs.python.org  Sat Mar 20 06:44:47 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 20 Mar 2010 05:44:47 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1269063887.44.0.667402341636.issue7347@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Why the *Ex names? Can't we just add additional arguments to the original names?

The Python names do not necesarily have to match the API calls. Having QueryValue and QueryValueEx was a mistake in the first place, and I would prefer not continuing doing such things.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Sat Mar 20 07:01:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Mar 2010 06:01:53 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269064913.31.0.420232717512.issue8179@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This failure seems to be caused by major changes to test_macpath.  I'm not sure how much of this is really applicable to macpath which implements the obsolete MacOS 9 path functions.  Perhaps leave well enough alone?

----------
nosy: +flox, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sat Mar 20 07:17:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Mar 2010 06:17:22 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269065842.58.0.244387318717.issue8180@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

r78585 to test_pep277.py recently enabled this test for all POSIX systems but note the warning in r33595.

----------
nosy: +flox, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:15:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 09:15:06 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269076506.8.0.664847570072.issue8179@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The changes enabled more tests for all *path related modules.

Please try attached patch.

----------
components: +Macintosh
keywords: +patch
priority:  -> normal
resolution:  -> accepted
type:  -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file16593/issue8179_macpath_realpath.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:18:55 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 09:18:55 +0000
Subject: [issue8181] Guenstiger kaufen Sie Software nicht!
In-Reply-To: <8471975994.84GBKROP240377@kzjfnunsukjauhs.ahext.com>
Message-ID: <8471975994.84GBKROP240377@kzjfnunsukjauhs.ahext.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Kaufen Sie nur beste Software hier!

Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie  Programme, die Sie in Ihrem  Computer haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. 
Sparen Sie wirklich! Kaufen Sie Hier Programme!

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Orangeitect LTD
3398 Hemlock Lane
Jersey City NJ 7304

Copyright (C) 2010 Orangeitect LTD All rights reserved.

----------
files: unnamed
messages: 101368
nosy: nobody
severity: normal
status: open
title: Guenstiger kaufen Sie Software nicht!
Added file: http://bugs.python.org/file16594/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8181>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=Windows-1252">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://ryfutitotudspaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Kaufen Sie nur beste Software hier!</h1>
				    <p>Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie  Programme, die Sie in Ihrem  Computer haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. </p><a href="http://ryfutitotud.spaces.live.com">Sparen Sie wirklich! Kaufen Sie Hier Programme!</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://ryfutitotud.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://ryfutitotud.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Orangeitect LTD<br>3398 Hemlock Lane<br>Jersey City NJ 7304</p>
					    <p>Copyright (C) 2010 Orangeitect LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 10:19:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 09:19:22 +0000
Subject: [issue8181] Guenstiger kaufen Sie Software nicht!
Message-ID: <1269076762.76.0.88513949351.issue8181@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8181>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:19:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 09:19:25 +0000
Subject: [issue8181] Guenstiger kaufen Sie Software nicht!
Message-ID: <1269076765.83.0.855786354824.issue8181@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16594/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8181>
_______________________________________

From report at bugs.python.org  Sat Mar 20 10:19:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 09:19:41 +0000
Subject: [issue8181] spam
Message-ID: <1269076781.21.0.961499983225.issue8181@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
title: Guenstiger kaufen Sie Software nicht! -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8181>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:04:37 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 20 Mar 2010 10:04:37 +0000
Subject: [issue8128] String interpolation with unicode subclass fails to call
	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1269079477.83.0.426610370898.issue8128@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I've assumed that the documentation is correct, and that "%s"%obj should call __str__ for unicode objects as well as everything else.

Attached in a test file.

----------
Added file: http://bugs.python.org/file16595/test_interpolation.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8128>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:53:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 10:53:56 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269082436.1.0.849073592042.issue8180@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch should fix the test on OS X platforms.

----------
components: +Macintosh, Unicode
keywords: +patch
priority:  -> normal
resolution:  -> accepted
stage: needs patch -> patch review
type:  -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file16596/issue8180_pep277_darwin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 11:54:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 10:54:47 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269082487.59.0.219404669126.issue8179@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sat Mar 20 13:10:32 2010
From: report at bugs.python.org (Jelly Chen)
Date: Sat, 20 Mar 2010 12:10:32 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266854368.51.0.157548124545.issue7977@psf.upfronthosting.co.za>
Message-ID: <c37e78d81003200510w71e2ea78n9bf6c2d84f19254d@mail.gmail.com>


Jelly Chen <sinojelly at gmail.com> added the comment:

I know why those two tests run failed, and I found another way to solve the
problem, do not make the existing tests broken, and at the same time I have
added another test case.
I encountered this problem due to a argument is already being a tuple but
re-packaged into another tuple, It appears a high probability. Maybe modify
the client.py according to this patch is a solution.

2010/2/22 Florent Xicluna <report at bugs.python.org>

>
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
>
> Attached, the output of the test with "-v test_xmlrpc".
>
> ----------
> Added file: http://bugs.python.org/file16308/issue7977_test_xmlrpc.log
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7977>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16597/unnamed
Added file: http://bugs.python.org/file16598/dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________
-------------- next part --------------
<div><span class="Apple-style-span" style="font-family: Arial, sans-serif; font-size: 13px; line-height: 22px; "><span title="????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????">I know why those two tests run failed, and I found another way to solve the problem, do not make the existing tests broken, and at the same time I have added another test case.<br>
</span><span title="?????????????????????????????????????????????tuple????????????????????????????????????tuple???">I encountered this problem due to a argument is already being a tuple but re-packaged into another tuple, It appears a high probability. Maybe modify the client.py according to this patch is a solution.</span></span><br>
<br><div class="gmail_quote">2010/2/22 Florent Xicluna <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Florent Xicluna &lt;<a href="mailto:laxyf at yahoo.fr">laxyf at yahoo.fr</a>&gt; added the comment:<br>
<br>
Attached, the output of the test with &quot;-v test_xmlrpc&quot;.<br>
<br>
----------<br>
Added file: <a href="http://bugs.python.org/file16308/issue7977_test_xmlrpc.log" target="_blank">http://bugs.python.org/file16308/issue7977_test_xmlrpc.log</a><br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7977" target="_blank">http://bugs.python.org/issue7977</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Contact me: &nbsp;<br>QQ: 2578717<br>MSN: <a href="mailto:sinojelly at msn.cn">sinojelly at msn.cn</a><br>???????????????<a href="http://t.sina.com.cn/sinojelly">http://t.sina.com.cn/sinojelly</a><br>
???????????????<a href="http://sinojelly.20x.cc">http://sinojelly.20x.cc</a><br><br><br>
</div>
-------------- next part --------------
diff -Nur old\test\test_xmlrpc.py new\test\test_xmlrpc.py
--- old\test\test_xmlrpc.py	Thu Aug 13 18:30:32 2009
+++ new\test\test_xmlrpc.py	Sat Mar 20 19:39:48 2010
@@ -478,6 +478,14 @@
         # This avoids waiting for the socket timeout.
         self.test_simple1()
 
+    def test_call_with_tuple_param(self):
+        def execute(server, methodname, *args):
+            r = getattr(server, methodname)(args) # params become a tuple
+            return r
+        p = xmlrpclib.ServerProxy(URL)
+        r = execute(p, "add", 4,7)
+        self.assertEqual(r, 11)
+
 # This is a contrived way to make a failure occur on the server side
 # in order to test the _send_traceback_header flag on the server
 class FailingMessageClass(http.client.HTTPMessage):
diff -Nur old\xmlrpc\client.py new\xmlrpc\client.py
--- old\xmlrpc\client.py	Thu Jun 04 17:11:52 2009
+++ new\xmlrpc\client.py	Sat Mar 20 19:41:03 2010
@@ -49,6 +49,7 @@
 # 2003-07-12 gp  Correct marshalling of Faults
 # 2003-10-31 mvl Add multicall support
 # 2004-08-20 mvl Bump minimum supported Python version to 2.1
+# 2010-03-20 cgd Avoid to make a tuple to be another tuple(Chenguodong email:sinojelly at gmail.com)
 #
 # Copyright (c) 1999-2002 by Secret Labs AB.
 # Copyright (c) 1999-2002 by Fredrik Lundh.
@@ -1026,6 +1027,9 @@
     def __getattr__(self, name):
         return _Method(self.__send, "%s.%s" % (self.__name, name))
     def __call__(self, *args):
+        # Fixed by sinojelly: if args[0] is a tuple, should not make it to be another tuple.
+        if len(args) == 1 and type(args[0]) is type(()):
+            args = args[0]
         return self.__send(self.__name, args)
 
 ##

From report at bugs.python.org  Sat Mar 20 14:16:49 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 20 Mar 2010 13:16:49 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1269091009.16.0.270788002802.issue4037@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I have fixed the issue with line length, and taken Brian's advice re valname. Updated patch for doctest and test.test_doctest2 is attached.

----------
Added file: http://bugs.python.org/file16599/doctest_patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4037>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:19:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Mar 2010 14:19:44 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269094784.08.0.639743634921.issue8154@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe that backporting this change to 2.6 is inappropriate.  It will more than likely cause perfectly correct code to stop working, and that is not something we like to do in a maintenance release.

I believe that the bug on the debian/ubuntu side is actually that /bin/true crashes if argc is 0.  Someone with a debian or ubuntu system should test this.

In fact, reviewing this issue again after Alexander's post to python-dev, I don't think that this fix in its current form is advisable at all.  It makes Python's execv function less flexible than the underlying system API, and more importantly changes its behavior in a backwards incompatible way.  Python 3 is a different story in this regard, since the change went in before 3.1, and as noted it makes Python "strictly compliant" with the posix standard, which seems like an acceptable reason to decrease flexibility.

Since it does trigger a crash on the windows equivalent API, the check should be conditional on platform.  And it should generate a py3k warning on other platforms.

I'm open to an argument that the API can be changed in 2.7, although I don't think we normally do that without a deprecation first.  But I think there is no question that this change in its current form needs to be backed out of 2.6.

----------
resolution: fixed -> 
stage: patch review -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sat Mar 20 15:28:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Mar 2010 14:28:53 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1269095333.66.0.712011000097.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

RegDeleteKeyEx will only work on a Windows version of 5.2 or greater (Vista/XP x64), and XP is 5.1, so RegDeleteKeyEx can't be a simple drop-in under the "DeleteKey" name.

CreateKeyEx is different though since it goes as far back as Win2k, and it could be put into CreateKey like you suggest. However, given the way the rest of the module is laid out with *Key and *KeyEx already, it seemed more consistent the way I had written it. I could change this if more people agree with your plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:54:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 15:54:56 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269100496.27.0.579591496718.issue8180@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

A patch with more Unicode normalization tests.

Could you test it on Windows or Mac OS X?

----------
Added file: http://bugs.python.org/file16600/issue8180_pep277_additions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 16:55:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 15:55:44 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269100544.94.0.582454547108.issue8180@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:13:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Mar 2010 16:13:03 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1269101583.55.0.288838231702.issue2356@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Committed the 2to3 fixer in r79137.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:41:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 16:41:12 +0000
Subject: [issue8182] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1269103272.68.0.0151167142477.issue8182@psf.upfronthosting.co.za>
Message-ID: <1269103272.68.0.0151167142477.issue8182@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

$ ./python.exe Lib/test/test_imp.py 
test_find_module_encoding (__main__.ImportTests) ... ok
test_issue1267 (__main__.ImportTests) ... ok
test_issue3594 (__main__.ImportTests) ... ok
test_issue5604 (__main__.ImportTests) ... ERROR
test_builtin (__main__.ReloadTests) ... ok
test_extension (__main__.ReloadTests) ... ok
test_source (__main__.ReloadTests) ... ok
testLock (__main__.LockTests) ... ok

======================================================================
ERROR: test_issue5604 (__main__.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?

----------------------------------------------------------------------
Ran 8 tests in 0.032s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 194, in <module>
    test_main()
  File "Lib/test/test_imp.py", line 191, in test_main
    support.run_unittest(*tests)
  File "/compile/python3-back/Lib/test/support.py", line 997, in run_unittest
    _run_suite(suite)
  File "/compile/python3-back/Lib/test/support.py", line 980, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?


Could be related to issue 8180 perhaps? 

In addition, if I run this test in an ascii terminal, unittest dies trying to output the failure message:

  File "/compile/python3-back/Lib/unittest/runner.py", line 150, in run
    result.printErrors()
  File "/compile/python3-back/Lib/unittest/runner.py", line 105, in printErrors
    self.printErrorList('ERROR', self.errors)
  File "/compile/python3-back/Lib/unittest/runner.py", line 113, in printErrorList
    self.stream.writeln("%s" % err)
  File "/compile/python3-back/Lib/unittest/runner.py", line 21, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 197: ordinal not in range(128)

Should unittest be fixed to be able to handle this? (Output '\u...' style strings when there is an encoding error in the TextTestRunner / TextTestResult.)

----------
assignee: ronaldoussoren
messages: 101377
nosy: brett.cannon, michael.foord, ronaldoussoren
severity: normal
status: open
title: test_imp.py test failures on Py3K Mac OS X
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8182>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:42:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Mar 2010 16:42:06 +0000
Subject: [issue8182] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1269103272.68.0.0151167142477.issue8182@psf.upfronthosting.co.za>
Message-ID: <1269103326.25.0.199130897469.issue8182@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_imp fails on OS X; filename normalization issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8182>
_______________________________________

From report at bugs.python.org  Sat Mar 20 17:50:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 16:50:24 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269103824.38.0.170719902433.issue8133@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Note: issue #8180 is related to the same NFC/NFD issue.
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

----------
components: +Macintosh, Unicode
nosy: +flox
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:07:03 2010
From: report at bugs.python.org (Ben Artin)
Date: Sat, 20 Mar 2010 17:07:03 +0000
Subject: [issue8183] warn crashes if warning's __str__ returns Unicode
In-Reply-To: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>
Message-ID: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>


New submission from Ben Artin <ba000484 at artins.org>:

Running the following script crashes my 2.6.1 interpreter on two different platforms:

from warnings import warn

class TestWarning(Warning):
	def __str__(self):
		return u'\u00ae'

warn(TestWarning())

Platforms I tried this on:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

Python 2.6.1 (r261:67515, Dec 17 2008, 20:25:07) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6

Crash backtrace on Mac OS X:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.python.python             	0x0000000100059e4c PyTuple_Pack + 154
1   org.python.python             	0x00000001000794c1 PyErr_Warn + 468
2   org.python.python             	0x000000010007922b _PyUnicodeUCS2_IsNumeric + 5504
3   org.python.python             	0x0000000100079fc8 PyErr_WarnExplicit + 1113
4   org.python.python             	0x00000001000951df PyEval_EvalFrameEx + 15001
5   org.python.python             	0x0000000100096ccf PyEval_EvalCodeEx + 1803
6   org.python.python             	0x0000000100096d62 PyEval_EvalCode + 54
7   org.python.python             	0x00000001000ae65a Py_CompileString + 78
8   org.python.python             	0x00000001000b04dd PyRun_InteractiveOneFlags + 503
9   org.python.python             	0x00000001000b0615 PyRun_InteractiveLoopFlags + 206
10  org.python.python             	0x00000001000b0685 PyRun_AnyFileExFlags + 76
11  org.python.python             	0x00000001000bc286 Py_Main + 2718
12  python                        	0x0000000100000e6c start + 52

----------
components: Library (Lib)
messages: 101379
nosy: bromine
severity: normal
status: open
title: warn crashes if warning's __str__ returns Unicode
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8183>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:08:52 2010
From: report at bugs.python.org (news1234)
Date: Sat, 20 Mar 2010 17:08:52 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>


New submission from news1234 <news1234 at free.fr>:

Following code snippet will behave differently on Linux and windows hosts.

Under linux the script can only be run once.
The second call will raise an exception, as the previous program is
already listening to pot 8089.


Under Windows however the program can be started twice.
and will print twice "serving". This surprises me

The script:
# ##########################
import socket,sys
from multiprocessing.managers import BaseManager

mngr = BaseManager(address=('127.0.0.1',8089),authkey='verysecret')
try:
    srvr = mngr.get_server()
except socket.error as e:
    print "probably address already in use"
    sys.exit()
print "serving"
srvr.serve_forever()


Perhaps the reason for the problem might be related to
http://bugs.python.org/issue2550


I'd suggest to fix multiprocessing.managers.BaseManager such, that it behaves identially on both platforms.

----------
components: Library (Lib), Windows
messages: 101380
nosy: news1234
severity: normal
status: open
title: multiprocessing.managers will not fail if listening ocket already in use
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8184>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:21:00 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sat, 20 Mar 2010 17:21:00 +0000
Subject: [issue8185] re.findall()
In-Reply-To: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>
Message-ID: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

>>> sys.version
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit
(Intel)]
>>> import re
>>> re.match("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4").group()
1.23e-4
>>> re.search("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4").group()
1.23e-4
>>> for e in re.finditer("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4"):
        print e.group()
        
1.23e-4

but

>>> re.findall("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4")
['e-4']
>>> 

It seems re.findall() does not like patterns containing parentheses.

>>> re.findall("[-+]?[0-9]+[.]?[0-9]*[eE][-+]?[0-9]+", "1.23e-4")
['1.23e-4']
>>> 
>>> re.findall("a(b)?", "ab")
['b']
>>> re.findall("ab?", "ab")
['ab']
>>>

----------
components: Regular Expressions
messages: 101381
nosy: jmfauth
severity: normal
status: open
title: re.findall()
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8185>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:27:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 17:27:21 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269106041.83.0.592429781961.issue8133@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Could you tell if the patch fix the issue?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16601/issue8133_test_imp.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:31:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 17:31:34 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269106294.4.0.819015647953.issue8133@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That patch works for me.

(You should probably commit the comment fix in the patch separately though, rather than mixing it up with this issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:36:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Mar 2010 17:36:55 +0000
Subject: [issue8183] warn crashes if warning's __str__ returns Unicode
In-Reply-To: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>
Message-ID: <1269106615.66.0.652418086541.issue8183@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I cannot reproduce this with python 2.6.4 or trunk on linux.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8183>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:44:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Mar 2010 17:44:28 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1269107068.45.0.096984795251.issue2550@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2550>
_______________________________________

From report at bugs.python.org  Sat Mar 20 18:55:43 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 17:55:43 +0000
Subject: [issue8186] Hohe Qualitaet und beste Preise garantiert.
In-Reply-To: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>
Message-ID: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}Email not displaying correctly? View it in your browser.      Bei uns kaufst Du beste Software guenstig.

Unsere Kunde  erhalten ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  
Neue Software zu einem guenstigen Preis

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Bitdog LTD
3221 Neville Street
Los Angeles CA 90017

Copyright (C) 2010 Bitdog LTD All rights reserved.

----------
files: unnamed
messages: 101385
nosy: nobody
severity: normal
status: open
title: Hohe Qualitaet und beste Preise garantiert.
Added file: http://bugs.python.org/file16602/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8186>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">

<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
<body class="background">
<div id="wrap" class="background">
<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
<tr>
<td id="header" mc:edit="header" colspan="3">
<span>Email not displaying correctly? <a href="http://wymavydi.spaces.live.com" target="_blank">View it in your browser.</a></span>
</td>
</tr>
<tr>
  <td id="lead_content" mc:edit="main" colspan="3">
    <h1 class="primary-heading">Bei uns kaufst Du beste Software guenstig.</h1>
    <p>Unsere Kunde  erhalten ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  </p><a href="http://wymavydi.spaces.live.com">Neue Software zu einem guenstigen Preis</a><br>
  </td>
</tr>
  <tr>
<td id="footer" mc:edit="footer" colspan="3" class="background">
    <p><a href="http://wymavydi.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://wymavydi.spaces.live.com">Update your profile</a></p>

<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

    <p>Bitdog LTD<br>3221 Neville Street<br>Los Angeles CA 90017</p>
    <p>Copyright (C) 2010 Bitdog LTD All rights reserved.</p>
</td>
</tr>
</table>
</div>
</body>
</html>
</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 19:10:42 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 18:10:42 +0000
Subject: [issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1269108642.89.0.639720638781.issue7832@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to Py3k in revision 79141, revision 79142 and  revision 79143.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:15:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Mar 2010 18:15:12 +0000
Subject: [issue8186] spam
In-Reply-To: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>
Message-ID: <1269108912.71.0.64553426932.issue8186@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
status: open -> closed
title: Hohe Qualitaet und beste Preise garantiert. -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8186>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:36:21 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 18:36:21 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1269110181.3.0.597686689705.issue8084@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Since this needs review, and Christian is the author of that PEP, I'm assigning it to him.  If not appropriate, any suggestions on where to get visibility to get reviewers?

----------
assignee: ronaldoussoren -> christian.heimes
nosy: +christian.heimes, jafo
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:38:31 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 18:38:31 +0000
Subject: [issue7072] isspace(0xa0) is true on Mac OS X
In-Reply-To: <1254838065.19.0.554814525306.issue7072@psf.upfronthosting.co.za>
Message-ID: <1269110311.53.0.112449741334.issue7072@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7072>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:41:38 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 18:41:38 +0000
Subject: [issue8187] Online kaufen die beste Software!
In-Reply-To: <3636738565.4A98638N364251@tzcsvrkv.qmwziticmd.su>
Message-ID: <3636738565.4A98638N364251@tzcsvrkv.qmwziticmd.su>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Hohe Qualitaet der Software zum besten Preis!

Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie Software, die Sie in Ihrem PC haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. 
Hier Hilft man Dir Immer richtig zu Sparen!

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Linkgator LTD
1338 Mcwhorter Road
Wausau WI 54401

Copyright (C) 2010 Linkgator LTD All rights reserved.

----------
files: unnamed
messages: 101388
nosy: nobody
severity: normal
status: open
title: Online kaufen die beste Software!
Added file: http://bugs.python.org/file16603/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8187>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://koxeweru.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Hohe Qualitaet der Software zum besten Preis!</h1>
				    <p>Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie Software, die Sie in Ihrem PC haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. </p><a href="http://koxeweru.spaces.live.com">Hier Hilft man Dir Immer richtig zu Sparen!</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://koxeweru.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://koxeweru.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Linkgator LTD<br>1338 Mcwhorter Road<br>Wausau WI 54401</p>
					    <p>Copyright (C) 2010 Linkgator LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 19:42:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Mar 2010 18:42:05 +0000
Subject: [issue8187] spam
In-Reply-To: <3636738565.4A98638N364251@tzcsvrkv.qmwziticmd.su>
Message-ID: <1269110525.51.0.229562843876.issue8187@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
status: open -> closed
title: Online kaufen die beste Software! -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8187>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:42:39 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 20 Mar 2010 18:42:39 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1269110559.21.0.0946303015247.issue4931@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Tarek: This patch seems reasonable to me, is this something that can be applied?

----------
nosy: +jafo
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Sat Mar 20 19:42:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Mar 2010 18:42:54 +0000
Subject: [issue8184] multiprocessing.managers will not fail if listening ocket
	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1269110574.17.0.0293743936302.issue8184@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8184>
_______________________________________

From report at bugs.python.org  Sat Mar 20 20:51:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 20 Mar 2010 19:51:43 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1269114703.51.0.830923953278.issue4931@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I guess i can be applied on distutils, and backported in distutils2. I'll do it in the coming days.

Notice that I am now applying only bug fixes and regression fixes now for distutils.

----------
components: +Distutils2
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Sat Mar 20 20:53:07 2010
From: report at bugs.python.org (Jon Clements)
Date: Sat, 20 Mar 2010 19:53:07 +0000
Subject: [issue8185] re.findall()
In-Reply-To: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>
Message-ID: <1269114787.17.0.973033053212.issue8185@psf.upfronthosting.co.za>


Jon Clements <joncle at googlemail.com> added the comment:

Seems consistent to me:

.match, .search and .finditer return a MatchObject whose .group() return the *entire matched string*. If you use .group(1) you'll get similar results to .findall() which returns a list of (possibly of tuples) of the captured groupings.

This is the findall equivalent (using a non-capturing group):

>>> re.findall('a(?:b)?', 'ab')
['ab']

----------
nosy: +joncle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8185>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:04:46 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Mar 2010 20:04:46 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269115486.29.0.623108042265.issue8133@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch works for me as well. Go ahead and commit it, Florent, with the comment fix as a separate commit as Mark suggested.

----------
assignee: brett.cannon -> flox
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:15:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Mar 2010 20:15:53 +0000
Subject: [issue8183] warn crashes if warning's __str__ returns Unicode
In-Reply-To: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>
Message-ID: <1269116153.87.0.244045614137.issue8183@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Can't reproduce under OS X with Python 2.6.5. Closing as out of date.

----------
nosy: +brett.cannon
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8183>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:23:32 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Sat, 20 Mar 2010 20:23:32 +0000
Subject: [issue8006] os.popen in Python 3.1
In-Reply-To: <1266971440.47.0.35262669604.issue8006@psf.upfronthosting.co.za>
Message-ID: <1269116612.33.0.509819261267.issue8006@psf.upfronthosting.co.za>


Yuriy Taraday <yorik.sar at gmail.com> added the comment:

os.popen is obsolete and as I understand is removed from 3k. Use subprocess module instead.
http://docs.python.org/library/os.html?highlight=popen#os.popen

----------
nosy: +yorik.sar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8006>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:34:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 20:34:30 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a patch that makes hash(x) == hash(y) for any numeric types (int, float, complex, Decimal, Fraction, bool) when x and y are numerically equal.

This is a prerequisite for making all numeric types accurately comparable with each other.

----------
files: numeric_hash.patch
keywords: patch
messages: 101395
nosy: mark.dickinson
severity: normal
status: open
title: Unified hash for numeric types.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file16604/numeric_hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:40:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Mar 2010 20:40:11 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269117611.61.0.387229916967.issue8133@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79144 on 3.x and r79146 on 3.1.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Sat Mar 20 21:54:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 20:54:01 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269118441.9.0.754231319975.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Uploaded to Rietveld:

http://codereview.appspot.com/660042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:02:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Mar 2010 21:02:54 +0000
Subject: [issue8006] os.popen in Python 3.1
In-Reply-To: <1266971440.47.0.35262669604.issue8006@psf.upfronthosting.co.za>
Message-ID: <1269118974.89.0.89526847656.issue8006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, actually os.popen in Python3 is implemented by calling subprocess.Popen.

So, Bob, how does it fail?

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8006>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:21:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 21:21:56 +0000
Subject: [issue8185] re.findall()
In-Reply-To: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>
Message-ID: <1269120116.28.0.580278982564.issue8185@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What Jon said is correct, .group() is equivalent to .group(0) and returns the whole match. re.findall returns all the groups captured by each set of () as a list of strings (if there is 0 or 1 group) or a list of tuples (if there are more than 1).

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8185>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:59:24 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 21:59:24 +0000
Subject: [issue8189] Gute  Programme billig hier!
In-Reply-To: <1610584395.2Y7976ED477707@ltarjczisefn.sgopu.tv>
Message-ID: <1610584395.2Y7976ED477707@ltarjczisefn.sgopu.tv>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Guenstiger kaufen Sie Software nicht!

Unsere Kunde bekommen ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  
 aktuelle Software zu einem guenstigen Preis

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Objectdog LTD
2388 Holt Street
Clearwater FL 34621

Copyright (C) 2010 Objectdog LTD All rights reserved.

----------
files: unnamed
messages: 101400
nosy: nobody
severity: normal
status: open
title: Gute  Programme billig hier!
Added file: http://bugs.python.org/file16605/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8189>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1250">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://wawutehy.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Guenstiger kaufen Sie Software nicht!</h1>
				    <p>Unsere Kunde bekommen ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  </p><a href="http://wawutehy.spaces.live.com"> aktuelle Software zu einem guenstigen Preis</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://wawutehy.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://wawutehy.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Objectdog LTD<br>2388 Holt Street<br>Clearwater FL 34621</p>
					    <p>Copyright (C) 2010 Objectdog LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 22:59:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 21:59:39 +0000
Subject: [issue8189] Gute  Programme billig hier!
Message-ID: <1269122379.92.0.269633213367.issue8189@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8189>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:59:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 21:59:42 +0000
Subject: [issue8189] Gute  Programme billig hier!
Message-ID: <1269122382.88.0.0708978132212.issue8189@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16605/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8189>
_______________________________________

From report at bugs.python.org  Sat Mar 20 22:59:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Mar 2010 21:59:55 +0000
Subject: [issue8189] spam
Message-ID: <1269122395.65.0.595677630122.issue8189@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: Gute  Programme billig hier! -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8189>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:14:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 22:14:08 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269123248.05.0.412008501415.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch, with a bit of cleanup and some comments describing the hashing strategy;  I'll update the Rietveld issue as well.

----------
Added file: http://bugs.python.org/file16606/numeric_hash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:36:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 22:36:13 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269124573.18.0.699965007703.issue8188@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file16606/numeric_hash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:36:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 22:36:47 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269124607.41.0.386196762944.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops;  that patch included some accidental Lib/test/test_decimal changes.  Here's the correct patch.

----------
Added file: http://bugs.python.org/file16607/numeric_hash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:41:29 2010
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 20 Mar 2010 22:41:29 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269124889.22.0.790069464343.issue8188@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Why aren't you using 64-bit hashes on 64-bit architectures?

----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:43:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 22:43:21 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269125001.47.0.0435805758988.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Why aren't you using 64-bit hashes on 64-bit architectures?

Mostly because I haven't got around to putting that in yet.  :)

Ideal would be to use _PyHASH_BITS=61 for 64-bit machines, throughout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:44:47 2010
From: report at bugs.python.org (Adam Olsen)
Date: Sat, 20 Mar 2010 22:44:47 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269125087.77.0.165869340027.issue8188@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

I assume you mean 63. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 20 23:45:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 22:45:58 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269125158.88.0.662186892277.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

No, I mean 61.  2**61 - 1 is prime;  2**63-1 is not.  (So 2 bits of the hash get wasted, but that's not a big deal, especially since they're the high-end bits and Python mostly cares about the lower-order bits.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:01:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 23:01:28 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269126088.96.0.239394024153.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Restore tests accidentally omitted from second patch.

----------
Added file: http://bugs.python.org/file16608/numeric_hash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:01:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 23:01:36 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269126096.17.0.880124593803.issue8188@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file16607/numeric_hash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:19:48 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 20 Mar 2010 23:19:48 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269127188.88.0.44109582852.issue8188@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:21:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Mar 2010 23:21:29 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1269127289.55.0.455676228661.issue8084@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:23:47 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 23:23:47 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269127427.74.0.000754591767041.issue8179@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Test passes for me with the patch applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:28:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 23:28:08 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269127688.3.0.538153926642.issue8180@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The test passes with the first patch applied (darwin.diff). With the second patch applied I get two failures:


======================================================================
ERROR: test_normalize (__main__.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 121, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_70346_tmp/\xc2\xa8\xcc\x81\xc2\xb4\xe3\x8f\x95'

======================================================================
FAIL: test_listdir (__main__.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 145, in test_listdir
    self.assertEqual(len(f1), len(self.files))
AssertionError: 18 != 19

----------------------------------------------------------------------
Ran 30 tests in 0.292s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 198, in <module>
    test_main()
  File "Lib/test/test_pep277.py", line 191, in test_main
    UnicodeNFKDFileTests,
  File "/compile/python-trunk/Lib/test/test_support.py", line 1031, in run_unittest
    _run_suite(suite)
  File "/compile/python-trunk/Lib/test/test_support.py", line 1014, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 00:30:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 20 Mar 2010 23:30:00 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1269127800.12.0.722854180475.issue8084@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@Sean: you can look at the maintainers.rst file in the py3k branch I guess

I am maintaining sysconfig, so I guess I'll just help on the review.

Notice that we might need to backport some of the work in distutils/sysconfig since we have decided to revert distutils to 2.6/3.1 state in 2.7/3.2. I'll wait for Christian reviews, and make sure that this part is OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sun Mar 21 02:26:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 01:26:20 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1269134780.14.0.815686880456.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

More warnings silenced with r79165.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Mar 21 02:28:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 01:28:20 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1269134900.68.0.065556788157.issue7849@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Done on trunk with r78758 and r79049.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7849>
_______________________________________

From report at bugs.python.org  Sun Mar 21 02:36:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 01:36:56 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1269135416.44.0.592957294634.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch fixing most of your comments.

A couple of answers:

> I believe we can support arbitrary values here, subject to floating
> point rounding errors, by calling lock-with-timeout in a loop. I'm not
> sure whether that's a good idea, but it fits better with python's
> arbitrary-precision ints.

I'm a bit wary of this, because we can't test it properly.

> -        task_handler.join(1e100)
> +        task_handler.join()
> 
> Why is this change here?  (Mostly curiosity)

Because 1e100 would raise OverflowError :)

> +               if (timeout > PY_TIMEOUT_MAX) {
> 
> I believe it's possible for this comparison to return false, but for
> the conversion to PY_TIMEOUT_T to still overflow:

Ok, I've replaced it with the following which should be ok:

    if (timeout >= (double) PY_TIMEOUT_MAX) [...]

> +               milliseconds = (microseconds + 999) / 1000;
> 
> Can (microseconds+999) overflow?

Indeed it can (I sincerely hoped that nobody would care...).
I've replaced it with what might be a more appropriate construct.
Please note that behaviour is undefined when microseconds exceeds the max timeout, though (this is the low-level C API).

----------
Added file: http://bugs.python.org/file16609/timedlock5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Sun Mar 21 02:37:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 01:37:47 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1269135467.88.0.729671246191.issue7316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15795/timedlock4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Sun Mar 21 04:25:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 21 Mar 2010 03:25:57 +0000
Subject: [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

let's add a small xml-rpc client in Distutils2, implementing all functions.

See http://wiki.python.org/moin/PyPiXmlRpc

----------
assignee: tarek
components: Distutils2
messages: 101414
nosy: tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an xml-rpc client for PyPi
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 21 04:29:13 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 21 Mar 2010 03:29:13 +0000
Subject: [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269142153.71.0.930906427938.issue8190@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

see also http://tools.assembla.com/yolk/browser/trunk/yolk/pypi.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:29:14 2010
From: report at bugs.python.org (bairam)
Date: Sun, 21 Mar 2010 10:29:14 +0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1269167354.84.0.802673064984.issue1124861@psf.upfronthosting.co.za>


bairam <bkomaki at yahoo.com> added the comment:

I have tested this form in Python26 ,It works
>>> import subprocess
>>> p = subprocess.Popen("cmd.exe dir", stdout=subprocess.PIPE)
>>> p.communicate()
('Microsoft Windows XP [Version 5.1.2600]\r\n(C) Copyright 1985-2001 Microsoft Corp.\r\n\r\nC:\\Python26>', None)

----------
nosy: +bairam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_______________________________________

From report at bugs.python.org  Sun Mar 21 11:38:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Mar 2010 10:38:58 +0000
Subject: [issue8177] Incoherent error with keyword argument follow by
	unpacking argument lists
In-Reply-To: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>
Message-ID: <1269167938.11.0.880042611364.issue8177@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8177>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:02:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Mar 2010 11:02:50 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269169370.72.0.0180240537657.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch:

 - put hash parameters into pyport.h, to avoid repetition;  make them
   available to Python code via a private attribute sys._hash_info.

 - use a modulus of 2**61-1 on systems where SIZEOF_LONG >= 8, and
   a modulus of 2**31 - 1 otherwise.

 - remove _invmod from fractions module.  It's faster (and easier) to
   use 3-argument pow to compute inverses modulo a prime.

 - add a few more tests.

----------
Added file: http://bugs.python.org/file16610/numeric_hash3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun Mar 21 12:15:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 11:15:42 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1269170142.16.0.242870537547.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

other py3k warnings silenced with r79187 r79188 r79189

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Mar 21 13:30:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 12:30:29 +0000
Subject: [issue8179] Test failure in test_macpath.py test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269174629.43.0.845494721595.issue8179@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79195 and r79196.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8179>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:09:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:09:59 +0000
Subject: [issue7820] parser: restores all bytes in the right order if
	check_bom() fails
In-Reply-To: <1264908263.1.0.898518004348.issue7820@psf.upfronthosting.co.za>
Message-ID: <1269176999.73.0.803141748207.issue7820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Backported in r79197 (2.6).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:14:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:14:02 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1269177242.7.0.137329988188.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> thread fix commited: r78610 (trunk)
> curses panel fix commited: r78635 (trunk)

Backport done in r79198 (2.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:33:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:33:04 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1269178384.66.0.716396896623.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited: r78638 (trunk)

Backport done: r79199 (2.6).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:39:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:39:05 +0000
Subject: [issue7494] _lsprof (cProfile): Profiler.clear() keeps references to
	detroyed nodes
In-Reply-To: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>
Message-ID: <1269178745.95.0.739211489909.issue7494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fixed by r78641 (trunk)

Backport done: r79200 (2.6).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:42:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:42:04 +0000
Subject: [issue1054943] Python may contain NFC/NFKC bug per Unicode PRI #29
Message-ID: <1269178924.28.0.487977177292.issue1054943@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited: r78646 (trunk)

Backport done: r79201 (2.6).

----------
resolution: remind -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054943>
_______________________________________

From report at bugs.python.org  Sun Mar 21 14:50:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 13:50:03 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1269179403.71.0.19759853888.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r78835 (trunk) fixes getpath

Backport done: r79202 (2.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Sun Mar 21 15:02:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 14:02:59 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1269180179.75.0.801572495588.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Commited to trunk: r78826 + r78827

Partial backport to 2.6 as r79204: leave import site error handler unchanged (print the error and continue). I don't want to change Python behaviour between minor releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Sun Mar 21 15:06:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 14:06:38 +0000
Subject: [issue8063] Call _PyGILState_Init() earlier in Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1269180398.44.0.124629638939.issue8063@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8063>
_______________________________________

From report at bugs.python.org  Sun Mar 21 15:36:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Mar 2010 14:36:54 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1269182214.85.0.848758897219.issue7783@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Sun Mar 21 15:38:40 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 21 Mar 2010 14:38:40 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1269182320.99.0.506215238154.issue8047@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Hmm.  I'm not entirely sure about giving False a meaning when None has traditionally had a different (and documented) meaning.  And sleeping on it hasn't convinced me in either direction :-(

(well, I'd say no, but the compatibility argument is somewhat tempting)

I'm not that concerned by changing the default for write -- 3.x users with utf-8 as the default output encoding will get different output, but still perfectly valid XML.  3.x users with non-utf-8 default encodings  will get valid XML also in cases where it didn't work before.

tostring() is more problematic, but I'm leaning towards Guido's torpedoes approach there -- changing the default output to bytestrings is more likely to cause code to blow up than cause bad output, and you can trivially make your program backwards compatible by adding an extra check/decode after the call.  Supporting unicode for lxml.etree compatibility is fine with me, but I think it might make sense to support the string "unicode" as well (as a pseudo-encoding -- it's pretty clear to me that nobody will ever define a real character encoding with that name :-).

Have you posted/can you post the patch to riedveld, btw?  I have some questions about the code that are independent of the encoding decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Sun Mar 21 16:03:22 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sun, 21 Mar 2010 15:03:22 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1269183802.96.0.332338771471.issue7718@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

Is it necessary to file a new bug for the same issue, or can we reopen from here?  With Stuart in the loop it looks to me the raised issues are dealt with?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sun Mar 21 16:50:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 15:50:59 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269186659.2.0.512401178803.issue8180@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16600/issue8180_pep277_additions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 16:57:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 15:57:29 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269187049.49.0.744767958937.issue8180@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

New patch: removed the offending codepoint '\ufad1'.
Please try again on OS X, and windows.

----------
Added file: http://bugs.python.org/file16611/issue8180_pep277_additions_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:03:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 21 Mar 2010 16:03:11 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1269187391.11.0.484924190529.issue7718@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'll reopen this for now, no need for duplicate issues.

http://www.python.org/psf/contrib/ has the relevant contributor agreement that should be signed.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sun Mar 21 17:53:22 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 21 Mar 2010 16:53:22 +0000
Subject: [issue8088] assertSameElements fails with sequences that contain
	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1269190402.56.0.211160052532.issue8088@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Fixed as part of #7832.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8088>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:20:42 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 21 Mar 2010 17:20:42 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269192042.83.0.154500937394.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> this change in its current form needs to be backed out of 2.6

done.

I'll check for uses of execlp and execlpe.

how should the divergency of execlp (raises ValueError), and execlpe (raises IndexError) be handled?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:23:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 17:23:29 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269192209.58.0.0696501908503.issue8180@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16611/issue8180_pep277_additions_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:24:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 17:24:25 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269192265.88.0.873158725143.issue8180@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

New patch, fixing test_listdir on OS X (hopefully).

----------
Added file: http://bugs.python.org/file16612/issue8180_pep277_additions_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:27:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Mar 2010 17:27:02 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269192422.85.0.0222495366165.issue8154@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Could you please write the revision number when you speak about a commit? Text like ?fixed in r4253? will become an helpful link.

Thanks

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:36:02 2010
From: report at bugs.python.org (George Sakkis)
Date: Sun, 21 Mar 2010 17:36:02 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1269192962.81.0.918188874391.issue1745@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Is there any update on this for 2.7 ?

----------
nosy: +gsakkis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Sun Mar 21 18:38:31 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 21 Mar 2010 17:38:31 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269193111.47.0.242087966837.issue8154@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

reverted in r79190 on the 2.6 branch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:04:46 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 21 Mar 2010 18:04:46 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1269194686.15.0.770344924124.issue3783@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy:  -gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:18:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 18:18:55 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Since issue1039 made it illegal to pass empty argument list to execv*, I suggest to change signature of os.execl* functions and make arg0 a required positional argument.

This is not a backward compatible change because os.execlp('true'),  for example will now raise TypeError instead of ValueError.  However since issue1039 change has not been released yet, I think this can be done.

----------
components: Library (Lib)
files: execl.diff
keywords: patch
messages: 101437
nosy: Alexander.Belopolsky
severity: normal
status: open
title: Make arg0 required argument in os.execl* functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file16613/execl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:20:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 18:20:53 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1269195653.37.0.363144680553.issue8154@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Please see related issue8191.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:23:49 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 21 Mar 2010 18:23:49 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1269195829.68.0.59628699521.issue3783@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:24:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 18:24:47 +0000
Subject: [issue1039] Asssertion in Windows debug build
In-Reply-To: <1188280918.82.0.842547677227.issue1039@psf.upfronthosting.co.za>
Message-ID: <1269195887.96.0.529401973273.issue1039@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Link to revision: r57731

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1039>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:28:38 2010
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 21 Mar 2010 18:28:38 +0000
Subject: [issue8192] SQLite3 PRAGMA table_info doesn't respect database on
	Win32
In-Reply-To: <1269196118.36.0.673213819166.issue8192@psf.upfronthosting.co.za>
Message-ID: <1269196118.36.0.673213819166.issue8192@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

'PRAGMA database.table_info("SOME_TABLE_NAME")' will report table metadata for the given database. The main database called 'main', can be extended by attaching further databases via 'ATTACH DATABASE'. The above PRAGMA should respect the chosen database, but fails to do so on Win32 (tested on Wine) while it does on Linux.

How to reproduce:

FILE 'first.db' has table:

  CREATE TABLE "First" (
          "Test" INTEGER NOT NULL
  );

FILE 'second.db' has table:

  CREATE TABLE "Second" (
          "Test" INTEGER NOT NULL
  );

The final result of the following code shoule be empty, but returns table data from second.db instead.

Y:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect('first.db')
>>> c = conn.cursor()
>>> c.execute("ATTACH DATABASE 'second.db' AS 'second'")
<sqlite3.Cursor object at 0x0071FB00>
>>> for row in c:
...     print repr(row)
...
>>> c.execute("PRAGMA 'main'.table_info('Second')")
<sqlite3.Cursor object at 0x0071FB00>
>>> for row in c:
...     print repr(row)
...
(0, u'Test', u'INTEGER', 99, None, 0)
>>>

In contrast sqlite3.exe respects the value for the same command:

Y:\>sqlite3.exe first.db
SQLite version 3.6.23
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
First
sqlite> ATTACH DATABASE 'second.db' AS 'second';
sqlite> .tables
First
sqlite> PRAGMA main.table_info('Second');
sqlite> PRAGMA second.table_info('Second');
0|Test|INTEGER|1||0
sqlite>

Advice on further debugging possibilities is requested. I do not have a Windows system available though, nor can I currently compile for Win32.

----------
components: Library (Lib)
messages: 101440
nosy: christoph
severity: normal
status: open
title: SQLite3 PRAGMA table_info doesn't respect database on Win32
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8192>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:32:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 18:32:39 +0000
Subject: [issue1039] Asssertion in Windows debug build
In-Reply-To: <1188280918.82.0.842547677227.issue1039@psf.upfronthosting.co.za>
Message-ID: <1269196359.53.0.972682238755.issue1039@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

This issue was misclassified as an interpreter crash while in fact it was a bug in the underlying OS utility. Please see discussion in issue8154.

Since the fix changes behavior, it should be documented and a NEWS entry added.

----------
type: crash -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1039>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:52:17 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 21 Mar 2010 18:52:17 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1269197537.27.0.0931364277668.issue8191@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> However since issue1039 change has not been released yet

os.execlp('true') does raise ValueError on released 3.x versions. sorry if I do misunderstand something.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Sun Mar 21 19:53:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 18:53:38 +0000
Subject: [issue8180] Unicode File Test failures (PEP 277 on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269197618.0.0.689007996548.issue8180@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79207 (2.x) and r79209 (3.x).
Thank you Michael for testing it.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8180>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:03:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 19:03:07 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269197537.27.0.0931364277668.issue8191@psf.upfronthosting.co.za>
Message-ID: <d38f5331003211203m20ebfa36le84a7a3ed3c13a43@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Mar 21, 2010 at 2:52 PM, Matthias Klose <report at bugs.python.org> wrote:
..
> os.execlp('true') does raise ValueError on released 3.x versions. sorry if I do misunderstand something.

My bad.  I thought it was a more recent change.  However as far as I
can tell it was never documented or announced in the NEWS or "What's
new in" files, so it is unlikely that there is code in the wild that
would rely on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:12:49 2010
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Sun, 21 Mar 2010 19:12:49 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>


New submission from Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl>:

Starting with zlib 1.2.4 zlib test suite fails with:

test test_zlib failed -- Traceback (most recent call last):
  File "/home/users/arekm/rpm/BUILD/Python-2.6.5/Lib/test/test_zlib.py", line 84, in test_baddecompressobj
    self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised

----------
components: Library (Lib)
messages: 101445
nosy: arekm
severity: normal
status: open
title: test_zlib fails with zlib 1.2.4
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:14:19 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 21 Mar 2010 19:14:19 +0000
Subject: [issue8191] Make arg0 required argument in os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1269198859.3.0.851314791021.issue8191@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8191>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:14:58 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 21 Mar 2010 19:14:58 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269198898.55.0.376407933839.issue8193@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:24:22 2010
From: report at bugs.python.org (Defert)
Date: Sun, 21 Mar 2010 19:24:22 +0000
Subject: [issue8194] broken API in xmlrpclib.Transport
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>


New submission from Defert <laurent_defert at yahoo.fr>:

In the Transport class of the xmlrpclib module, the parse_response method expects a File object but handles HTTPResponse's.
The regression was introduced in r73638.
A fix is attached.

----------
components: Library (Lib)
files: xmlrpclib.patch
keywords: patch
messages: 101446
nosy: lids
severity: normal
status: open
title: broken API in xmlrpclib.Transport
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file16614/xmlrpclib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:27:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 19:27:50 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1269199670.02.0.240759253307.issue1628484@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r79218 (trunk), r79220 (2.6), r79221 (py3k), r79222 (3.1). Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:29:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 19:29:09 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1269199749.12.0.996178618377.issue8176@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Clearly not enough information, but I have a few observations:

1. Clearly the crash occurs on exit (in Py_Finalize) during a module cleanup.  (Unfortunately it looks like a non-debug build of Python was used so figuring out which module is involved may be hard. 

2. Memory map suggests that the crash is very late in python finalization.  Note that only two python modules are still mapped: mxDateTime and _hashlib.  However the memmap seems incomplete.

Try to reproduce the crash with a debug build of python (configure --with-pydebug).  The debug build may also crash sooner and more reliably.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:41:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 19:41:01 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269200461.11.0.418380964635.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed the patch to trunk (r79226), only to discover that it caused occasional failures in test_ftplib:

$ ./python -m test.regrtest -F test_ftplib
test_ftplib
test_ftplib
Exception in thread Thread-116:
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line 223, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 211, in loop
    poll_fun(timeout, map)
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 148, in poll
    read(obj)
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 80, in read
    obj.handle_error()
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 76, in read
    obj.handle_read_event()
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line 284, in handle_read_event
    super(SSLConnection, self).handle_read_event()
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 421, in handle_read_event
    self.handle_read()
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line 39, in handle_read
    self.baseclass.last_received_data += self.recv(1024)
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line 302, in recv
    return super(SSLConnection, self).recv(buffer_size)
  File "/home/antoine/cpython/__svn__/Lib/asyncore.py", line 370, in recv
    data = self.socket.recv(buffer_size)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 96, in <lambda>
    self.recv = lambda buflen=1024, flags=0: SSLSocket.recv(self, buflen, flags)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: [Errno 2] _ssl.c:1335: The operation did not complete (read)

test test_ftplib failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line 491, in test_storlines
    self.client.storlines('stor', f)
  File "/home/antoine/cpython/__svn__/Lib/ftplib.py", line 749, in storlines
    return self.voidresp()
  File "/home/antoine/cpython/__svn__/Lib/ftplib.py", line 224, in voidresp
    resp = self.getresp()
  File "/home/antoine/cpython/__svn__/Lib/ftplib.py", line 210, in getresp
    resp = self.getmultiline()
  File "/home/antoine/cpython/__svn__/Lib/ftplib.py", line 196, in getmultiline
    line = self.getline()
  File "/home/antoine/cpython/__svn__/Lib/ftplib.py", line 183, in getline
    line = self.file.readline()
  File "/home/antoine/cpython/__svn__/Lib/socket.py", line 445, in readline
    data = self._sock.recv(self._rbufsize)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 96, in <lambda>
    self.recv = lambda buflen=1024, flags=0: SSLSocket.recv(self, buflen, flags)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/home/antoine/cpython/__svn__/Lib/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out


Giampaolo, do you think the test is flaky?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Sun Mar 21 20:57:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 19:57:24 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269201444.64.0.0629523932562.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(using SSL_MODE_AUTO_RETRY doesn't fix the test_ftplib issue)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:16:41 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 21 Mar 2010 20:16:41 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1269202601.58.0.626997331508.issue3119@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Sorry for the delay in getting to this patch.

I've reviewed this patch and it seems fine to me.  The only thing I see outstanding is the recommendation made by Alexandre about changing the C module to also implement this.

Aaron: You may want to take your question on the implementation to the python-dev mailing list: Whether it is necessary to implement it in the C module, and if so suggestions on how or help on doing it.  Is that something you can do, Aaron?

----------
nosy: +jafo
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:19:23 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 21 Mar 2010 20:19:23 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1269202763.5.0.91777410479.issue3119@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Ugh, I forgot to check the output of my test run before submitting the last reply.  With the patch applied, "make test" fails with:

test_pickle
Fatal Python error: Cannot recover from stack overflow.
Fatal Python error: Cannot recover from stack overflow.
make: *** [test] Aborted (core dumped)

This is on Python 3 trunk, with the pickle3.patch applied (which applied cleanly).

For the Misc/NEWS I propose (in the Library section):

- Issue #3119: pickle.py can now handle deeply-nested data-structures
  without reaching the Python call stack limit.  NOTE: the pickle save()
  method is now a generator, though sub-classes of Pickler shouldn't
  override save().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:19:35 2010
From: report at bugs.python.org (Daniel Serodio)
Date: Sun, 21 Mar 2010 20:19:35 +0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1269202775.48.0.143759212262.issue1124861@psf.upfronthosting.co.za>


Daniel Serodio <dserodio at gmail.com> added the comment:

Still doesn't work for me with Python 2.6.5 on Windows 7 64-bit, but apparently for a different reason.
When I type p.communicate() as in bairam's example, it blocks with no output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:21:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Mar 2010 20:21:26 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1269202886.56.0.780909600894.issue6474@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r79235.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:47:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 21 Mar 2010 20:47:10 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1269204430.54.0.222557067124.issue1059244@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:49:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Mar 2010 20:49:42 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269204582.55.0.442012336344.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The intuitive explanation seems to be:
- there are some bytes available for reading on the *TCP socket*, therefore asyncore calls the read handler
- however, there are not enough bytes for OpenSSL to actually decrypt any data, which is why we get SSL_ERROR_WANT_READ when trying to read from the *SSL socket*

The following patch seems to fix test_ftplib; any thoughts?


Index: Lib/test/test_ftplib.py
===================================================================
--- Lib/test/test_ftplib.py	(r?vision 79224)
+++ Lib/test/test_ftplib.py	(copie de travail)
@@ -293,7 +293,9 @@
             try:
                 return super(SSLConnection, self).send(data)
             except ssl.SSLError, err:
-                if err.args[0] in (ssl.SSL_ERROR_EOF, ssl.SSL_ERROR_ZERO_RETURN):
+                if err.args[0] in (ssl.SSL_ERROR_EOF, ssl.SSL_ERROR_ZERO_RETURN,
+                                   ssl.SSL_ERROR_WANT_READ,
+                                   ssl.SSL_ERROR_WANT_WRITE):
                     return 0
                 raise
 
@@ -301,6 +303,9 @@
             try:
                 return super(SSLConnection, self).recv(buffer_size)
             except ssl.SSLError, err:
+                if err.args[0] in (ssl.SSL_ERROR_WANT_READ,
+                                   ssl.SSL_ERROR_WANT_WRITE):
+                    return ''
                 if err.args[0] in (ssl.SSL_ERROR_EOF, ssl.SSL_ERROR_ZERO_RETURN):
                     self.handle_close()
                     return ''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:50:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 21 Mar 2010 20:50:13 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1269204613.35.0.108555058209.issue1059244@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am creating packages for PyPI and they all are created wrong. If the module is pure Python - 'bdist' should be equal to 'sdist'.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:54:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Mar 2010 20:54:52 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1269204892.66.0.849695760815.issue1059244@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Sun Mar 21 21:59:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 21 Mar 2010 20:59:48 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1269205188.92.0.0892314974633.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Now paths with spaces are explicitly rejected, after the upgrade to libffi 3.0.9. (Issue #8142)

----------
nosy: +doko
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7661>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:09:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 21:09:24 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1269205764.34.0.991327470881.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I commited unicode_fromformat_U.patch as r78875.
> object_pyunicode_asstring-py3k.patch commited as r78876.

Backported as r79240 and r79241 to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:18:28 2010
From: report at bugs.python.org (Carlos Ribeiro)
Date: Sun, 21 Mar 2010 21:18:28 +0000
Subject: [issue8176] Interpreter crash with "double free or corruption" message
In-Reply-To: <1269199749.12.0.996178618377.issue8176@psf.upfronthosting.co.za>
Message-ID: <864d37091003211417o414778b8vc7da984a96f01213@mail.gmail.com>


Carlos Ribeiro <carribeiro at gmail.com> added the comment:

Thanks for investigating!

I'll keep watching. I'm currently developing a small Django app, and the
crash happened during one of the automatic reloads that the development
server do whenever a source code file changes. The problem is that I
probably ran through the same procedure several hundred times over the past
few weeks, but the bug happened only *once*. Seems like a nasty bug. I
*suspect* it may be thread related, a racing condition or something like it.
(and yes, I'm using a regular build, not a debug build).

Also note that I use Python since 1998 and never, in the past 12 years, I
had a dump like this.

As for this ticket, it seems like a nasty and elusive bug; I _feel_ that we
may never see the same bug again, _but_ other people may encounter similar
situations, and we can then try to correlate them to find the cause. If I
don't manage to reproduce it over the next few days we may close it but keep
it in the tracker, until someone else hits it again.

Best regards,

Carlos Ribeiro

On Sun, Mar 21, 2010 at 16:29, Alexander Belopolsky
<report at bugs.python.org>wrote:

>
> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
>
> Clearly not enough information, but I have a few observations:
>
> 1. Clearly the crash occurs on exit (in Py_Finalize) during a module
> cleanup.  (Unfortunately it looks like a non-debug build of Python was used
> so figuring out which module is involved may be hard.
>
> 2. Memory map suggests that the crash is very late in python finalization.
>  Note that only two python modules are still mapped: mxDateTime and
> _hashlib.  However the memmap seems incomplete.
>
> Try to reproduce the crash with a debug build of python (configure
> --with-pydebug).  The debug build may also crash sooner and more reliably.
>
> ----------
> nosy: +Alexander.Belopolsky
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8176>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16615/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8176>
_______________________________________
-------------- next part --------------
Thanks for investigating!<br><br>I&#39;ll keep watching. I&#39;m currently developing a small Django app, and the crash happened during one of the automatic reloads that the development server do whenever a source code file changes. The problem is that I probably ran through the same procedure several hundred times over the past few weeks, but the bug happened only *once*. Seems like a nasty bug. I *suspect* it may be thread related, a racing condition or something like it. (and yes, I&#39;m using a regular build, not a debug build).<br>

<br>Also note that I use Python since 1998 and never, in the past 12 years, I had a dump like this.<br><br>As for this ticket, it seems like a nasty and elusive bug; I _feel_ that we may never see the same bug again, _but_ other people may encounter similar situations, and we can then try to correlate them to find the cause. If I don&#39;t manage to reproduce it over the next few days we may close it but keep it in the tracker, until someone else hits it again.<br>

<br>Best regards,<br><br>Carlos Ribeiro<br><br><br><div class="gmail_quote">On Sun, Mar 21, 2010 at 16:29, Alexander Belopolsky <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Alexander Belopolsky &lt;<a href="mailto:alexander.belopolsky at gmail.com">alexander.belopolsky at gmail.com</a>&gt; added the comment:<br>
<br>
Clearly not enough information, but I have a few observations:<br>
<br>
1. Clearly the crash occurs on exit (in Py_Finalize) during a module cleanup. ??(Unfortunately it looks like a non-debug build of Python was used so figuring out which module is involved may be hard.<br>
<br>
2. Memory map suggests that the crash is very late in python finalization. ??Note that only two python modules are still mapped: mxDateTime and _hashlib. ??However the memmap seems incomplete.<br>
<br>
Try to reproduce the crash with a debug build of python (configure --with-pydebug). ??The debug build may also crash sooner and more reliably.<br>
<br>
----------<br>
nosy: +Alexander.Belopolsky<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue8176" target="_blank">http://bugs.python.org/issue8176</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Carlos Ribeiro<br>Consultoria em Projetos<br>twitter: <a href="http://twitter.com/carribeiro">http://twitter.com/carribeiro</a><br>blog: <a href="http://rascunhosrotos.blogspot.com">http://rascunhosrotos.blogspot.com</a><br>

mail: <a href="mailto:carribeiro at gmail.com">carribeiro at gmail.com</a><br>

From report at bugs.python.org  Sun Mar 21 22:30:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Mar 2010 21:30:57 +0000
Subject: [issue8177] Incoherent error with keyword argument follow by
	unpacking argument lists
In-Reply-To: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>
Message-ID: <1269207057.62.0.168030165655.issue8177@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's a weird error even it reverse order:

>>> def f(foo, *args):
...     pass
...
>>> f(*(1, 2, 3), foo=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got multiple values for keyword argument 'foo'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8177>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:31:18 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 21 Mar 2010 21:31:18 +0000
Subject: [issue5671] Speed up pickling of lists in cPickle
In-Reply-To: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
Message-ID: <1269207078.37.0.5737786463.issue5671@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

pickle_batch_list_exact_py3k.diff applies cleanly on current py3k trunk and passes tests.  cpickle_list.patch applies cleanly against 2.x trunk and passes "make test".

I don't see any objections brought up about this set of patches, so we can get these applied?

----------
assignee:  -> alexandre.vassalotti
nosy: +jafo
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5671>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:50:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 21:50:13 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1269208213.73.0.51719626559.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Backported to py3k as r78872

And backported to 3.1 as r79247.

> But py3k will require extra work: there are some PyErr_Clear() somewhere, eating the errors.

Leave this issue open until #8124 is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:56:17 2010
From: report at bugs.python.org (Ghislain Hivon)
Date: Sun, 21 Mar 2010 21:56:17 +0000
Subject: [issue8177] Incoherent error with keyword argument follow by
	unpacking argument lists
In-Reply-To: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>
Message-ID: <1269208577.92.0.954250169394.issue8177@psf.upfronthosting.co.za>


Ghislain Hivon <jahed_g at hotmail.com> added the comment:

The reverse, f(*(1, 2, 3), foo=4), is consistent with 
f(1,2,3, foo=4)
who also gave 
TypeError: f() got multiple values for keyword argument 'foo'

Which is consistent with the tutorial
http://docs.python.org/tutorial/controlflow.html#keyword-arguments

def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):
...
but the following calls would all be invalid:
parrot(voltage=5.0, 'dead')  # non-keyword argument following keyword
parrot(110, voltage=220)     # duplicate value for argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8177>
_______________________________________

From report at bugs.python.org  Sun Mar 21 22:57:21 2010
From: report at bugs.python.org (bairam)
Date: Sun, 21 Mar 2010 21:57:21 +0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1269208641.29.0.186681788347.issue1124861@psf.upfronthosting.co.za>


bairam <bkomaki at yahoo.com> added the comment:

shell vs subprocess
The problem is the default option "Shell" is "False" , you you write commands you should turn on the shell.
for example try this to show the content of directory " C:\Python26
":
>>>import subprocess
>>> p = subprocess.Popen("dir", shell=True,stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>>> stdout,stderr=p.communicate()
>>> print stderr # if errors doe not occur ,it is empty!

>>> print stdout

----------
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_______________________________________

From report at bugs.python.org  Sun Mar 21 23:03:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Mar 2010 22:03:18 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1269208998.74.0.44407563259.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Merged as r79248 and r79250.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Sun Mar 21 23:10:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 22:10:52 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1269209452.89.0.709100531508.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> Backported to py3k as r78872
> And backported to 3.1 as r79247.

I reverted the change on initsite(): as for Python 2.6, I don't want to change import site error handler between minor releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Sun Mar 21 23:25:37 2010
From: report at bugs.python.org (Bob Buckley)
Date: Sun, 21 Mar 2010 22:25:37 +0000
Subject: [issue8006] os.popen in Python 3.1
In-Reply-To: <1269118974.89.0.89526847656.issue8006@psf.upfronthosting.co.za>
Message-ID: <4BA69CD7.7010106@buckley.id.au>


Bob Buckley <bob at buckley.id.au> added the comment:

I could not get it to open a write pipe. I am trying to drive GNUplot 
from Python. It worked OK in Python 2.x but does not work well in 3.x.
I have it partially working now ... I am calling subprocess.Popen but I 
cannot get a text mode pipe which is disappointing. I have not yet got 
my head around Python 3's byte vs string stuff.

regards
Bob Buckley

On 21/03/2010 8:02 AM, R. David Murray wrote:
> R. David Murray<rdmurray at bitdance.com>  added the comment:
>
> Well, actually os.popen in Python3 is implemented by calling subprocess.Popen.
>
> So, Bob, how does it fail?
>
> ----------
> nosy: +r.david.murray
> priority:  ->  normal
> stage:  ->  test needed
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8006>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8006>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:37:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 23:37:05 +0000
Subject: [issue8195] Crash in sqlite3.create_collation() with a string non
	encodable to utf8
In-Reply-To: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>
Message-ID: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

sqlite.connect(":memory:").create_collation, "\uDC80", collation_cb) because _PyUnicode_AsString() returns NULL and error, and the result is not checked.

Attached patch fixes the crash.

I didn't checked if the problem does also concern Python 2.x.

----------
components: Library (Lib)
files: sqlite_collation-py3k.patch
keywords: patch
messages: 101468
nosy: haypo
severity: normal
status: open
title: Crash in sqlite3.create_collation() with a string non encodable to utf8
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16616/sqlite_collation-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8195>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:39:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 23:39:27 +0000
Subject: [issue8195] Crash in sqlite3.create_collation() with a string non
	encodable to utf8
In-Reply-To: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>
Message-ID: <1269214767.54.0.802728343974.issue8195@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16616/sqlite_collation-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8195>
_______________________________________

From report at bugs.python.org  Mon Mar 22 00:39:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 23:39:49 +0000
Subject: [issue8195] Crash in sqlite3.create_collation() with a string non
	encodable to utf8
In-Reply-To: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>
Message-ID: <1269214789.46.0.341436880025.issue8195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(oops, my patch included tabulations!)

----------
Added file: http://bugs.python.org/file16617/sqlite_collation-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8195>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:05:29 2010
From: report at bugs.python.org (Santiago Gala)
Date: Mon, 22 Mar 2010 00:05:29 +0000
Subject: [issue8196] sqlit3.paramstyle reported as 'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

>>> import sqlite3
>>> sqlite3.paramstyle
'qmark'

The documentation claims that sqlite3 accepts 'named' paramstyle, and :PEP:`249` says in footnote 2:

        Module implementors should prefer 'numeric', 'named' or
        'pyformat' over the other formats because these offer more
        clarity and flexibility.

I think the module should report 'named', as it is preferred, and leave to the documentation the fact that 'qmark' is also supported.

----------
components: Extension Modules
messages: 101470
nosy: sgala
severity: normal
status: open
title: sqlit3.paramstyle reported as 'qmark'
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8196>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:07:45 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 00:07:45 +0000
Subject: [issue7815] Regression in unittest traceback formating extensibility
In-Reply-To: <1264874450.07.0.188014948494.issue7815@psf.upfronthosting.co.za>
Message-ID: <1269216465.36.0.467643454436.issue7815@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 79263. As external modules are already using __unittest it would be backwards incompatible not to restore the functionality.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7815>
_______________________________________

From report at bugs.python.org  Mon Mar 22 01:33:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 00:33:17 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1269217997.38.0.988051973183.issue7774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The initial problem (test_subprocess failures) is solved thanks to different fixes. I consider that we can close this issue. Use non portable tricks to get the real program name if argv[0] is invalid doesn't sound like something importat. If someone changes argv[0], he have to assume that sys.executable is invalid or empty.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:04:23 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 01:04:23 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1269219863.28.0.724382814499.issue8074@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Failfast option added, committed revision 79265. Still needs documentation. Ctrl-C handling not yet done. Slightly more complex as it needs to play well with tests that test SIGINT handling.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:08:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 01:08:25 +0000
Subject: [issue8197] Fatal error on thread creation in low memory condition (2)
In-Reply-To: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>
Message-ID: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I wrote a patch to preallocate Python thread state before creating the thread to avoid a fatal error: issue7544 (it's now closed). This patch is not enough to avoid fatal errors in low memory condition.

Just after the creation of the thread, _PyGILState_NoteThreadState() is called. This function can fail with a fatal error (Couldn't create autoTLSkey mapping) in low memory condition if a memory allocation fails in find_key(), called by PyThread_set_key_value().

PyThread_set_key_value() fills a global single linked list of type 'struct key', the head is 'keyhead'. This list contains values and uses an index composed of (long thread id, int key). Only one key is used: autoTLSkey (0). The list is used to get the thread state (eg. in PyGILState_Ensure).

Note: This issue is very unlikely, but it does exist :-)

----------
messages: 101474
nosy: haypo
severity: normal
status: open
title: Fatal error on thread creation in low memory condition (2)
type: crash
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8197>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:16:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 01:16:44 +0000
Subject: [issue8197] Fatal error on thread creation in low memory condition:
	local storage
In-Reply-To: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>
Message-ID: <1269220604.1.0.467262012112.issue8197@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
priority:  -> low
title: Fatal error on thread creation in low memory condition (2) -> Fatal error on thread creation in low memory condition: local storage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8197>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:21:58 2010
From: report at bugs.python.org (George Sakkis)
Date: Mon, 22 Mar 2010 01:21:58 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1269220918.91.0.941620218273.issue1745@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

FWIW I updated the patch to r79264; it applies cleanly and passes the tests but other than that I can't tell if it's ready. It would be nice to have it in 2.7 though.

----------
Added file: http://bugs.python.org/file16618/backport-keyword-only-arguments-full-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:32:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 01:32:11 +0000
Subject: [issue8195] Crash in sqlite3.create_collation() with a string non
	encodable to utf8
In-Reply-To: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>
Message-ID: <1269221531.15.0.530004589049.issue8195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My first sentence doesn't mean anything! I wanted to write:

sqlite.connect(":memory:").create_collation, "\uDC80", collation_cb) crashs because _PyUnicode_AsString() returns NULL on error, and the result is not checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8195>
_______________________________________

From report at bugs.python.org  Mon Mar 22 02:34:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 01:34:28 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1269221668.68.0.522446823754.issue4735@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4735>
_______________________________________

From report at bugs.python.org  Mon Mar 22 03:00:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 02:00:34 +0000
Subject: [issue4282] profile doesn't support non-UTF8 source code
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1269223234.87.0.968877539245.issue4282@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r79271 (py3k), r79272 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________

From report at bugs.python.org  Mon Mar 22 03:11:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Mar 2010 02:11:36 +0000
Subject: [issue8006] os.popen in Python 3.1
In-Reply-To: <1266971440.47.0.35262669604.issue8006@psf.upfronthosting.co.za>
Message-ID: <1269223896.79.0.910762118634.issue8006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A short snipped of example code that works in python2 and fails in python3 would be helpful in deciding whether or not this is a bug that needs fixing in python3.  Something that doesn't involve gnuplot, just python itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8006>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:22:04 2010
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Granade?=)
Date: Mon, 22 Mar 2010 05:22:04 +0000
Subject: [issue8198] Importing pydoc and overwriting sys.stdout,
	causes one char to be sent to the console when calling help()
In-Reply-To: <1269235324.89.0.336122945296.issue8198@psf.upfronthosting.co.za>
Message-ID: <1269235324.89.0.336122945296.issue8198@psf.upfronthosting.co.za>


New submission from Fran?ois Granade <francois at granade.com>:

When the "pydoc" module is imported, and the sys.stdout is overwriten, a end-of-line is sent to the console (on sdtout) when the help() function is sent.

to reproduce (this is on Python 2.5 but the same happens on Pythjon 3.1):

bash-3.2$ python2.5 -c "import pydoc; import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)"

bash-3.2$ 

(note the one empty line)

whereas:

bash-3.2$ python2.5 -c "import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)"
bash-3.2$ 

(no empty line)

The funny thing is that the difference only occurs if sys.stdout is redirected; if it is not, importing pydoc doesn't change anything to the output:

bash-3.2$ python2.5 -c "import pydoc; import sys; help(sys)" | wc
     256    1298   10690
bash-3.2$ python2.5 -c "import sys; help(sys)" | wc
     256    1298   10690
bash-3.2$ 




Note that this is related to 1700304, but is actually *one specific case* since *only one character* is not redirected - I would expect them all or none

----------
components: Library (Lib)
messages: 101479
nosy: farialima
severity: normal
status: open
title: Importing pydoc and overwriting sys.stdout, causes one char to be sent to the console when calling help()
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8198>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:26:11 2010
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Granade?=)
Date: Mon, 22 Mar 2010 05:26:11 +0000
Subject: [issue1700304] pydoc.help samples sys.stdout and sys.stdin at import
	time
Message-ID: <1269235571.73.0.122094303331.issue1700304@psf.upfronthosting.co.za>


Fran?ois Granade <francois at granade.com> added the comment:

issue8198 is related.

Re. 1700304, it's easy to work around by writing

from pydoc import help
import sys
help.output = sys.stdout
help.input = sys.stdin

----------
nosy: +farialima

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700304>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:44:47 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 22 Mar 2010 05:44:47 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269236687.28.0.0205549516509.issue6543@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

>From a cursory glance, I don't see any problems with this patch.  Though I admit that I don't know the traceback code nearly as well as you, Amaury.  The tests pass on py3k trunk on my Linux box.

If you want other review, perhaps ask on python-dev?

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:45:02 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 22 Mar 2010 05:45:02 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269236702.93.0.55595577877.issue6543@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Mon Mar 22 06:56:28 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 22 Mar 2010 05:56:28 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1269237388.2.0.966598491483.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I'm attaching a test for Ctrl-C behavior on Linux (the patch itself works on Windows too, but I am not sure how to send Ctrl-C on windows programatically and subprocess does not have this functionality either).

The test_pdb2.py module is generic and can be extended to test other functionality. But, as discussed earlier, it cannot be easily (if at all) integrated into existing test_pdb.py.

Note that the test module will NOT work with existing pdb (as it doesnot have expected Ctrl-C) behavior, but on can specify alternative pdb location from command line:

  env DEBUG_PDB=./pdb.py ./test_pdb2.py

----------
Added file: http://bugs.python.org/file16619/test_pdb2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Mon Mar 22 08:04:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 07:04:17 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269241457.35.0.605303943625.issue3890@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This last issue seems related to SSL 0.9.8m:
http://bugs.python.org/issue8108

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:22:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Mar 2010 08:22:41 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269246161.4.0.299316773044.issue3890@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> The intuitive explanation seems to be:
> - there are some bytes available for reading on the *TCP socket*, 
> therefore asyncore calls the read handler
> - however, there are not enough bytes for OpenSSL to actually decrypt 
> any data, which is why we get SSL_ERROR_WANT_READ when trying to read 
> from the *SSL socket*
> The following patch seems to fix test_ftplib; any thoughts?

The patch seems ok to me. This is how it was supposed to be in the first place if ssl.py behaved as expected with non blocking sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:28:41 2010
From: report at bugs.python.org (Nick)
Date: Mon, 22 Mar 2010 08:28:41 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1269246521.85.0.787509988305.issue1544339@psf.upfronthosting.co.za>


Nick <nick_bower at fastmail.fm> added the comment:

Hello is this not the fix?  Are there any plans for patch and ctypes 1.0.3?  ctypes is a setuptools dependency for various Python 3rd party packages, and this breaks any that enlist ctypes on Solaris.

http://sourceware.org/ml/libffi-discuss/2010/msg00016.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:52:13 2010
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Cauwelier?=)
Date: Mon, 22 Mar 2010 08:52:13 +0000
Subject: [issue8199] zipfile.py: consistency between "write" and "writestr"
In-Reply-To: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>
Message-ID: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>


New submission from Herv? Cauwelier <herve at itaapy.com>:

Hi,

In class "ZipFile", method "write" accepts "compress_type" parameter but not the "writestr" method.

I see no reason for this limitation and the change is trivial.

This is needed for generating ODF documents since the mimetype file must not be compressed, contrary to other parts.

For now, I've copied the block of code that create a "ZipInfo" object in that "writestr" method.

The attached patch shows the desired change.

Thanks

----------
components: Library (Lib)
files: writestr-compress_type.diff
keywords: patch
messages: 101486
nosy: herve at itaapy.com
severity: normal
status: open
title: zipfile.py: consistency between "write" and "writestr"
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file16620/writestr-compress_type.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8199>
_______________________________________

From report at bugs.python.org  Mon Mar 22 09:54:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 08:54:01 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1269248041.28.0.775105811968.issue8047@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

http://codereview.appspot.com/664043 (patch against 3.x)

IIUC, the changes proposed (for 3.2) are:
 - default encoding or bool(encoding) == False
   ==> fallback to 'US-ASCII' encoding (instead of Unicode)
 - encoding=str or encoding='unicode'
   ==> serialize to Unicode

And it changes the behavior of :
 - ET.write()
 - tostring()
 - tostringlist()

For 2.x we could add the options for Unicode output:
 - encoding=unicode
 - and encoding='unicode'

----------
assignee: georg.brandl -> effbot
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:09:34 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 22 Mar 2010 09:09:34 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1269248974.38.0.037113908177.issue8047@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

> Supporting unicode for lxml.etree compatibility is fine with me, but I
> think it might make sense to support the string "unicode" as well (as
> a pseudo-encoding -- it's pretty clear to me that nobody will ever
> define a real character encoding with that name :-).

The reason I chose the unicode type over a 'unicode' string name at the time was that I wanted to make a clear distinction to show that this is not just selecting a different codec but that it changes the output type.

I don't really care either way, though, given that this reads a lot less well in Py3. If ET supports both, lxml will follow.

Stefan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:29:27 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 09:29:27 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The logging module errors out if the multiprocessing module is not finished loading when logging.log() is called.

This can happen, for example, if a custom import hook is defined that causes third-party code to execute when the multiprocessing module gets to an import statement.  (autoinstall is an example of a package that defines such an import hook: http://pypi.python.org/pypi/autoinstall/0.1a2 )

Here is a stack trace of the issue in action:

  File "/Users/chris_g4/dev/apple/WebKit-git/WebKitTools/Scripts/webkitpy/executive.py", line 118, in cpu_count
    import multiprocessing
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/multiprocessing/__init__.py", line 60, in <module>
    import os
  File "/Users/chris_g4/dev/apple/WebKit-git/WebKitTools/Scripts/webkitpy/thirdparty/autoinstall.py", line 279, in find_module
    _logger.debug("find_module(%s, path=%s)" % (fullname, path))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1036, in debug
    self._log(DEBUG, msg, args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1164, in _log
    record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1139, in makeRecord
    rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 279, in __init__
    self.processName = sys.modules['multiprocessing'].current_process().name
AttributeError: 'module' object has no attribute 'current_process'


Here is a possible fix (in logging/__init__.py):

         if not logMultiprocessing:
             self.processName = None
         # "current_process" might not be defined if multiprocessing is
         # not finished loading yet.  This can happen, for example, if
         # a custom import hook is defined that causes third-party code
         # to execute when the multiprocessing module calls import.
-        elif 'multiprocessing' not in sys.modules:
+        elif 'multiprocessing' not in sys.modules or \
+             'current_process' not in dir(sys.modules['multiprocessing']):
             self.processName = 'MainProcess'
         else:
             self.processName = sys.modules['multiprocessing'].current_process().name
         if logProcesses and hasattr(os, 'getpid'):
             self.process = os.getpid()

----------
components: Library (Lib)
messages: 101489
nosy: cjerdonek
severity: normal
status: open
title: logging module errors out if log called when multiprocessing module not finished loading
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:36:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Mar 2010 09:36:32 +0000
Subject: [issue8047] Serialiser in ElementTree returns unicode strings in Py3k
In-Reply-To: <1269248974.38.0.037113908177.issue8047@psf.upfronthosting.co.za>
Message-ID: <4BA73A1C.70100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Behnel wrote:
> 
> Stefan Behnel <scoder at users.sourceforge.net> added the comment:
> 
>> Supporting unicode for lxml.etree compatibility is fine with me, but I
>> think it might make sense to support the string "unicode" as well (as
>> a pseudo-encoding -- it's pretty clear to me that nobody will ever
>> define a real character encoding with that name :-).
> 
> The reason I chose the unicode type over a 'unicode' string name at the time was that I wanted to make a clear distinction to show that this is not just selecting a different codec but that it changes the output type.
> 
> I don't really care either way, though, given that this reads a lot less well in Py3. If ET supports both, lxml will follow.

There's always the possibility of adding a new official codec
called 'unicode' which converts Unicode to Unicode as no-op.

This may also be useful to have in other situations where you
want to signal a special case for Unicode input or output.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8047>
_______________________________________

From report at bugs.python.org  Mon Mar 22 10:46:01 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 09:46:01 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269251161.1.0.725082431003.issue8200@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:22:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 10:22:42 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1269253362.7.0.722255977834.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

See this post, about Solaris failure:
http://bugs.python.org/issue1544339#msg101485

And the proposed patch:
http://sourceware.org/ml/libffi-discuss/2010/msg00016.html

----------
nosy: +nick

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:30:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 10:30:04 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1269253804.92.0.842424708614.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ignore my last comment. It is not relevant, and the patch is already in 3.0.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:34:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 10:34:47 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269254087.78.0.970351844131.issue6543@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Mon Mar 22 11:38:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Mar 2010 10:38:40 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1269254320.23.0.563396351932.issue1544339@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please try the subversion trunk of Python, and report whether this works for you?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Mon Mar 22 12:56:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Mar 2010 11:56:02 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1268958662.39.0.686646187747.issue7643@psf.upfronthosting.co.za>
Message-ID: <4BA75ACE.4000704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> Backward compatibility concern:
>  * it adds VT u'\x0b' and FF u'\x0c' as line breaks.
> 
> The choice is either to preserve backward compatibility, or to comply with the specification (UAX #14).

I think we should correct this bug together with a clear warning in
the Misc/NEWS file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:00:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 12:00:37 +0000
Subject: [issue2223] regrtest.py -R not working
In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za>
Message-ID: <1269259237.6.0.870544900618.issue2223@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

No known issues with "regrtest -R :" on trunk.

----------
nosy: +flox
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2223>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:08:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 12:08:23 +0000
Subject: [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1269259703.66.0.397166896814.issue5035@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_tkinter patch (r70641) was backported to py3k as r70707. py3k compiles fine without threads.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5035>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:19:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 12:19:28 +0000
Subject: [issue8201] test_logging fails if the loggerDict contains non-ASCII
	loggers.
In-Reply-To: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>
Message-ID: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Following test case fails with a UnicodeDecodeError:

import logging
import logging.config
logging.getLogger("\xab\xd7\xbb")
logging.getLogger(u"LOG")
logging.config.dictConfig({'version': 1})


Same behavior on "non-ASCII" path buildbots, when test_lib2to3 is run before test_logging. It happens because "test_lib2to3" set a logger with key u"<string>".
IMHO, it should be fixed in the logging module.

----------
assignee: vinay.sajip
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
keywords: buildbot
messages: 101497
nosy: benjamin.peterson, flox, haypo, vinay.sajip
priority: normal
severity: normal
stage: test needed
status: open
title: test_logging fails if the loggerDict contains non-ASCII loggers.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8201>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:21:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 12:21:27 +0000
Subject: [issue8201] test_logging fails if the loggerDict contains non-ASCII
	loggers.
In-Reply-To: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>
Message-ID: <1269260487.84.0.969218014445.issue8201@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patch with tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file16621/issue8201_logging_config.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8201>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:34:40 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Mar 2010 12:34:40 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269261280.29.0.4661600423.issue8200@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

A slightly more generic fix checked into trunk (r79279), please verify in your environment.

----------
assignee:  -> vinay.sajip
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:42:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 12:42:08 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269261728.2.0.400874706226.issue8200@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I would suggest something like:

if logMultiprocessing:
    try:
        self.processName = sys.modules['multiprocessing'] .current_process().name
    except StandardError:
        self.processName = 'MainProcess'
else:
    self.processName = None

----------
nosy: +flox
priority:  -> normal
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:56:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 12:56:54 +0000
Subject: [issue1583863] __str__ cannot be overridden on unicode-derived classes
Message-ID: <1269262614.98.0.941046988032.issue1583863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r79278+r79280 (trunk), r79281 (py3k), r79282 (3.1), r79283 (2.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1583863>
_______________________________________

From report at bugs.python.org  Mon Mar 22 13:57:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 12:57:04 +0000
Subject: [issue1583863] __str__ cannot be overridden on unicode-derived classes
Message-ID: <1269262624.98.0.845474516698.issue1583863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1583863>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:00:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 13:00:33 +0000
Subject: [issue1503789] Cannot write source code in UTF16
Message-ID: <1269262833.04.0.665535745001.issue1503789@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This feature was requested only once, 4 years ago, so I don't think that the feature is a "must-have" :-)

I think that a lot of code have to be modified in Python parser to support UTF-16-* and UTF-32-* codecs. Since there is no working patch, I consider that I can close this issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503789>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:02:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 13:02:57 +0000
Subject: [issue1069092] segfault on printing nested sequences of None/Ellipsis
Message-ID: <1269262977.15.0.338591026776.issue1069092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is 6 years old. Python has some protections against stack overflow, but there is no perfect solution. Since there is no patch, I consider that I can close this issue (as wont fix).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1069092>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:03:38 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Mar 2010 13:03:38 +0000
Subject: [issue8201] test_logging fails if the loggerDict contains non-ASCII
	loggers.
In-Reply-To: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>
Message-ID: <1269263018.76.0.570516573661.issue8201@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk (r79284).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8201>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:05:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 13:05:30 +0000
Subject: [issue4261] The pwd module doesn't distinguish between errors and no
	user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1269263130.28.0.224071148047.issue4261@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is open since 2 years without any patch. It looks like the feature request is not really important, and I consider that we can close it. Reopen the issue (with a patch!) if you consider that this ticket is important.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:06:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 13:06:24 +0000
Subject: [issue4261] The pwd module doesn't distinguish between errors and no
	user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1269263184.18.0.908656011808.issue4261@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:55:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Mar 2010 13:55:32 +0000
Subject: [issue4261] The pwd module doesn't distinguish between errors and no
	user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1269266132.53.0.0474301567577.issue4261@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, since this is a real,fixable bug but nobody has stepped forward with a patch, I think it is better make its status 'languishing' with the reason 'no one has stepped forward with a patch'.  This kind of thing is exactly what we introduced languishing for.  And two years is nothing ;)

----------
components: +Extension Modules -Library (Lib)
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
resolution: wont fix -> accepted
stage:  -> test needed
status: closed -> languishing
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________

From report at bugs.python.org  Mon Mar 22 14:58:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 13:58:24 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1269241457.35.0.605303943625.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269266411.3782.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This last issue seems related to SSL 0.9.8m:
> http://bugs.python.org/issue8108

I don't think so:

$ rpm -qv openssl
openssl-0.9.8k-5.1mdv2010.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:02:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Mar 2010 14:02:54 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1269266574.03.0.373163465284.issue7860@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Ah, that's simple enough :)

Minor changes to the test patch: uname caches it's results, so I added a few lines to clear the cache before the uname calls. In order to not affect other tests, the whole thing is in a try/finally so we don't leave anything behind in cache.

The test passes on both a 32 and 64 bit Python.

----------
Added file: http://bugs.python.org/file16622/uname_WOW64_test2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:15:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Mar 2010 14:15:13 +0000
Subject: [issue8199] zipfile.py: consistency between "write" and "writestr"
In-Reply-To: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>
Message-ID: <1269267313.44.0.94111262423.issue8199@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Given that this is a feature request, it would go into 2.7 rather than 2.6.

The patch will need a test (see Lib/test/test_zipfile.py) and a documentation update (see Doc/library/zipfile.rst).

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8199>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:17:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Mar 2010 14:17:33 +0000
Subject: [issue8199] zipfile.py: consistency between "write" and "writestr"
In-Reply-To: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>
Message-ID: <1269267453.05.0.157462636106.issue8199@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Actually this was recently fixed on trunk (r78097) and py3k (r78098). See #6003.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8199>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:25:59 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Mar 2010 14:25:59 +0000
Subject: [issue8156] pybsddb 4.8.4 integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1269267959.55.0.0466067404857.issue8156@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Integration committed as r79285.

The integration is with just released pybsddb 4.8.4, with patches for issue6462 and issue3892 added.

----------
title: pybsddb 4.8.3+ integration -> pybsddb 4.8.4 integration

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8156>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:47:31 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Mar 2010 14:47:31 +0000
Subject: [issue2960] bsddb/test/test_replication.py bus error, segfault,
	assertion error, pass
In-Reply-To: <1211685483.73.0.203518027491.issue2960@psf.upfronthosting.co.za>
Message-ID: <1269269251.93.0.587175421638.issue2960@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2960>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:57:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 14:57:48 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1269246161.4.0.299316773044.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269269973.3782.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch seems ok to me. This is how it was supposed to be in the
> first place if ssl.py behaved as expected with non blocking sockets.

Ok, patch applied.

In light of the recv() and recv_into() implementation change, I also
think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents
blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

See description in
http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html:

? SSL_MODE_AUTO_RETRY

        Never bother the application with retries if the transport is
        blocking. If a renegotiation take place during normal operation,
        a SSL_read(3) or SSL_write(3) would return with -1 and indicate
        the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
        environment applications must be prepared to handle incomplete
        read/write operations. In a blocking environment, applications
        are not always prepared to deal with read/write operations
        returning without success report. The flag SSL_MODE_AUTO_RETRY
        will cause read/write operations to only return after the
        handshake and successful completion. ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Mon Mar 22 15:59:16 2010
From: report at bugs.python.org (Daniel Serodio)
Date: Mon, 22 Mar 2010 14:59:16 +0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1269269956.7.0.61870844212.issue1124861@psf.upfronthosting.co.za>


Daniel Serodio <dserodio at gmail.com> added the comment:

Ah, it works now. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:32:44 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Mar 2010 15:32:44 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1269271964.95.0.306702019307.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Roumen Petrov (rpetrov) wrote:
>>
>> Jes?s Cea Avi?n<jcea at jcea.es>  added the comment:
>>
>> I just did the minimal change. I don't know if removing "defined(HAVE_MAKEDEV)" is safe.

> The python build system is full with minimal changes and result is a
> big mess. Did you found which revision add ".. defined(HAVE_MAKEDEV)"
> in posix*.c ?

The code was added in 2002-07-30 by nnorwitz, to support OSF1 (Dec Unix). Is that platform still supported?. I don't see any related  buildbot.

>> "HAVE_DEVICE_MACROS" is defined if "configure" finds "makedev()" macro.

> And what is result on you platform ?

It is defined if I add the new "include".


> Cases:
> 1) platform is no longer supported - it is save to remove test case from 
> configure and defined(HAVE_MAKEDEV) from posixmodule.c

Do we have a list of officially supported?.

> 2) HAVE_DEVICE_MACROS is defined for you . Then check how is written 
> test for HAVE_DEVICE_MACROS and make test for makedev similar.

Investigating the issue, I could say that HAVE_MAKEDEV should be deleted, but I don't have access to a OSF1 machine for trying.

How should I proceed?

----------
nosy:  -barry, rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:39:56 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Mar 2010 15:39:56 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269272396.53.0.760077931051.issue8200@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's structured the way it is for two reasons:
 1. IMO It's better (more readable) to have the simpler case in the "then" clause and the more complicated case in the "else" clause.
 2. If multiprocessing is not used, the process name needs to be set anyway to "MainProcess". So, I've structured it so the assignment is in just one place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 16:58:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 15:58:32 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269273512.44.0.144978872434.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I finally agree that test_ftplib should be patched.
The patch isn't exactly correct: it should ideally retry the unwrap() call later, rather than simply ignore the error. But since it's just used for testing, it looks sufficient.

(we probably lack a higher-level abstraction around ssl sockets, especially non-blocking ones; there's too many domain-specific stuff to know for the average programmer.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:09:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 16:09:42 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1269274182.86.0.611848180551.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79288 and r79295.

----------
priority:  -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:37:14 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Mar 2010 16:37:14 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1269275834.65.0.352540667198.issue3928@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

My browser keeps deleting nosy.  Sorry.

Roumen, please read.

----------
nosy: +barry, rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Mar 22 17:57:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Mar 2010 16:57:25 +0000
Subject: [issue1069092] segfault on printing nested sequences of None/Ellipsis
Message-ID: <1269277045.17.0.743405625582.issue1069092@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

General policy is that ordinary code (not using, for instance, ctypes) should not crash or segfault the interpreter.  I believe there is a 'crashers' subdirectory somewhere in the tree for examples that do so that people so inclined can work on them.

The OP reported a crash on 2.3/2.4a on Linux, but not 1.5. I could not reproduce it on 2.2 on Windows. Instead, I (properly) got an exception. Trying again with 3.1, I get a similar exception: RuntimeError: maximum recursion depth exceeded while getting the repr of a tuple. List instead of tuple does similar.

If 
>>> t=None,
>>> for i in range(50000): t = t,None

>>> print(t)

still crashes on 2.6/2.7, at least with Linux, then there is still a bug to be fixed and the issue should be left open. If it now raises an exception as above, then this should be closed as fixed.

I am pretty sure this issue has nothing to do with None and Ellipsis but only with the structure (not necessarily a sequence) being deeply, deeply nested. So I think the title should be: "Segfault on printing deeply nested structures."

I think the deeper issue is the use of recursion on the C stack to print. If the print routine instead usee iteration with an auxiliary Python stack (list), then there should be no stack overflow to worry about. [When in increase the recursion limit to 100000 and try to print the 50000 nested tuples, I get "MemoryError: stack overflow" instead of the RuntimeError above. So there might be more than one fix needed.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1069092>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:03:01 2010
From: report at bugs.python.org (David Bonner)
Date: Mon, 22 Mar 2010 17:03:01 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1269277381.2.0.00404512511425.issue1625@psf.upfronthosting.co.za>


David Bonner <dbonner at vmware.com> added the comment:

Picking this back up again.  There's actually no docs changes necessary...the docs never mentioned that the module didn't support multiple logical streams, and I didn't see any other mentions in the docs that seemed to need updating.  I supposed I could add something along the lines of "BZ2File supports multiple logical streams in a single compressed file", if that's what you/re looking for.

Working on a patch for trunk as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:24:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 17:24:04 +0000
Subject: [issue7666] test_lib2to3 fails if path contains space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1269278644.76.0.467373255348.issue7666@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file15818/lib2to3_path_with_space.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7666>
_______________________________________

From report at bugs.python.org  Mon Mar 22 18:28:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 17:28:54 +0000
Subject: [issue7666] test_lib2to3 fails if path contains space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1269278934.06.0.816776368597.issue7666@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ultimate pach, tested with this insane path:

>>> os.getcwdu()
u'/home/user/dev/python/py2u;\u2026 \u2192 u"n\\ic\'ode'

It should fix some buildbot failures.

----------
assignee:  -> benjamin.peterson
components: +2to3 (2.x to 3.0 conversion tool) -Tests
keywords: +buildbot, patch
nosy: +pitrou
priority:  -> normal
resolution:  -> accepted
Added file: http://bugs.python.org/file16623/lib2to3_path_with_space_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7666>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:19:37 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 18:19:37 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269281977.25.0.784769895838.issue8200@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Reversing the if-else in Florent's suggestion seems to address points (1) and (2).  Is there a reason to set and check an mp variable rather than simply having the try-except block?

if not logMultiprocessing:
    self.processName = None
else:
    # Errors may occur if multiprocessing has not finished loading
    # yet - e.g. if a custom import hook causes third-party code
    # to run when multiprocessing calls import. See issue 8200
    # for an example
    try:
        self.processName = sys.modules['multiprocessing'].current_process().name
    except StandardError:
        self.processName = 'MainProcess'

Thanks for the quick action!  I'll try in my dev environment when this is settled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:21:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Mar 2010 18:21:53 +0000
Subject: [issue8196] sqlit3.paramstyle reported as 'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269282113.19.0.907336402206.issue8196@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ghaering
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8196>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:22:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Mar 2010 18:22:09 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1269282129.8.0.16930253321.issue7860@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patches applied to trunk in r79294, py3k in r79298.  Should this be backported?

----------
keywords:  -needs review
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:45:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Mar 2010 18:45:04 +0000
Subject: [issue1069092] segfault on printing nested sequences of None/Ellipsis
Message-ID: <1269283504.68.0.851700052182.issue1069092@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On linux: on Py3 (trunk and 3.1) I get the recursion depth exceeded message, but on py2 trunk I get the segfault if I use 100000 for the range.  So somebody fixed this crasher in py3, somehow.

----------
nosy: +r.david.murray
resolution: wont fix -> 
stage:  -> needs patch
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1069092>
_______________________________________

From report at bugs.python.org  Mon Mar 22 19:45:45 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Mar 2010 18:45:45 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269281977.25.0.784769895838.issue8200@psf.upfronthosting.co.za>
Message-ID: <271520.40101.qm@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

----- Original Message ----

Reversing the if-else in Florent's suggestion seems to 
> address points (1) and (2).  Is there a reason to set and check an mp 
> variable rather than simply having the try-except block?

Just that it went over the 80-column limit :-)

Also, I know about asking forgiveness rather than permission, but Florent's change doesn't make clear the intent to call current_process only if multiprocessing has already been imported (i.e. is in sys.modules). In other words, he would catch both the KeyError and any error due to an incomplete import of multiprocessing. While either version will work, the way I have it preserves the original intent and only traps errors due to multiprocessing being incompletely imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:04:36 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 19:04:36 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269284676.34.0.487973934933.issue8200@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I agree.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Mon Mar 22 20:47:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Mar 2010 19:47:41 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1269282129.8.0.16930253321.issue7860@psf.upfronthosting.co.za>
Message-ID: <4BA7C95A.4020407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Patches applied to trunk in r79294, py3k in r79298.  Should this be backported?

I don't think so: applications relying on the previous behavior
would need to be updated and requiring this for a patch level
release of Python is not a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:01:09 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 22 Mar 2010 20:01:09 +0000
Subject: [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1269288069.4.0.347200683299.issue6352@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Apparently this was never backported to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6352>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:19:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 20:19:40 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1269289180.94.0.455503103895.issue7512@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed the simple patch in r79299 (trunk), r79300 (2.6), r79301 (py3k), r79302 (3.1). Tarek suggested a test could be added for this, assigning the issue to him.

----------
assignee: pitrou -> tarek
nosy: +tarek
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Mon Mar 22 21:21:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 20:21:46 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When you execute "python -m package" the package is first imported with sys.argv[0] set to '-c' (and sys.modules['__main__'] exists but is empty. Then package.__main__.py is executed with the correct sys.argv[0].

This means module level code executed during the initial import that attempts to work out how the code is being executed can't use either sys.modules['__main__'] *or* sys.argv[0].

----------
assignee: ncoghlan
messages: 101531
nosy: michael.foord, ncoghlan
severity: normal
status: open
title: sys.argv[0] and python -m package
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:05:22 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Mar 2010 21:05:22 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Install 3.1.2 -> Open IDLE -> Open "About IDLE" dialog -> click on "Credits"

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/aboutDialog.py", line 123, in ShowIDLECredits
    self.display_file_text('About - Credits', 'CREDITS.txt', 'iso-8859-1')
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/aboutDialog.py", line 138, in display_file_text
    textView.view_file(self, title, fn, encoding)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/textView.py", line 76, in view_file
    return view_text(parent, title, textFile.read())
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1540-1543: invalid data

----------
components: IDLE
messages: 101532
nosy: srid
severity: normal
status: open
title: IDLE about dialog credits raises UnicodeDecodeError
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:11:08 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Mar 2010 21:11:08 +0000
Subject: [issue8204] test_ttk_guionly assertion error on 3.x linux 64-bit
In-Reply-To: <1269292268.26.0.854483419941.issue8204@psf.upfronthosting.co.za>
Message-ID: <1269292268.26.0.854483419941.issue8204@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This happens on 3.1.2 Linux 64-bit.

test test_ttk_guionly failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python3.1/tkinter/test/test_ttk/test_widgets.py", line 708, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.183072530064' != '.183072529552'

----------
components: Tests, Tkinter
messages: 101533
nosy: srid
severity: normal
status: open
title: test_ttk_guionly assertion error on 3.x linux 64-bit
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8204>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:14:35 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Mar 2010 21:14:35 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269292475.68.0.932843030637.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> The patch isn't exactly correct: it should ideally retry the unwrap() 
> call later, rather than simply ignore the error. But since it's just 
> used for testing, it looks sufficient.

Actually unwrap() should already be called.
What the patch does is returning in case of ERROR_WANT_READ/WRITE, and *explicitly avoids to close() the connection when such an event occurs*.

This should grant that another asyncore poll() loop is executed, handle_close() automatically be called again and so unwrap().

As I said in comment #100977 I'm not 100% sure of this since I've not been able to reproduce the issue. I'm just presuming this as I know that asyncore works like this with plain-text sockets.

I'd like to make sure this works as expected even if it's just a test.
If some of the folks able to reproduce this issue could confirm that unwrap() gets called again it would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:14:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Mar 2010 21:14:44 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1269292484.88.0.273899156075.issue7026@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Re-opening. test_urllib in 3.1.2 fail similarly (on Linux 64-bit):

test_urllib
Warning: os.environ was modified by test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python3.1/test/test_urllib.py", line 122, in setUp
    for k in os.environ.keys():
  File "/home/apy/rrun/tmp/autotest/apy/lib/python3.1/_abcoll.py", line 404, in __iter__
    for key in self._mapping:
  File "/home/apy/rrun/tmp/autotest/apy/lib/python3.1/os.py", line 404, in __iter__
    for key in self.data:
RuntimeError: dictionary changed size during iteration

----------
status: closed -> open
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7026>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:24:38 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 22 Mar 2010 21:24:38 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1269293078.91.0.0925374013607.issue3928@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

>>> "HAVE_DEVICE_MACROS" is defined if "configure" finds "makedev()" macro.
>> And what is result on you platform ?
>It is defined if I add the new "include".

a) Why you touch test case for "AC_MSG_CHECKING(for major, minor, and makedev)
AC_TRY_LINK([
#if defined(MAJOR_IN_MKDEV)
#include <sys/mkdev.h>
#elif defined(MAJOR_IN_SYSMACROS)
#include <sys/sysmacros.h>
#else
#include <sys/types.h>
#endif
],[
  makedev(major(0),minor(0));
],[
  AC_DEFINE(HAVE_DEVICE_MACROS, 1,
	    [Define to 1 if you have the device macros.])
  AC_MSG_RESULT(yes)
],[
  AC_MSG_RESULT(no)
])"
?
Sorry I did't understand why this test case fail for you.


b) PEP 11 list unsupported platforms and OSF1 is not listed.

c) So code if from revision 27820 that fix "SF patch #584245, get python to link on OSF1 (Dec Unix)" . The current patch as is will break OSF1 and other OS-es (as example linux don't define this header). Just adding new include will fail test case and will left as undefined HAVE_MAKEDEV => mknod won't be added for those platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Mar 22 22:55:37 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 22 Mar 2010 21:55:37 +0000
Subject: [issue1027206] unicode DNS names in socket, urllib, urlopen
Message-ID: <1269294937.43.0.373674815616.issue1027206@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

I was about to report this for the socket module - the gethostbyname(), gethostbyname_ex() and getnameinfo() functions are the only things currently affected in that module as far as I can see.  3.x is affected too - the functions will pass non-ASCII Unicode to the system as UTF-8 there.  The attached patch fixes them in 2.x and 3.x.

----------
keywords: +patch
nosy: +baikie
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16624/idna.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1027206>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:05:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Mar 2010 22:05:39 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269295539.52.0.157795313484.issue8202@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, the problem here is we don't *know* the module filename until we get hold of the loader for it (see _get_module_details() in runpy). And it is the process of finding the loader for the __main__ module that does the initial import of the package as a side effect.

Added Brett to the nosy list in case I've not thought of something obvious.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:18:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 22:18:05 +0000
Subject: [issue8205] test_multiprocessing failure
In-Reply-To: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

r79165 seems to be the culprit

Traceback (most recent call last):
  File "/home/antoine/cpython/trunk/Lib/test/regrtest.py", line 864, in runtest_inner
    indirect_test()
  File "/home/antoine/cpython/trunk/Lib/test/test_multiprocessing.py", line 2028, in test_main
    run(suite)
  File "/home/antoine/cpython/trunk/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/home/antoine/cpython/trunk/Lib/test/test_support.py", line 565, in _filterwarnings
    raise AssertionError("unhandled warning %r" % reraise[0])
AssertionError: unhandled warning ImportWarning("Not importing directory '/home/antoine/cpython/trunk/Modules/zlib': missing __init__.py",)

----------
assignee: flox
components: Tests
messages: 101539
nosy: flox, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing failure
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8205>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:18:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 22:18:10 +0000
Subject: [issue8205] test_multiprocessing failure
In-Reply-To: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269296290.47.0.426076836961.issue8205@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8205>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:21:09 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Mar 2010 22:21:09 +0000
Subject: [issue7666] test_lib2to3 fails if path contains space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1269296469.45.0.903988966609.issue7666@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Resolved in r79304.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7666>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:23:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 22:23:36 +0000
Subject: [issue8205] test_multiprocessing failure
In-Reply-To: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269296616.63.0.00997230050224.issue8205@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It happens only when sysconfig.is_python_build() is True (i.e. build directory).

Proposed patch fixes it.

----------
keywords: +patch
Added file: http://bugs.python.org/file16625/issue8205_sys_path.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8205>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:43:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Mar 2010 22:43:53 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269297833.85.0.796647746336.issue8202@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nick is right that importing package.__main__ requires importing package.__init__ first.

But it sounds like Michael really just wants some way to know when runpy is being used over something else. Could a special string token like "<runpy>" or "<-m>" be placed in sys.argv until it is back-patched to what it will eventually become? That should allow Michael to find out what whether runpy was being used or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:45:17 2010
From: report at bugs.python.org (Eric Promislow)
Date: Mon, 22 Mar 2010 22:45:17 +0000
Subject: [issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

Title should be self-explanatory.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101543
nosy: ericp
severity: normal
status: open
title: 2to3 doesn't convert 'types.InstanceType' to 'object'
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8206>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:45:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 22:45:55 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269297955.61.0.942024532306.issue8202@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I've already fixed my specific usecase (for unittest), but a special value in sys.argv[0] would indeed have met my needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:46:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 22:46:19 +0000
Subject: [issue7667] test_doctest fails with non-ascii path
In-Reply-To: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>
Message-ID: <1269297979.95.0.808216671715.issue7667@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Really fixed with r79307.

----------
superseder: test_doctest fails when run in verbose mode -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7667>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:46:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 22:46:27 +0000
Subject: [issue7667] test_doctest fails with non-ascii path
In-Reply-To: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>
Message-ID: <1269297987.57.0.971998482657.issue7667@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7667>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:48:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 22:48:33 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269298113.95.0.114208691483.issue8202@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

'-c' isn't helpful because that is also the content of sys.argv[0] when a module is imported in response to "python -c '...'".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:58:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Mar 2010 22:58:39 +0000
Subject: [issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269298719.66.0.659421150592.issue8206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this conversion is correct. If there is a test for InstanceType, there is (IMO) a fifty-fifty-chance that it is there to distinguish old-style and new-style classes, so converting it to object is most likely to break the code.

People who actually want this conversion to happen could replace types.InstanceType with

  getattr(types, 'InstanceType', object)

or add

try:
  from types import InstanceType
except ImportError:
  InstanceType = object

to the top of the module; this would then work for both 2.x and 3.x (assuming that replacing InstanceType with object is actually correct in the code in question).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8206>
_______________________________________

From report at bugs.python.org  Mon Mar 22 23:59:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 22:59:31 +0000
Subject: [issue8205] test_multiprocessing failure
In-Reply-To: <1269296616.63.0.00997230050224.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269298879.5792.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It happens only when sysconfig.is_python_build() is True (i.e. build directory).
> 
> Proposed patch fixes it.

Can't say whether the patch is ok, but I confirm it does fix the issue
here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8205>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:00:44 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 23:00:44 +0000
Subject: [issue8200] logging module errors out if log called when
	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269298844.77.0.610091253664.issue8200@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

FYI, I verified the fix in my local environment.  Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8200>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:23:52 2010
From: report at bugs.python.org (Nick)
Date: Mon, 22 Mar 2010 23:23:52 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1269300232.09.0.295797136165.issue1544339@psf.upfronthosting.co.za>


Nick <nick_bower at fastmail.fm> added the comment:

Unfortunately I also get core dump applying that patch alone.

core 'core' of 12847:   /usr/local/Python-2.4.6-SunCC/bin/python setup.py test
 feaf0cfe ffi_call_SYSV (fefb0fc8, 8045898, feaf0b08, feaf08e4, 8045880, 4) + 66
 feaf0caf ffi_call_SYSV (feaf08e4, 8045880, 4, 1, 8045920, fe95133c) + 17
 feaf0b08 ffi_call (80458b0) + 64
 feaeb47a _call_function_pointer (1001, fe95133c, 8045910, 8045900, 82a27bc, 804
5920) + 86
 feaebad0 _CallProc (fe95133c, 842298c, 1001, 0, 82e1e74, 0) + 2dc
 feae8408 CFuncPtr_call (83fe304, 842298c, 0, 8422a6c) + 190
 08063423 PyObject_Call (83fe304, 842298c, 0, 8063423) + 23
 080b308c do_call  (83fe304, 8045aec, 1, 0) + 54
 080b2806 call_function (8045aec, 1, cd24f104, 82ca2cc) + ae
 080afd91 PyEval_EvalFrame (8275154, 815ded4, 82b30b4, 0) + 27a1
 080b1782 PyEval_EvalCodeEx (82ba460, 82b30b4, 0, 8262388, 1, 826238c) + 8ba
 080b2cd6 fast_function (82ca2cc, 8045c9c, 1, 1, 0, 80f1740) + 15a
 080b2822 call_function (8045c9c, 0, a0, 0) + ca

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:30:54 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Mon, 22 Mar 2010 23:30:54 +0000
Subject: [issue8196] sqlit3.paramstyle reported as 'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269300654.79.0.347620165775.issue8196@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks for bringing this up.

By changing this we would maybe be a little bit closer to PEP 0249. I don't get why the PEP author thinks that 'qmark' is less clear than 'numeric', though. I think they're equally clear.

The real reason why I object changing anything here, however, is that by changing the paramstyle we would break backwards compatibility. Third-party software like ORMs might depend on sqlite3 having paramstyle 'qmark'.

So now someone might suggest to make paramstyle an instance of a subclass of string that will successfully compare against both 'qmark' and 'named'. To which possible suggestion I say forget it. You cannot anticipate how people will really access the paramstyle. And if it would make a difference in real-world scenarios.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8196>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:37:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Mar 2010 23:37:39 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1269301059.35.0.176802000498.issue1544339@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

nick: not sure what "this patch" is that you tried applying. What about Python trunk?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:38:03 2010
From: report at bugs.python.org (Eric Promislow)
Date: Mon, 22 Mar 2010 23:38:03 +0000
Subject: [issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269301083.71.0.810116535759.issue8206@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

I'm working on a debugger, trying to identify instances of
old-style classes in Python 2, and any class in Python 3.
The getattr formulation will work, but because I already
need to maintain an "is_v3" flag, I might as well use it
here.

As a side note, how are instances of new-style classes in
v2 categorized?  This v2 code prints 'None':

import types
def get_type_name(target_type):
  for t in dir(types):
    if target_type == getattr(types, t):
      return t

class C(object):
  pass

c = C()
print get_type_name(type(c))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8206>
_______________________________________

From report at bugs.python.org  Tue Mar 23 00:52:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Mar 2010 23:52:27 +0000
Subject: [issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269301947.87.0.919499499701.issue8206@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In a sense, *all* objects are instances of new-style classes in 2.x, including instances of old-style classes (which are instances of the InstanceType type, which is a type, and hence a new-style class).

You may want to look at the __flags__ property of the type object. If it is a heap type, there is a good chance that it was created through a class statement. Alternatively, you can look at the type's __module__, and find out whether the module is a Python module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8206>
_______________________________________

From report at bugs.python.org  Tue Mar 23 01:13:10 2010
From: report at bugs.python.org (Bertrand Janin)
Date: Tue, 23 Mar 2010 00:13:10 +0000
Subject: [issue8139] ossaudiodev not initializing its types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1269303190.72.0.775094558043.issue8139@psf.upfronthosting.co.za>


Bertrand Janin <tamentis at neopulsar.org> added the comment:

This is still an issue in Python 3.1.2 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8139>
_______________________________________

From report at bugs.python.org  Tue Mar 23 01:29:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Mar 2010 00:29:51 +0000
Subject: [issue8139] ossaudiodev not initializing its types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1269304191.32.0.2263042576.issue8139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r79317 (py3k) and r79318 (3.1). Thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8139>
_______________________________________

From report at bugs.python.org  Tue Mar 23 02:21:25 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Mar 2010 01:21:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1269307285.93.0.156311106118.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100323.zip is a new version of the regex module.

It now includes a test script. Most of the tests come from the existing test scripts.

----------
Added file: http://bugs.python.org/file16626/issue2636-20100323.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Mar 23 02:28:02 2010
From: report at bugs.python.org (Santiago Gala)
Date: Tue, 23 Mar 2010 01:28:02 +0000
Subject: [issue8196] sqlit3.paramstyle reported as 'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269307682.02.0.635211623726.issue8196@psf.upfronthosting.co.za>


Santiago Gala <sgala at apache.org> added the comment:

I don't think they are equally clear, at least from the point of view of the code written towards the API. I think that

execute("UPDATE authors set name = ?, email = ?, comment = ? WHERE id = ?", (form.name, form.email, form.text, form.id))

is way less clear, more verbose, and prone to alignment errors, than

execute("UPDATE authors set name = :name, email = :email, comment = :text WHERE id = :id", form)

I think this is the reason why the PEP writer prefer named style and. I was about to recode an example using a dictionary for cleaner code, when I noticed the bug. Now I need to hardcode that sqlite3 supports 'named' style, even if paramstyle says other thing, or to dynamically test, in case they decide to remove support for the next release. Both are ugly alternatives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8196>
_______________________________________

From report at bugs.python.org  Tue Mar 23 02:56:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Mar 2010 01:56:12 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1269309372.49.0.840476189302.issue7860@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7860>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:43:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 05:43:22 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

With r79207 (Issue8180) applied to trunk, seeing this failure (10.6.2, HFS+ case-sensitive file system):

======================================================================
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep277.py", line 119, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_24797_tmp/\xe2\x80\x82\xe2\x80\x82\xe2\x80\x82A'

----------------------------------------------------------------------
Ran 30 tests in 0.237s

FAILED (errors=1)
test test_pep277 failed -- Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep277.py", line 119, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_24797_tmp/\xe2\x80\x82\xe2\x80\x82\xe2\x80\x82A'

----------
messages: 101559
nosy: flox, ned.deily
severity: normal
status: open
title: test_pep277 fails on OS X
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:52:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 05:52:37 +0000
Subject: [issue8208] test_issue7820 fails: "name '?' is not defined"
In-Reply-To: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>
Message-ID: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Trunk running on OS X 10.6.2:

======================================================================
ERROR: test_issue7820 (test.test_pep263.PEP263Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep263.py", line 39, in test_issue7820
    self.assertRaises(SyntaxError, eval, '\xff\x20')
  File "/private/tmp/pp/usr/local/lib/python2.7/unittest/case.py", line 444, in assertRaises
    callableObj(*args, **kwargs)
  File "<string>", line 1, in <module>
NameError: name '?' is not defined

----------------------------------------------------------------------

----------
components: Tests
messages: 101560
nosy: haypo, ned.deily
severity: normal
status: open
title: test_issue7820 fails: "name '?' is not defined"
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8208>
_______________________________________

From report at bugs.python.org  Tue Mar 23 06:57:51 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 23 Mar 2010 05:57:51 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1269323871.86.0.757089854093.issue2919@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Tue Mar 23 08:00:33 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 23 Mar 2010 07:00:33 +0000
Subject: [issue8196] sqlit3.paramstyle reported as 'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269327633.42.0.645257437173.issue8196@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I said qmark vs numeric. I. e. vs:

execute("UPDATE authors set name = :1, email = :2, comment = :3 WHERE id = :4", (form.name, form.email, form.text, form.id))

The sqlite3 module will always support both paramstyles qmark and named, simply because that is what the underlying SQLite engine supports. What paramstyle says is mostly important for third-party software that works across multiple DB-API compliant database modules. paramstyle enables them to use database supported parameter binding.

In reality, though, there will hardly be a wrapper for DB-API modules that does *not* need to special-case anything depending on the underlying database. So they will hardly ever rely only on the paramstyle and threadsafety parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8196>
_______________________________________

From report at bugs.python.org  Tue Mar 23 08:39:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 07:39:32 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269329972.56.0.996001841555.issue8207@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also this failure on py3k:

======================================================================
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/pp3/usr/local/lib/python3.2/test/test_pep277.py", line 119, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_42408_tmp/\u2002\u2002\u2002A'

----------------------------------------------------------------------

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 09:23:51 2010
From: report at bugs.python.org (Nick)
Date: Tue, 23 Mar 2010 08:23:51 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1269332631.53.0.548980461942.issue1544339@psf.upfronthosting.co.za>


Nick <nick_bower at fastmail.fm> added the comment:

Martin, the patch is for libffi included in ctypes 1.0.2.  This is python 2.4 (required for plone/zope) so python 2.5/2.6 etc is not a possibility.

ctypes 1.0.2 compiles with this patch but then core dumps anyway during tests so false hope.

It appears to me that no-one is maintaining this separate ctypes code-base anymore so I'll have to ditch dependencies that use it (Shapely) unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Tue Mar 23 09:42:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 08:42:00 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269333720.92.0.488523206096.issue8207@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch should fix it...
"HFS Plus uses a variant of Normal Form D in which U+2000 through U+2FFF, U+F900 through U+FAFF, and U+2F800 through U+2FAFF are not decomposed."

<rant>
I believed there was only one Unicode...
But obviously the Apple's Unicode is something different.
</rant>

----------
assignee:  -> flox
components: +Macintosh, Unicode
keywords: +patch
nosy: +michael.foord
priority:  -> normal
resolution:  -> accepted
stage:  -> patch review
Added file: http://bugs.python.org/file16627/issue8207_pep277_for_os_x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 09:44:41 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Mar 2010 08:44:41 +0000
Subject: [issue8209] OptionParser keyword arg 'epilog' not mentioned in the
	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

I was looking for some option in optparse module which will allow me to add custom help text after the generated help. Realized that OptionParser class has a keyword argument 'epilog' for the same purpose. 
But this is not been explained in the documentation, other keyword args are covered.

----------
assignee: orsenthil
components: Documentation
messages: 101565
nosy: orsenthil
priority: normal
severity: normal
status: open
title: OptionParser keyword arg 'epilog' not mentioned in the docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8209>
_______________________________________

From report at bugs.python.org  Tue Mar 23 09:53:47 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Mar 2010 08:53:47 +0000
Subject: [issue8209] OptionParser keyword arg 'epilog' not mentioned in the
	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269334427.14.0.878706991165.issue8209@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 79329.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8209>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:13:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Mar 2010 09:13:34 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269333720.92.0.488523206096.issue8207@psf.upfronthosting.co.za>
Message-ID: <4BA88639.1030100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <florent.xicluna at gmail.com> added the comment:
> 
> This patch should fix it...
> "HFS Plus uses a variant of Normal Form D in which U+2000 through U+2FFF, U+F900 through U+FAFF, and U+2F800 through U+2FAFF are not decomposed."

Could you provide a reference link for this quote ?

It's rather strange that those ranges are not decomposed,
since they do contain combining code points.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:40:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 09:40:36 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269337236.46.0.659177515093.issue8207@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Actually, the file system in question is what Apple calls a HFSX case-sensitive (see http://developer.apple.com/mac/library/technotes/tn/tn1150.html#HFSX).  On a typical OS X system, you could encounter any combination of HFS+ case-insensitive, HFSX case-insensitive, HFSX case-sensitive file systems, along with other usual suspects, like NFS or SMB.  I'll note again the warning in r33595.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 10:44:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Mar 2010 09:44:06 +0000
Subject: [issue8209] OptionParser keyword arg 'epilog' not mentioned in the
	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269337446.87.0.0469406680189.issue8209@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged into release26-maint branch - 79331

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8209>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:10:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 10:10:20 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269339020.35.0.71169636613.issue8207@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Could you provide a reference link for this quote ?

I put the link in the patch:
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 11:43:16 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 10:43:16 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269340996.45.0.986695151572.issue8207@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the patch for trunk, the test no longer fails on the given file system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:43:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 11:43:45 +0000
Subject: [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1269344625.54.0.0150310895379.issue6352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Apparently this was never backported to 3.1.

done: r79335 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6352>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:45:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 11:45:50 +0000
Subject: [issue7668] test_httpservers fails with non-ascii path
In-Reply-To: <1263147324.56.0.696076411083.issue7668@psf.upfronthosting.co.za>
Message-ID: <1269344750.33.0.0187433460314.issue7668@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79297

----------
priority:  -> normal
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7668>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:48:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 11:48:42 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1269344922.55.0.992156618905.issue7880@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7880>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:50:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 11:50:09 +0000
Subject: [issue8133] test_imp fails on OS X; filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1269345009.48.0.416153847196.issue8133@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8133>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:51:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 23 Mar 2010 11:51:41 +0000
Subject: [issue8205] test_multiprocessing failure
In-Reply-To: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269345101.25.0.780922706373.issue8205@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed with r79310.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8205>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:56:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Mar 2010 11:56:52 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1269345412.9.0.121705262651.issue8158@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Senthil documented epilog in issue 8209.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Tue Mar 23 12:57:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Mar 2010 11:57:55 +0000
Subject: [issue8209] OptionParser keyword arg 'epilog' not mentioned in the
	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269345475.88.0.520004663413.issue8209@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 8158.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8209>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:09:06 2010
From: report at bugs.python.org (Attila Nagy)
Date: Tue, 23 Mar 2010 12:09:06 +0000
Subject: [issue8210] rev 78820 causes problems on Solaris (Python 2.6)
In-Reply-To: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>
Message-ID: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>


New submission from Attila Nagy <nagy.attila at yahoo.com>:

The check-in http://svn.python.org/view?view=rev&revision=78820 causes problems on Solaris (SXCE 125, ksh, Studio 12).

configure output:
[...]
checking for --with-pydebug... no
./configure: test: unknown operator ==

"test" on Solaris does not accept "==". "=" works okay.

----------
components: Build
messages: 101577
nosy: attila
severity: normal
status: open
title: rev 78820 causes problems on Solaris (Python 2.6)
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8210>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:14:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 12:14:08 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

configure.in uses AC_PROG_CC, extract of the autoconf manual:
(http://www.delorie.com/gnu/docs/autoconf/autoconf_64.html)
 
 If using the GNU C compiler, set shell variable GCC to `yes'. If output variable CFLAGS was not already set, set it to `-g -O2' for the GNU C compiler (`-O2' on systems where GCC does not accept `-g'), or `-g' for other compilers.

Python does already set the optimization level in its OPT variable: for gcc, it uses -O3 by default, and not -O option (in this case, gcc disables all optimisations, it's like -O0) if --with-pydebug is used.

Because of AC_PROG_CC, Python is compiled with -O2 even if --with-pydebug is used, which is bad because it's harder to debug an optimized program: most variable are unavailable (gcc prints "<optimized out>").

Another problem is that AC_PROG_CC eats user CFLAGS. It's not possible to specify: ./configure CFLAGS="myflags".

On the autoconf mailing list, I saw a simple "trick": 

   Save CFLAGS before you call AC_PROG_CC, and restore it after, 
   if you don't want "-g -O2".

Attached patch implements that. Results:
 * ./configure: CFLAGS=$(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
 * ./configure --with-pdebug CFLAGS="-O0": CFLAGS=$(BASECFLAGS) -O0 $(OPT) $(EXTRA_CFLAGS)

It works :-)

----------
components: Build
files: configure_cflags.patch
keywords: patch
messages: 101578
nosy: haypo
severity: normal
status: open
title: configure: ignore AC_PROG_CC hardcoded CFLAGS
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16628/configure_cflags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 13:52:02 2010
From: report at bugs.python.org (Stefan Praszalowicz)
Date: Tue, 23 Mar 2010 12:52:02 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1269348722.24.0.270044579147.issue4999@psf.upfronthosting.co.za>


Stefan Praszalowicz <deubeulyou at gmail.com> added the comment:

I just got surprised by this, and I agree that updating the doc would be nice, because as of now, it states quite explicitly that "the Queue and JoinableQueue types are multi-producer, multi-consumer FIFO queues".

----------
nosy: +Stefan.P
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:28:32 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Mar 2010 13:28:32 +0000
Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an
	object
In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za>
Message-ID: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The tp_dealloc of a type can chose to resurrect an object.  the subtype_dealloc() in typeobject.c does this when it calls the tp_del() member and it has increased the refcount.

The problem is, that if you subclass a custom C object, and that C object's tp_dealloc() chooses to resurrect a dying object, that doesn't go well with subtype_dealloc().

After calling basedealloc() (line 1002 in typeobject.c), the object's type is decrefed.  But if the object was resurrected by basedealloc() this shouldn't have been done.  The object will be alive, but the type will be missing a reference.  This will cause a crash later.

This could be fixable if we knew somehow after calling basedealloc() if the object were still alive.  But we cannot check "self" because it may have died.

The only way out of this conundrum that I can see is to change the signature of tp_dealloc() to return a flag, whether it did actually delete the object or not.

Of course, I see no easy way around not clearing the slots, but the clearing of the dict could be postponed until after the call to basedealloc().

Since tp_dealloc _can_ resurrect objects (subtype_dealloc does it), subclassing such objects should work, and not crash the interpreter if the base class' dp_dealloc() decides to do so.
No suggested

----------
messages: 101580
nosy: krisvale
severity: normal
status: open
title: A tp_dealloc of a subclassed class cannot resurrect an object
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8212>
_______________________________________

From report at bugs.python.org  Tue Mar 23 14:42:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 23 Mar 2010 13:42:53 +0000
Subject: [issue8210] rev 78820 causes problems on Solaris (Python 2.6)
In-Reply-To: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>
Message-ID: <1269351773.84.0.671778818616.issue8210@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8210>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:01:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2010 14:01:34 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269352894.63.0.0508863940352.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another update, partly to address comments raised by Guido on Rietveld.  I'll upload these changes to Rietveld later today.

 - rename sys._hash_info to sys.hash_info and make it public rather than private (it still needs docs somewhere)

 - add some explanatory comments to long_hash; remove an outdated comment

 - fix missing error check (in previous patch) in slot_tp_hash.  slot_tp_hash also now always raises a TypeError if __hash__ returns a non-integer;  this is a change from current behaviour, which allows small floats to be returned by __hash__, but not large floats (where large means > 2**31 or > 2**63 in absolute value, depending on the system).  I'm assuming this was unintentional (the docs specify that __hash__ should return an integer).

 - simplify specification of hash function slightly:  for nonnegative x it simply computes the reduction of x;  previously it computed 1 + reduction of (x-1) for positive values.  This extra +-1 doesn't really add anything of value, and makes it slightly more complicated and error-prone to write your own hash function.

----------
Added file: http://bugs.python.org/file16629/numeric_hash4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:27:35 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Mar 2010 14:27:35 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269354455.24.0.842670107826.issue8202@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I realised today that this behaviour is actually the case for any execution of a module inside a package with -m (i.e. any __init__ modules execute before sys.argv and __main__ are fully configured).

As I recall, I used a bit of a hack to get main.c to implement -m correctly by piggybacking on the existing -c semantics. I'll find the hack and replace it with some proper '-c' or '-m' logic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Tue Mar 23 15:57:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2010 14:57:47 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1269356267.83.0.16630560363.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re-opening to address a couple of points that came out of the python-dev discussion:

(1) As Stefan pointed out on python-dev, equality and inequality comparisons involving signaling nans should signal (order comparisons already do).  IEEE 754 is fairly clear on this.  From section 6.2:

"""Signaling NaNs shall be reserved operands that, under default exception handling, signal the invalid operation exception (see 7.2) for every general-computational and signaling-computational operation except for the conversions described in 5.12."""

(Comparisons fall under 'signaling-computational operations, in section 5.6 of the standard.)

I propose to fix this for 2.7 and 3.2.

(2) Currently hash(Decimal("nan")) raises a TypeError.  I can see no good reason for this at all;  it's possible to hash float nans and to put them in sets and dictionaries.  I propose to remove this restriction for 2.7 and 3.2.  I think hash(Decimal("snan")) should also succeed:  *computational* operations on signaling nans should signal, but I don't think that putting a signaling nan into a dict, or checking for its presence in a list, counts as a computational operation for this purpose.

----------
assignee:  -> mark.dickinson
priority:  -> high
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:20:15 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Tue, 23 Mar 2010 15:20:15 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>


New submission from Noam Yorav-Raphael <noamraph at gmail.com>:

Hello,

Python 3.1 ignored the PYTHONUNBUFFERED environment variable and the '-u' switch (which do the same thing): stdout remains buffered even when the flag is raised.

To reproduce, run:
> python3 -u -c 'import time, sys; sys.stdout.write("a"); time.sleep(1); sys.stdout.write("\n")'

You can see that it first waits a second and then 'a' is printed.

I'm using Ubuntu 9.10. Tested this on both the 3.1.1 installed and svn checkout (revision 79345).

This follows a bug report: https://bugs.launchpad.net/dreampie/+bug/545012
which was reported on win32, so the problem is there too.

----------
components: IO
messages: 101584
nosy: noam
severity: normal
status: open
title: Python 3 ignored PYTHONUNBUFFERED and -u
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:25:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Mar 2010 15:25:40 +0000
Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an
	object
In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za>
Message-ID: <1269357940.63.0.0128115998533.issue8212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. The io module has had to circumvent this and uses the following snippet when resurrecting an instance of a subclass of one of its types (see iobase_dealloc() in Modules/_io/iobase.c):

        /* When called from a heap type's dealloc, the type will be
           decref'ed on return (see e.g. subtype_dealloc in typeobject.c). */
        if (PyType_HasFeature(Py_TYPE(self), Py_TPFLAGS_HEAPTYPE))
            Py_INCREF(Py_TYPE(self));
        return;


I agree it would be nice to have an automatic way of handling this. I don't see an obvious solution, though.

----------
components: +Interpreter Core
nosy: +benjamin.peterson, pitrou
priority:  -> normal
stage:  -> needs patch
type: crash -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8212>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:29:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 15:29:27 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269358167.67.0.249528257265.issue8213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

-u is not ignored, but use line buffering: see issue #4705 and commit r68977.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:29:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 15:29:51 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269358191.28.0.235992306561.issue8213@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:33:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Mar 2010 15:33:51 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269358431.68.0.938924989029.issue8213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In the current state of affaires this is more of a documentation issue.

Python 3 doesn't support totally unbuffered text I/O (and standard streams are open in text mode). What `-u` and PYTHONUNBUFFERED do is that the binary layer of standard streams is unbuffered, but the text layer is still line-buffered (if in a tty).

"python --help" gives you an accurate description:

-u     : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
         see man page for details on internal buffering relating to '-u'

Also, you can try out:

python3 -u -c  'import time, sys; sys.stdout.buffer.write(b"b"); time.sleep(1); sys.stdout.buffer.write(b"\n")'

To explicitly flush the text layer, you can use the flush() method.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Tue Mar 23 16:35:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Mar 2010 15:35:04 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269358504.07.0.802107740824.issue8213@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl
components: +Documentation -IO
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:20:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 23 Mar 2010 17:20:17 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1269364817.81.0.0415043177262.issue1222585@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:28:59 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 23 Mar 2010 17:28:59 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1269365339.91.0.528628425511.issue1222585@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

To have proper support for C++ linking in distutils2 at least in when used with Python 2.7, Makefile should set a variable, which will specify default C++ linker. I think that LDCXXSHARED can be used as a name for this new variable. I'm attaching the patch for configure.in and Makefile.pre.in.

----------
Added file: http://bugs.python.org/file16630/python-LDCXXSHARED.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue Mar 23 18:50:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Mar 2010 17:50:22 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269366622.29.0.47521625526.issue8211@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:07:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Mar 2010 18:07:37 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269367657.61.0.417546400325.issue8211@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Setting CFLAGS is broken in Python configure system, so it's better not to rely on it (or to fix it, but that's a major task - the whole CFLAGS and LDFLAGS system used in Python's configure has over the years turned into a complete mess).

You should get the same result by using ./configure OPT="-O0".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:09:23 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 23 Mar 2010 18:09:23 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269367763.85.0.238291482017.issue8211@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:38:47 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 23 Mar 2010 18:38:47 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1269369527.52.0.0101523522998.issue6645@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This also breaks pydoc on AIX (Python 2.6.5).

help> modules pydoc

Here is a list of matching modules.  Enter any module name to get more help.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/qatest/APy/lib/python2.6/site.py", line 438, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1722, in __call__
    self.interact()
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1740, in interact
    self.help(request)
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1760, in help
    self.listmodules(split(request)[1])
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1865, in listmodules
    apropos(key)
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1965, in apropos
    ModuleScanner().run(callback, key)
  File "/home/qatest/APy/lib/python2.6/pydoc.py", line 1930, in run
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
  File "/home/qatest/APy/lib/python2.6/pkgutil.py", line 110, in walk_packages
    __import__(name)
  File "/home/qatest/APy/lib/python2.6/multiprocessing/__init__.py", line 63, in <module>
    from multiprocessing.process import Process, current_process, active_children
  File "/home/qatest/APy/lib/python2.6/multiprocessing/process.py", line 286, in <module>
    _current_process = _MainProcess()
  File "/home/qatest/APy/lib/python2.6/multiprocessing/process.py", line 283, in __init__
    self._authkey = AuthenticationString(os.urandom(32))
  File "/home/qatest/APy/lib/python2.6/os.py", line 756, in urandom
    raise NotImplementedError("/dev/urandom (or equivalent) not found")
NotImplementedError: /dev/urandom (or equivalent) not found

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:41:47 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Mar 2010 18:41:47 +0000
Subject: [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1269369707.03.0.152518377041.issue7782@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can you produce a more tightly focused test, the minimum code that would have segfaulted your change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7782>
_______________________________________

From report at bugs.python.org  Tue Mar 23 19:53:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 18:53:43 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269370423.99.0.274063836288.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> (or to fix it, but that's a major task - the whole CFLAGS 
> and LDFLAGS system used in Python's configure has over the
> years turned into a complete mess).

What do you mean by "a complete mess"? Did you try my patch? Is it enough to fix this issue?

A least, my patch is enough to disable all compilation optimization if --with-pydebug option is used (which was my first goal).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:17:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Mar 2010 19:17:47 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269370423.99.0.274063836288.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BA913D7.6040309@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> (or to fix it, but that's a major task - the whole CFLAGS 
>> and LDFLAGS system used in Python's configure has over the
>> years turned into a complete mess).
> 
> What do you mean by "a complete mess"? 

There's a discussion on some other ticket about this. Basically,
Python's configure script doesn't really allow setting CFLAGS
in a meaningful way via env vars (which it should to be standards
conform).

It adds all sorts of non-standard variables which are then combined
to build the final CFLAGS variable: BASECFLAGS, EXTRA_CFLAGS and
OPT.

> Did you try my patch? Is it enough to fix this issue?

No. It doesn't allow overriding the CFLAGS settings actually
used by the system. You'd also need to set BASECFLAGS="", OPT="" and
EXTRA_CFLAGS="" in addition to applying your patch and setting
CFLAGS to "-O0".

> A least, my patch is enough to disable all compilation optimization if --with-pydebug option is used (which was my first goal).

It unconditionally overrides CFLAGS - even if it is not set and
defined by AC_PROG_CC as "-g -O2". That would need to be corrected.

Other than that it does help a little work around the mess :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:17:52 2010
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 23 Mar 2010 19:17:52 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
In-Reply-To: <1269332631.53.0.548980461942.issue1544339@psf.upfronthosting.co.za>
Message-ID: <4BA913D8.3000109@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> It appears to me that no-one is maintaining this separate ctypes
> code-base anymore so I'll have to ditch dependencies that use it
> (Shapely) unfortunately.

This is correct, the separate ctypes code base is linked via svn:external
into the core Python svn repository.  Unfortunately, the Python trunk ctypes
code does not compile with earlier Python versions any more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:33:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2010 19:33:09 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1269372789.24.0.707568342946.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I think hash(Decimal("snan")) should also succeed

On second thoughts, this would be bad, since it would lead to unpredictable results for sets of dicts containing a signaling nan:

>>> from decimal import Decimal
[69536 refs]
>>> s = Decimal('snan'); h = hash(s)
[69551 refs]
>>> {s, h+1}    # can put most integers into a set with an sNaN
{Decimal('sNaN'), 373955814}
[69561 refs]
>>> {s, h}      # but not if that integer hashes equal to the sNaN...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 864, in __eq__
    ans = self._check_nans(other, context)
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 746, in _check_nans
    self)
  File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 3842, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: sNaN
[69698 refs]

So if __eq__ with an sNaN raises an exception, there's little choice but to prohibit putting sNaNs into sets and dicts, and the obvious way to do this is to make __hash__ raise too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Tue Mar 23 20:49:36 2010
From: report at bugs.python.org (Tom Zych)
Date: Tue, 23 Mar 2010 19:49:36 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1269373776.2.0.419736083235.issue7936@psf.upfronthosting.co.za>


Tom Zych <freethinker at pobox.com> added the comment:

I'm getting something like this on Windows 7:

C:\>assoc .py
.py=Python.File

C:\>ftype Python.File
Python.File="C:\Python31\py31.exe" "%1" %*

C:\>args.py 1 2 3
Python version: sys.version_info(major=3, minor=1, micro=1, releaselevel='final', serial=0)
Command-line args: 1
['C:\\args.py']

C:\>\python31\py31 args.py 1 2
Python version: sys.version_info(major=3, minor=1, micro=1, releaselevel='final', serial=0)
Command-line args: 3
['args.py', '1', '2']

----------
nosy: +tomzych

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:33:11 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Mar 2010 20:33:11 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1269376391.93.0.98947807662.issue7936@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I've read on a random forum somewhere that % need to be doubled on Windows 7.
Tom, can you try changing the association by typing
   FTYPE Python.File="C:\Python31\py31.exe" "%%1" %%*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:44:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Mar 2010 20:44:53 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1269377093.02.0.55629187781.issue7279@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch (against py3k) to make all comparisons involving signaling nans raise InvalidOperation.

Stefan, does this look okay to you?

----------
keywords: +patch
Added file: http://bugs.python.org/file16631/issue7279.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Tue Mar 23 21:59:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Mar 2010 20:59:53 +0000
Subject: [issue8210] rev 78820 causes problems on Solaris (Python 2.6)
In-Reply-To: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>
Message-ID: <1269377993.27.0.750068038807.issue8210@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks. Fixed in r79351.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8210>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:07:55 2010
From: report at bugs.python.org (Attila Nagy)
Date: Tue, 23 Mar 2010 21:07:55 +0000
Subject: [issue8210] rev 78820 causes problems on Solaris (Python 2.6)
In-Reply-To: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>
Message-ID: <1269378475.1.0.409226735413.issue8210@psf.upfronthosting.co.za>


Attila Nagy <nagy.attila at yahoo.com> added the comment:

Thank you, that was fast! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8210>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:18:51 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Mar 2010 21:18:51 +0000
Subject: [issue8206] 2to3 doesn't convert 'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269379131.89.0.408417852095.issue8206@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Closing 2to3 request.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8206>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:25:54 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 23 Mar 2010 21:25:54 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1269379554.91.0.634469687735.issue1222585@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I could not found reasons python build to support C++ compiler as all source is C!
Another case is distutils where is possible external module to use C++ code.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:27:33 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 23 Mar 2010 21:27:33 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269379653.01.0.0840296326925.issue6081@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have created a new patch, that should be satisfying now. There is help (though it is quite small, I tried to mimic those that were already in unicode.c) and tests. Right now format_using_mapping is called like this:

format_using_mapping(mapping, *args)

where mapping is a subscriptible object, that will be pushed to kwargs and the following args are used just like in normal format. This should be as similar to the normal format as possible.

There are also tests, including usage presented in the ticket.

----------
Added file: http://bugs.python.org/file16632/6081_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Tue Mar 23 22:40:34 2010
From: report at bugs.python.org (Tom Zych)
Date: Tue, 23 Mar 2010 21:40:34 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1269380434.8.0.0278703897861.issue7936@psf.upfronthosting.co.za>


Tom Zych <freethinker at pobox.com> added the comment:

No joy :(

I tried putting double-quotes around %%*, that didn't work either. Tried single-quotes too, just in case it works like a Bourne-type shell.

BTW I forgot to set 3.1 on my earlier message.

That business about having to double the % rings a faint bell from the old MS-DOS days, though. Can't remember. Something about, it will interpret it once, so you have to make sure it comes out the way you want after it does that. (Which is old hat to anyone who does much programming in a Unix shell, but it was new to me back then.) I remember it was rather difficult to get it right.

----------
components: +Library (Lib) -IO
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:12:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Mar 2010 22:12:13 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Sean Reifschneider proposed [1] adding the ability to log an exception using the syslog module.

My proposed implementation is along the lines of:

def logexceptions(chain=True):
    import sys
    import traceback
    import syslog

    # Should we chain to the existing sys.excepthook?
    current_hook = sys.excepthook if chain else None

    def syslog_exception(etype, evalue, etb):
        if current_hook:
            current_hook(etype, evalue, etb)
        # The result of traceback.format_exception might contain
        # embedded newlines, so we have the nested loops.
        for line in traceback.format_exception(etype, evalue, etb):
            for line in line.rstrip().split('\n'):
                syslog.syslog(line)
    sys.excepthook = syslog_exception

Although it would need to be written in C to work in the existing syslog module, and of course it would call syslog.syslog directly.


[1] http://mail.python.org/pipermail/python-ideas/2010-March/006927.html

----------
messages: 101605
nosy: eric.smith, jafo
priority: normal
severity: normal
stage: needs patch
status: open
title: Add exception logging function to syslog module
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:13:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Mar 2010 22:13:14 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269382394.24.0.108256195978.issue8214@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:29:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 22:29:02 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://docs.python.org/py3k/c-api/arg.html contains some ambiguous (string or Unicode object) definitions: what is a string? what is an unicode object? Is it a string or not? The problem is that the documentation is for Python2: the code was changed, but not the documentation. I think that it can be replaced by (unicode objet) with lower U to be consistent with (bytes object).

---

There are two functions: getbuffer() and convertbuffer().

getbuffer(): pb=arg->ob_type->tp_as_buffer
 - if pb->bf_getbuffer is not NULL: call PyObject_GetBuffer(arg, view, PyBUF_SIMPLE) and PyBuffer_IsContiguous(view, 'C')
 - if pb->bf_getbuffer is NULL: call convertbuffer()

convertbuffer() calls PyObject_GetBuffer(arg, &view, PyBUF_SIMPLE).

---

"s#", "y", "z" formats use convertbuffer()

"s", "y*", "z*" formats uses getbuffer().

"t" format reimplements convertbuffer().

"w*" format calls PyObject_GetBuffer(arg, (Py_buffer*)p, PyBUF_WRITABLE) and PyBuffer_IsContiguous((Py_buffer*)p, 'C').

"w" and "w#" formats call PyObject_GetBuffer(arg, &view, PyBUF_SIMPLE).

I think that all these cases should be factorized in one unique function.

Is it a bug, or functions using "s#", "y", "z", "t" formats do really support discontinious buffers?

Related PEP: http://www.python.org/dev/peps/pep-3118/

----------
components: Interpreter Core
messages: 101606
nosy: haypo
severity: normal
status: open
title: getargs.c in Python3 contains some TODO and the documentation is outdated
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:40:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 22:40:16 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1269384016.14.0.797201143359.issue8215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #2322.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:44:04 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Tue, 23 Mar 2010 22:44:04 +0000
Subject: [issue8216] Nur jetzt beste Software zu besten Preisen!
In-Reply-To: <9985340552.MB9N7E62837578@sapzsxhlyoyd.kfnuasmdp.com>
Message-ID: <9985340552.MB9N7E62837578@sapzsxhlyoyd.kfnuasmdp.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Heute nur! Beste Software zum besten Preis!

In unserem  online-Geschaeft finden Sie eine riesige Auswahl, ein grosses Sortiment der besten Software. Qualitaet jedes Programms geprueft! Hier bekommen Sie das Beste nur! 
Jetzt Bekommen Sie Software Einfach Billiger

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Newsletter.

Redmiller LTD
4347 Bottom Lane
Southfield MI 48075

Copyright (C) 2010 Redmiller LTD All rights reserved.

----------
files: unnamed
messages: 101608
nosy: nobody
severity: normal
status: open
title: Nur jetzt beste Software zu besten Preisen!
Added file: http://bugs.python.org/file16633/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8216>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://ryzywuxym.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Heute nur! Beste Software zum besten Preis!</h1>
				    <p>In unserem  online-Geschaeft finden Sie eine riesige Auswahl, ein grosses Sortiment der besten Software. Qualitaet jedes Programms geprueft! Hier bekommen Sie das Beste nur! </p><a href="http://ryzywuxym.spaces.live.com">Jetzt Bekommen Sie Software Einfach Billiger</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://ryzywuxym.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://ryzywuxym.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Newsletter.</p>

					    <p>Redmiller LTD<br>4347 Bottom Lane<br>Southfield MI 48075</p>
					    <p>Copyright (C) 2010 Redmiller LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Tue Mar 23 23:44:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:44:16 +0000
Subject: [issue8216] Nur jetzt beste Software zu besten Preisen!
Message-ID: <1269384256.43.0.244946028031.issue8216@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8216>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:44:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:44:19 +0000
Subject: [issue8216] Nur jetzt beste Software zu besten Preisen!
Message-ID: <1269384259.34.0.348023535925.issue8216@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16633/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8216>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:44:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:44:31 +0000
Subject: [issue8216] spam
Message-ID: <1269384271.59.0.792712652089.issue8216@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: Nur jetzt beste Software zu besten Preisen! -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8216>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:54:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:54:42 +0000
Subject: [issue8187] spam
Message-ID: <1269384882.47.0.184986135699.issue8187@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8187>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:54:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:54:45 +0000
Subject: [issue8187] spam
Message-ID: <1269384885.55.0.868003556988.issue8187@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16603/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8187>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:55:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:55:28 +0000
Subject: [issue8186] spam
In-Reply-To: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>
Message-ID: <1269384928.94.0.653763447634.issue8186@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16602/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8186>
_______________________________________

From report at bugs.python.org  Tue Mar 23 23:55:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 22:55:32 +0000
Subject: [issue8186] spam
Message-ID: <1269384932.45.0.28680595898.issue8186@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8186>
_______________________________________

From report at bugs.python.org  Wed Mar 24 00:12:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Mar 2010 23:12:03 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269385923.51.0.111815929792.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure I'm wild about the *args parameter. Calling "Fred" the 0-th parameter here seems non-intuitive:

"My name is {0}".format_using_mapping({}, 'Fred')

If you're going to have *args, why not **kwargs and then merge/update the dicts? I'm being facetious, but I think even having *args is feature creep.

I think it's time to ask about this on python-dev. I'd vote for not using *args. It can always be added in the future if it's seen as a hole in the API.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Wed Mar 24 00:20:36 2010
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 23 Mar 2010 23:20:36 +0000
Subject: [issue8217] typo  unterlying
In-Reply-To: <1269386436.19.0.823512367997.issue8217@psf.upfronthosting.co.za>
Message-ID: <1269386436.19.0.823512367997.issue8217@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/howto/webservers.html

The low-level view

When a user enters a web site, his browser makes a connection to the site?s webserver (this is called the request). The server looks up the file in the file system and sends it back to the user?s browser, which displays it (this is the response). This is roughly how the unterlying protocol, HTTP works.

----------
assignee: georg.brandl
components: Documentation
messages: 101610
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: typo  unterlying
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8217>
_______________________________________

From report at bugs.python.org  Wed Mar 24 00:31:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Mar 2010 23:31:40 +0000
Subject: [issue8217] typo  unterlying
In-Reply-To: <1269386436.19.0.823512367997.issue8217@psf.upfronthosting.co.za>
Message-ID: <1269387100.72.0.31571330798.issue8217@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r79358 (trunk), r79359 (release26-maint), r79360 (py3k) and r79361 (release31-maint), thanks for the report!

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8217>
_______________________________________

From report at bugs.python.org  Wed Mar 24 01:41:36 2010
From: report at bugs.python.org (Nir Aides)
Date: Wed, 24 Mar 2010 00:41:36 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269391296.08.0.748824407099.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I upload bfs.patch

To apply the patch use the following commands on updated python 3.2:
$ patch -fp1 < bfs.patch
$ ./configure

The patch replaces the GIL with a scheduler. The scheduler is a simplified implementation of the recent kernel Brain F**k Scheduler by the Linux hacker Con Kolivas:

http://ck.kolivas.org/patches/bfs/sched-BFS.txt
"The goal of the Brain Fuck Scheduler, referred to as BFS from here on, is to
completely do away with the complex designs of the past for the cpu process
scheduler and instead implement one that is very simple in basic design.
The main focus of BFS is to achieve excellent desktop interactivity and
responsiveness without heuristics and tuning knobs that are difficult to
understand, impossible to model and predict the effect of, and when tuned to
one workload cause massive detriment to another."

Con Kolivas is the hacker whose work inspired the current CFS scheduler of the Linux Kernel. 

On my core 2 duo laptop it performs as follows compared to the other patches:

1) Florent's writenums() test: ~same
2) UDP test: x6 faster
3) cpued test: works as expected, while the other patches starve the pure python threads.

cpued test spins 3 threads, 2 of them pure python and the 3rd does time.sleep(0) every ~1ms:

import threading
import time

def foo(n):
    while n > 0:
        'y' in 'x' * n
        n -= 1

def bar(sleep, name):
    for i in range(100):
        print (name, i, sleep)
        for j in range(300):
            foo(1500)
            if sleep:
                time.sleep(0)

t0 = threading.Thread(target=bar, args=(False, 't0'))
t1 = threading.Thread(target=bar, args=(False, 't1'))
t2 = threading.Thread(target=bar, args=(True, 't2-interactive'))

list(map(threading.Thread.start, [t0, t1, t2]))
list(map(threading.Thread.join, [t0, t1, t2]))


The patch is still work in progress. In particular:
1) I still need to add support for Windows.
2) It currently requires Posix clock_gettime() and assumes good timer resolution.
3) I only verified it builds on Ubuntu Karmic 64bit.
4) I still need to optimize it and address cleanup.

The scheduler is very simple, straight forward and flexible, and it addresses the tuning problems discussed recently.

I think it can be a good replacement to the GIL, since Python really needs a scheduler, not a lock.

----------
Added file: http://bugs.python.org/file16634/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:13:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 01:13:47 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1269391296.08.0.748824407099.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269393334.4874.14.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I upload bfs.patch

Interesting patch, but:
- Please give understandable benchmark numbers, including an explicit
comparison with baseline 3.2, and patched 3.2 (e.g. gilinter.patch)
- Please also measure single-thread performance, because it looks like
you are adding significant work inside the core eval loop
- Do you need a hi-res clock? gettimeofday() already gives you
microseconds. It looks like a bit of imprecision shouldn't be
detrimental.
- The magic number DEADLINE_FACTOR looks gratuitous (why 1.1^20 ?)
- By the way, I would put COND_SIGNAL inside the LOCK_MUTEX /
UNLOCK_MUTEX pair in bfs_yield().

If this gets accepted there will be cosmetic issues to watch out (and
the patch should be cross-platform).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:43:11 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:43:11 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/howto/webservers.html

The path to the interpreter in the shebang (#!/usr/bin/env python) must be currect.


Sorry man there are a great many distractions here.

----------
assignee: georg.brandl
components: Documentation
messages: 101614
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: typo currect
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:46:53 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:46:53 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395213.5.0.734363505819.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

In same file, "intermangled with Python? and it has a ?Publisher? which destignates"

intermingled?
designates?

Thanks, Dave.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:48:22 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:48:22 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395302.69.0.103921301622.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

"Another problem ist the basic concept"

                 is

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:50:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Mar 2010 01:50:02 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395402.19.0.8370669583.issue8218@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:53:38 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:53:38 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395618.5.0.76577163345.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

much easier as is is specially designed

more easily and is especially designed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:55:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Mar 2010 01:55:04 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395704.87.0.0282713678276.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Some more typos:
"The benefit from this approach is that WSGI applications can be deployed much easier as is is specially designed to host WSGI applications"
s/is is/it is/

"Pylons is much like TurboGears with ab even"
s/ab/an/

Once you finish reading it I'll fix them all at once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:55:28 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:55:28 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395728.52.0.129315440899.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

There is a number of middlewares

      are

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 02:57:07 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:57:07 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269395827.33.0.438937900353.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

you can rely an already existing

       rely on an

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 03:47:42 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 02:47:42 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269398862.38.0.851370283031.issue8218@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

There is an incredible number of frameworks
s/is/are/

The majority of users is best 
s/is/are/

o work together as good as possible.
s/good/well/

jects can be saven in a st
s/saven/saved/

Thank you.  I'm through for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:18:39 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Wed, 24 Mar 2010 06:18:39 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269411519.71.0.384212856262.issue8213@psf.upfronthosting.co.za>


Noam Yorav-Raphael <noamraph at gmail.com> added the comment:

I typed "man python3" on ubuntu 9.10 and nothing was explained about that - I now checked and found out that it displayed the python2 man page. I don't know where to find the Python 3 man page.

I don't quite see the point in having the streams buffered in one level and unbuffered in another, but I guess there's a reason.

Anyway, how can I make those streams entirely unbuffered? This is for an interactive shell called DreamPie (dreampie.sourceforge.net), and I want to resemble the behavior of the regular shell as close as possible, and it's completely unbuffered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Wed Mar 24 07:49:36 2010
From: report at bugs.python.org (showell)
Date: Wed, 24 Mar 2010 06:49:36 +0000
Subject: [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1269413376.89.0.778903528806.issue7782@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

My proposed test is final.  Please either accept or reject it as is.  I assume it runs pretty quickly, so I am not sure what the cost fear is.  The benefit of accepting the test is that it would potentially catch bugs on changes to the implementation of list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7782>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:53:39 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 24 Mar 2010 07:53:39 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1269417219.38.0.227921385619.issue6701@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Just a few comments on the code itself:

    if type_ in self.__dispatch.keys():
should be:
    if type_ in self.__dispatch:

Previously, error reporting of recursive data stated the type of the offending value; with this patch, this hint is lost (see _add_memo)

Caching of bound methods in local variables is a common optimization (dump=self._dump); why did you remove it everywhere?

Why Marshaller.dispatch was renamed to __dispatch but Unmarshaller.dispatch stays the same? (btw, why the double underscore?)

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:53:43 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 24 Mar 2010 07:53:43 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1269417223.37.0.816013455876.issue6701@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Just a few comments on the code itself:

    if type_ in self.__dispatch.keys():
should be:
    if type_ in self.__dispatch:

Previously, error reporting of recursive data stated the type of the offending value; with this patch, this hint is lost (see _add_memo)

Caching of bound methods in local variables is a common optimization (dump=self._dump); why did you remove it everywhere?

Why Marshaller.dispatch was renamed to __dispatch but Unmarshaller.dispatch stays the same? (btw, why the double underscore?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Wed Mar 24 08:59:52 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 24 Mar 2010 07:59:52 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1269417592.96.0.375922200408.issue1553375@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:08:51 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 24 Mar 2010 08:08:51 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1269418131.09.0.545637130366.issue1222585@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Python can be compiled using C++ compiler.
See http://docs.python.org/extending/extending.html#writing-extensions-in-c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:11:56 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 24 Mar 2010 08:11:56 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1269418316.19.0.0163232284241.issue1222585@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Also you would have to pass --with-cxx-main=<compiler> option to configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Wed Mar 24 09:20:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Mar 2010 08:20:26 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269418826.61.0.506581974507.issue8218@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David, can you provide these changes as a unified diff against the subversion trunk?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 10:24:25 2010
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 24 Mar 2010 09:24:25 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

http://docs.python.org/dev/py3k/library/logging.html#logging.handlers.SysLogHandler

What to use as the value for facility for SysLogHandler's constructor is not documented.  There's a reference to LOG_USER, but it's kind of vague because it doesn't specify what LOG_USER it refers to - there's no mention that SysLogHandler itself has these constants.  And the corresponding documented values from the syslog module are not compatible with the ones SysLogHandler works with.

Similarly, the values for facility and priority for SysLogHandler.encodePriority() are not documented, it just talks about integers and strings without saying what they are.

I suggest documenting all the SysLogHandler.LOG_* constants and the priority and facility mapping strings in SysLogHandler's priority_names and facility_names dicts.

----------
assignee: georg.brandl
components: Documentation
messages: 101629
nosy: georg.brandl, scop
severity: normal
status: open
title: Facility and priority values/constants not documented for SysLogHandler
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:15:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Mar 2010 11:15:17 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269429317.6.0.25388450061.issue8219@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:30:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Mar 2010 11:30:24 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269430224.78.0.627340164128.issue8219@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +vinay.sajip
priority:  -> normal
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 12:59:03 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 24 Mar 2010 11:59:03 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269431943.09.0.409461555624.issue8219@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee: georg.brandl -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:25:24 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Wed, 24 Mar 2010 12:25:24 +0000
Subject: [issue7677] distutils,
	better error message for setup.py upload -sign without identity.
In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za>
Message-ID: <1269433524.95.0.825786046138.issue7677@psf.upfronthosting.co.za>


Zubin Mithra <zubin.mithra at gmail.com> added the comment:

are you suggesting that a warning stating that 

'--identity has`nt been used'

has to be generated?

----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7677>
_______________________________________

From report at bugs.python.org  Wed Mar 24 13:58:03 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Mar 2010 12:58:03 +0000
Subject: [issue4142] smtplib doesn't clear helo/ehlo flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1269435483.18.0.0347464818457.issue4142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Support for smtpd too? (a stdlib addition in 2.7/3.2)

----------
nosy: +jcea
versions: +Python 3.1, Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4142>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:09:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 13:09:16 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269411519.71.0.384212856262.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269436258.3367.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't quite see the point in having the streams buffered in one
> level and unbuffered in another, but I guess there's a reason.

The reason is simply that it wasn't implemented. Unbuffered I/O isn't
useful very often.

> Anyway, how can I make those streams entirely unbuffered? This is for
> an interactive shell called DreamPie (dreampie.sourceforge.net), and I
> want to resemble the behavior of the regular shell as close as
> possible, and it's completely unbuffered.

You can just call flush() after each write to stdout or stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:20:19 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Mar 2010 13:20:19 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269436819.02.0.698925704606.issue8188@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Wed Mar 24 14:52:48 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Mar 2010 13:52:48 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1269438768.76.0.687940718802.issue6749@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:33:23 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 24 Mar 2010 14:33:23 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269441203.31.0.380987205564.issue8219@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Update showing strings and corresponding symbolic integers checked into trunk (r79373).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:48:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Mar 2010 14:48:34 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269442114.68.0.520837249495.issue8219@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It still doesn't say that the LOG_ constants are defined on SysLogHandler. Or is the intention that the user just use the strings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 15:52:37 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Wed, 24 Mar 2010 14:52:37 +0000
Subject: [issue8220] site.py's Quitter pollutes builtins with exit and quit
	for non-interactive use
In-Reply-To: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>
Message-ID: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

A friend wrote "exit(0)" in a script without an import of sys.  I
pointed out the error and he said "But it works".  He was right.

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 9.10
    Release:        9.10
    Codename:       karmic
    $ python --version
    Python 2.6.4
    $ python -c 'quit("foo")'
    foo
    $ echo $?
    1
    $ python -Sc 'quit("foo")'
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    NameError: name 'quit' is not defined
    $ python -c 'print quit.__class__, exit.__class__'
    <class 'site.Quitter'> <class 'site.Quitter'>
    $

site.py is polluting, to my mind, the builtin namespace with `exit' and 
`quit'.  Surely this should only happen for interactive use of python?

http://docs.python.org/library/constants.html#exit says "They are useful
for the interactive interpreter shell and should not be used in
programs." but it seems to easy for exit, especially, to be used by
mistake.

Could the pollution only happen if the Python interpreter is an
interactive one?  Or, not as good, when called, could they tell this
isn't an interactive session and error?

----------
components: Library (Lib)
messages: 101635
nosy: ralph.corderoy
severity: normal
status: open
title: site.py's Quitter pollutes builtins with exit and quit for non-interactive use
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8220>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:06:20 2010
From: report at bugs.python.org (Robert Kern)
Date: Wed, 24 Mar 2010 15:06:20 +0000
Subject: [issue8221] 2to3 mishandles StringIO inside a package with an io.py
	module
In-Reply-To: <1269443180.02.0.978577516398.issue8221@psf.upfronthosting.co.za>
Message-ID: <1269443180.02.0.978577516398.issue8221@psf.upfronthosting.co.za>


New submission from Robert Kern <robert.kern at gmail.com>:

When a module inside a package imports StringIO from cStringIO, it should change that to "from io import StringIO". However, if there is a module inside the package named io.py, 2to3 changes it to "from .io import StringIO".

[bug23]$ tree
.
`-- package
    |-- __init__.py
    |-- helper.py
    `-- io.py

1 directory, 3 files

[bug23]$ cat package/helper.py
from cStringIO import StringIO

[bug23]$ 2to3 package         
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- package/helper.py (original)
+++ package/helper.py (refactored)
@@ -1,1 +1,1 @@
-from cStringIO import StringIO
+from .io import StringIO
RefactoringTool: Files that need to be modified:
RefactoringTool: package/helper.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101636
nosy: Robert.Kern
severity: normal
status: open
title: 2to3 mishandles StringIO inside a package with an io.py module
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8221>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:11:52 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 24 Mar 2010 15:11:52 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <1269442114.68.0.520837249495.issue8219@psf.upfronthosting.co.za>
Message-ID: <372392.42938.qm@web25804.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> From: Eric Smith <report at bugs.python.org>

> It still doesn't say that the LOG_ constants are defined on 
> SysLogHandler. Or is the intention that the user just use the 
> strings?

Whoops, now fixed (I think).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:28:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Mar 2010 15:28:23 +0000
Subject: [issue8219] Facility and priority values/constants not documented for
	SysLogHandler
In-Reply-To: <372392.42938.qm@web25804.mail.ukl.yahoo.com>
Message-ID: <53018.63.251.87.214.1269444499.squirrel@mail.trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
> Whoops, now fixed (I think).

Looks good. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8219>
_______________________________________

From report at bugs.python.org  Wed Mar 24 16:45:02 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 15:45:02 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269418826.61.0.506581974507.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269445498.4445.6.camel@lambertdw>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

I apologize for the noise.
Yes, I'll read the article carefully and provide changes as a unified
diff against the subversion trunk.

On Wed, 2010-03-24 at 08:20 +0000, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> David, can you provide these changes as a unified diff against the subversion trunk?
> 
> ----------
> nosy: +loewis
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8218>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:33:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 16:33:21 +0000
Subject: [issue8222] enabling SSL_ERROR_WANT_READ on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In light of the recv() and recv_into() implementation change (issue3890), I think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

See description in
http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html:

? SSL_MODE_AUTO_RETRY

        Never bother the application with retries if the transport is
        blocking. If a renegotiation take place during normal operation,
        a SSL_read(3) or SSL_write(3) would return with -1 and indicate
        the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
        environment applications must be prepared to handle incomplete
        read/write operations. In a blocking environment, applications
        are not always prepared to deal with read/write operations
        returning without success report. The flag SSL_MODE_AUTO_RETRY
        will cause read/write operations to only return after the
        handshake and successful completion. ?

----------
components: Library (Lib)
messages: 101640
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: enabling SSL_ERROR_WANT_READ on SSL sockets
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:34:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 16:34:14 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269448454.93.0.46633863921.issue8222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: enabling SSL_ERROR_WANT_READ on SSL sockets -> enabling SSL_MODE_AUTO_RETRY on SSL sockets

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:35:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 16:35:57 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1269448557.71.0.222357067631.issue3890@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've opened a separate issue (issue8222) for the SSL_MODE_AUTO_RETRY suggestion.

This very issue has been fixed in r79226 (trunk), r79287 (py3k), r79290 (3.1) and r79291 (2.6).

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:45:13 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Wed, 24 Mar 2010 16:45:13 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269449113.38.0.204948612023.issue8213@psf.upfronthosting.co.za>


Noam Yorav-Raphael <noamraph at gmail.com> added the comment:

I can call flush() after the user code was executed, but a code like this:

>>> for i in range(10):
...     print(i, end=' ')
...     time.sleep(1)

will show the numbers only after 10 seconds, while I would like a number printed every second. I now see that that's what the regular shell does, so it's probably not a very big deal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:55:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 16:55:33 +0000
Subject: [issue8223] memoryview is not documented in the Python library doc
In-Reply-To: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>
Message-ID: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

memoryview() is not documented in the Python Library documentation, only in the C API ("buffer" chapiter) :-/
http://docs.python.org/c-api/buffer.html

See also #8215.

----------
assignee: georg.brandl
components: Documentation
messages: 101643
nosy: georg.brandl, haypo
severity: normal
status: open
title: memoryview is not documented in the Python library doc
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8223>
_______________________________________

From report at bugs.python.org  Wed Mar 24 17:56:41 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Mar 2010 16:56:41 +0000
Subject: [issue7784] patch for making list/insert at the top of the list avoid
	memmoves
In-Reply-To: <1264501685.22.0.657604584157.issue7784@psf.upfronthosting.co.za>
Message-ID: <1269449801.87.0.538001737485.issue7784@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:13:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 24 Mar 2010 17:13:47 +0000
Subject: [issue8223] memoryview is not documented in the Python library doc
In-Reply-To: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>
Message-ID: <1269450827.38.0.52771542595.issue8223@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Duplicate of #7696.

----------
nosy: +flox
resolution:  -> duplicate
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8223>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:14:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 24 Mar 2010 17:14:02 +0000
Subject: [issue8223] memoryview is not documented in the Python library doc
In-Reply-To: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>
Message-ID: <1269450842.67.0.243627894562.issue8223@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
superseder:  -> Improve Memoryview/Buffer documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8223>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:14:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 24 Mar 2010 17:14:39 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1269450879.98.0.217538859727.issue7696@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +haypo
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7696>
_______________________________________

From report at bugs.python.org  Wed Mar 24 18:16:18 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Mar 2010 17:16:18 +0000
Subject: [issue8220] site.py's Quitter pollutes builtins with exit and quit
	for non-interactive use
In-Reply-To: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>
Message-ID: <1269450978.32.0.493064889006.issue8220@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

While technically site.py could probably detect it is running in an interactive session, changing this behaviour now would be backwards-incompatible and break pre-existing code that relies on this behaviour (which has been around for a long time).

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8220>
_______________________________________

From report at bugs.python.org  Wed Mar 24 19:10:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Mar 2010 18:10:34 +0000
Subject: [issue7784] patch for making list/insert at the top of the list avoid
	memmoves
In-Reply-To: <1264501685.22.0.657604584157.issue7784@psf.upfronthosting.co.za>
Message-ID: <1269454234.15.0.748138844935.issue7784@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Mar 24 19:26:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Mar 2010 18:26:00 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Assume you have two executables in currect directory:

  baz.exe
  foo.bar.exe

Now "subprocess.Popen(['baz'])" will run successfully. But "subprocess.Popen(['foo.bar'])" will throw the following exception:

Traceback (most recent call last):
  [...]
  File "C:\Python26\lib\subprocess.py", line 483, in check_call
    retcode = call(*popenargs, **kwargs)
  File "C:\Python26\lib\subprocess.py", line 470, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python26\lib\subprocess.py", line 621, in __init__
    errread, errwrite)
  File "C:\Python26\lib\subprocess.py", line 830, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

The workaround is to specify the full name "foo.bar.exe".

----------
components: Library (Lib), Windows
messages: 101646
nosy: srid
severity: normal
status: open
title: subprocess.Popen raises WindowsError if there is a dot in program name
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Wed Mar 24 19:27:01 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Mar 2010 18:27:01 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269455221.23.0.604528721586.issue8224@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Note that typing "foo.bar" in the Windows command line works, only subprocess is not able to find the executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Wed Mar 24 19:29:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Mar 2010 18:29:43 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269455383.9.0.579969365009.issue8224@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Wed Mar 24 20:05:03 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 24 Mar 2010 19:05:03 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269457503.62.0.556427763133.issue8222@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

By reading the doc it is not clear if we should activate this option only when dealing with blocking sockets.
What's the behavior with non blocking ones?
Does it result in a no-op or does it hang the applcation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Wed Mar 24 20:08:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 19:08:29 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269457709.15.0.900071325148.issue8222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

To me it looks clearly like a no-op ("Never bother the application with retries *if the transport is blocking*").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Wed Mar 24 20:08:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 19:08:43 +0000
Subject: [issue8213] Python 3 ignored PYTHONUNBUFFERED and -u
In-Reply-To: <1269449113.38.0.204948612023.issue8213@psf.upfronthosting.co.za>
Message-ID: <201003242008.35432.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Use :

...     print(i, end=' ')
...     sys.stdout.flush()
...     time.sleep(1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8213>
_______________________________________

From report at bugs.python.org  Wed Mar 24 20:11:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 24 Mar 2010 19:11:11 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269457871.32.0.746435205947.issue8222@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Mmm you're right. Sorry.
I'm clearly too tired. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Wed Mar 24 21:08:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Mar 2010 20:08:12 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269461292.54.0.0794059248344.issue8224@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that it works with shell=True.  Which is what you would expect if it works in the shell.  Without shell=True, the program name is being passed to CreateProcess directly. Popen("foo") results in the same cannot find file error for me if the file is foo.bat.  Perhaps CreateFile has special rules for .exe, and they are broken as you describe?

In any case, it looks to me like if there is a bug here it is in Windows.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Wed Mar 24 21:37:21 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Mar 2010 20:37:21 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1269463041.45.0.196157344455.issue7753@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Mar 24 21:42:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Mar 2010 20:42:38 +0000
Subject: [issue8221] 2to3 mishandles StringIO inside a package with an io.py
	module
In-Reply-To: <1269443180.02.0.978577516398.issue8221@psf.upfronthosting.co.za>
Message-ID: <1269463358.05.0.474809938164.issue8221@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This should be fixed in the latest versions of 2to3.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8221>
_______________________________________

From report at bugs.python.org  Wed Mar 24 21:43:04 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Mar 2010 20:43:04 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269463384.16.0.33082622867.issue7946@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Mar 24 23:09:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 22:09:28 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269468568.56.0.632230824338.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Giampaolo, I tried committing your patch but the buildbot still fails, with the following errors:

test_auth_issued_twice (test.test_ftplib.TestTLS_FTPClass) ... ok
test_auth_ssl (test.test_ftplib.TestTLS_FTPClass) ... ok
test_control_connection (test.test_ftplib.TestTLS_FTPClass) ... ok
test_data_connection (test.test_ftplib.TestTLS_FTPClass) ... Exception in thread Thread-462:
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 223, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asyncore.py", line 211, in loop
    poll_fun(timeout, map)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asyncore.py", line 154, in poll
    write(obj)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asyncore.py", line 88, in write
    obj.handle_error()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asyncore.py", line 84, in write
    obj.handle_write_event()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 290, in handle_write_event
    super(SSLConnection, self).handle_write_event()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asyncore.py", line 440, in handle_write_event
    self.handle_write()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asynchat.py", line 174, in handle_write
    self.initiate_send()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/asynchat.py", line 215, in initiate_send
    self.handle_close()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 43, in handle_close
    self.close()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 323, in close
    self.socket.unwrap()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ssl.py", line 258, in unwrap
    s = self._sslobj.shutdown()
error: [Errno 32] Broken pipe

ERROR
test_login (test.test_ftplib.TestTLS_FTPClass) ... ok

======================================================================
ERROR: test_nlst (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 515, in test_nlst
    self.assertEqual(self.client.nlst(), NLST_DATA.split('\r\n')[:-1])
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 495, in nlst
    self.retrlines(cmd, files.append)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 695, in retrlines
    conn = self.transfercmd(cmd)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 357, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 670, in ntransfercmd
    conn, size = FTP.ntransfercmd(self, cmd, rest)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 324, in ntransfercmd
    host, port = self.makepasv()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 302, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 786, in parse227
    raise error_reply, resp
error_reply: 226 transfer complete

======================================================================
ERROR: test_retrbinary_rest (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 475, in test_retrbinary_rest
    self.client.retrbinary('retr', received.append, rest=rest)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 678, in retrbinary
    conn = self.transfercmd(cmd, rest)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 357, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 670, in ntransfercmd
    conn, size = FTP.ntransfercmd(self, cmd, rest)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 324, in ntransfercmd
    host, port = self.makepasv()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 302, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 786, in parse227
    raise error_reply, resp
error_reply: 200 type ok

======================================================================
ERROR: test_storbinary (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 488, in test_storbinary
    self.client.storbinary('stor', f)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 727, in storbinary
    conn.unwrap()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ssl.py", line 258, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1367: The operation did not complete (read)

======================================================================
ERROR: test_storbinary_rest (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 500, in test_storbinary_rest
    self.client.storbinary('stor', f, rest=r)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 727, in storbinary
    conn.unwrap()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ssl.py", line 258, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1367: The operation did not complete (read)

======================================================================
ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 505, in test_storlines
    self.client.storlines('stor', f)
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 746, in storlines
    conn.unwrap()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ssl.py", line 258, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1367: The operation did not complete (read)

======================================================================
ERROR: test_data_connection (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_ftplib.py", line 619, in test_data_connection
    self.client.prot_c()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 663, in prot_c
    resp = self.voidcmd('PROT C')
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 249, in voidcmd
    return self.voidresp()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 224, in voidresp
    resp = self.getresp()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 210, in getresp
    resp = self.getmultiline()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 196, in getmultiline
    line = self.getline()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/ftplib.py", line 183, in getline
    line = self.file.readline()
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/socket.py", line 445, in readline
    data = self._sock.recv(self._rbufsize)
timeout: timed out

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 24 23:16:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 22:16:13 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269468973.91.0.628737689522.issue8108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: test needed -> needs patch
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Wed Mar 24 23:51:04 2010
From: report at bugs.python.org (news1234)
Date: Wed, 24 Mar 2010 22:51:04 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1269471064.86.0.889783940847.issue1553375@psf.upfronthosting.co.za>


Changes by news1234 <news1234 at free.fr>:


----------
nosy: +news1234

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:01:58 2010
From: report at bugs.python.org (Mangus Wahberg)
Date: Wed, 24 Mar 2010 23:01:58 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>


New submission from Mangus Wahberg <endast at gmail.com>:

When using the interactive python help and entering xml.etree the help page contains a link faulty link to the online documentation.

The link in the help page is:

 MODULE DOCS
    http://docs.python.org/library/xml.etree

But the correct link is:
http://docs.python.org/library/xml.etree.elementtree

----------
assignee: georg.brandl
components: Documentation
messages: 101655
nosy: georg.brandl, mangus.wahberg
severity: normal
status: open
title: Wrong link in xml.etree documentation
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:02:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Mar 2010 23:02:51 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1269471771.88.0.714914271354.issue8225@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:04:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Mar 2010 23:04:07 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1269471847.26.0.40188624652.issue8203@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:05:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 23:05:54 +0000
Subject: [issue8226] sys.setfilesystemencoding("xxx");
	open("a") => stack overflow
In-Reply-To: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>
Message-ID: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

sys.setfilesystemencoding() doesn't check if the argument is a valid encoding name.

If the filesystem encoding is invalid, open("a") goes into an unlimited loop. The default recursion limit is 1000, but the example crash at 930: too bad :-) Each loop allocate ~9000 bytes: Linux creates a 8 MB stack by default, and so ~9000x930 uses all the stack.

Using a lower recursion limit, we can see the loop:
----------
$ ./python -c 'import sys; sys.setrecursionlimit(30); sys.setfilesystemencoding("xxx"); open("x")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 83, in search_function
    norm_encoding = normalize_encoding(encoding)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 55, in normalize_encoding
    if isinstance(encoding, bytes):
RuntimeError: maximum recursion depth exceeded while calling a Python object
----------

----------
components: Interpreter Core
messages: 101656
nosy: haypo
severity: normal
status: open
title: sys.setfilesystemencoding("xxx"); open("a") => stack overflow
type: crash
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8226>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:08:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 23:08:09 +0000
Subject: [issue8226] sys.setfilesystemencoding("xxx");
	open("a") => stack overflow
In-Reply-To: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>
Message-ID: <1269472089.2.0.0899610598943.issue8226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch raises a LookupError is the specified encoding is invalid. It uses _PyCodec_Lookup() function: is it allowed in bltinmodule.c?

----------
keywords: +patch
Added file: http://bugs.python.org/file16635/setfilesystemencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8226>
_______________________________________

From report at bugs.python.org  Thu Mar 25 00:47:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Mar 2010 23:47:23 +0000
Subject: [issue8226] sys.setfilesystemencoding("xxx");
	open("a") => stack overflow
In-Reply-To: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>
Message-ID: <1269474443.26.0.946091199412.issue8226@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(duplicate of Issue8076)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8226>
_______________________________________

From report at bugs.python.org  Thu Mar 25 01:09:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 00:09:18 +0000
Subject: [issue8227] Fix C API documentation: Argument parsing
In-Reply-To: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>
Message-ID: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Patch fixing Doc/c-api/arg.rst:
 * 'z', 'z#', 'z*' does also accept Unicode
 * unify types name: replace "string or Unicode objet" by "string or Unicode" (it's shorter ;-))

See also #8215 and #2322.

----------
assignee: georg.brandl
components: Documentation
files: c-api_arg.patch
keywords: patch
messages: 101659
nosy: georg.brandl, haypo
severity: normal
status: open
title: Fix C API documentation: Argument parsing
versions: Python 2.7
Added file: http://bugs.python.org/file16636/c-api_arg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8227>
_______________________________________

From report at bugs.python.org  Thu Mar 25 01:26:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 00:26:32 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269476792.6.0.0307394473374.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MaL> It unconditionally overrides CFLAGS - even if it is not 
MaL> set and defined by AC_PROG_CC as "-g -O2". That would need 
MaL> to be corrected.
MaL>
MaL> Other than that it does help a little work around the mess :-)

I commited my patch: r79392 (trunk). I'm waiting for the buildbots before porting to other branches :-)

On my Linux, .c files are now compiled with:
 - "-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall ..." (default)
 - "-fno-strict-aliasing -g -Wall ..." (--with-pydebug): no more compiler optimization hurting gdb ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 01:28:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 00:28:46 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269476926.71.0.777361424578.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

This patch solves the problem with 0.9.8m on my Debian workstation.

Actually there's 4 kind of errors on shutdown():
 - SSL_ERROR_WANT_READ
 - SSL_ERROR_WANT_WRITE
 - socket.error: errno.PIPE (32)
 - socket.error: 0

Since the command is "shutdown()", the patch silence all the socket errors, because they are probably due to the remote side closing the connection abruptly.
See the details on the Darryl's analysis:
http://bugs.python.org/issue8108#msg100980

This patch is very closed to Darryl's proposal.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16637/issue8108_openssl_098m.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 01:36:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 00:36:35 +0000
Subject: [issue8226] sys.setfilesystemencoding("xxx");
	open("a") => stack overflow
In-Reply-To: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>
Message-ID: <1269477395.71.0.574889722288.issue8226@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r79393 (py3k), r79394 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8226>
_______________________________________

From report at bugs.python.org  Thu Mar 25 01:37:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 00:37:24 +0000
Subject: [issue8076] sys.setfilesystemencoding('foo') causes segmentation fault
In-Reply-To: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>
Message-ID: <1269477444.51.0.103245191187.issue8076@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #8226 (ok, it should be the opposite, but #8226 had a patch ;-)).

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8076>
_______________________________________

From report at bugs.python.org  Thu Mar 25 02:06:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 01:06:21 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269479181.36.0.161490506952.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I commited my patch: r79392 (trunk). I'm waiting for the buildbots before porting to other branches :-)

The buildbots look happy => r79401 (py3k), blocked in 2.6 and 3.1

The issue title was "configure: ignore AC_PROG_CC hardcoded CFLAGS", and not "fix configure", so I can close the issue.

Marc-Andre: open a new issue if you are motivated to fix "configure mess" :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 02:45:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 01:45:57 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1269481557.61.0.0752419968218.issue8203@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you try this patch? The encoding argument was just ignored...

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16638/idlelib_textView_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Thu Mar 25 02:48:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 01:48:56 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269481736.43.0.329971381563.issue8224@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue might be documentation is subprocess documentation.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Thu Mar 25 02:49:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 01:49:32 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269481772.22.0.248391954594.issue8224@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops. I wanted to write: "This issue might be documented in subprocess documentation" :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Thu Mar 25 02:58:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 01:58:27 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269482307.6.0.818538355062.issue8214@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

syslog_exception() should be declared outside logexceptions(), so it's possible to call it directly. Example:

try:
  ...
except Exception:
  syslog_exception(*sys.exc_info())

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 03:06:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Mar 2010 02:06:08 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269482768.42.0.961695435312.issue8224@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In order to do that someone will need to confirm that this affects all versions of windows, and whether or not it is a bug in windows or the expected behavior of CreateProcess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Thu Mar 25 03:11:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 02:11:28 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269483088.2.0.485775659803.issue6543@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> in compile.c, the c_filename member has utf8 encoding

The problem is maybe that c_filename should be an unicode object created using the file system default encoding and the surrogateescape error handler, to be able to store undecodable filenames (useful on POSIX OS using a byte string API, eg. Linux).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:14:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 03:14:44 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1269486884.26.0.627889672612.issue8225@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I believe the problem is with pydoc. In the case of xml.etree, I don't think it should be displaying anything for MODULE DOCS.

help(xml.etree.ElementTree) does display the proper link.

The attached patch and test fixes the problem.

----------
assignee: georg.brandl -> brian.curtin
components: +Library (Lib) -Documentation
keywords: +patch
nosy: +brian.curtin
stage:  -> patch review
type:  -> performance
Added file: http://bugs.python.org/file16639/issue8225.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Thu Mar 25 04:15:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 03:15:04 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1269486904.29.0.779923646135.issue8225@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Thu Mar 25 07:16:00 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Thu, 25 Mar 2010 06:16:00 +0000
Subject: [issue8228] pprint, single/multiple items per line parameter
In-Reply-To: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>
Message-ID: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>


New submission from Dmitry Chichkov <dchichkov at gmail.com>:

I've run into a case where pprint isn't really pretty. 

import pprint
pprint.PrettyPrinter().pprint([1]*100)

Prints a lengthy column of '1'; Not pretty at all. Look:

[1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1]

----------
components: Library (Lib)
messages: 101672
nosy: Dmitry.Chichkov
severity: normal
status: open
title: pprint, single/multiple items per line parameter
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8228>
_______________________________________

From report at bugs.python.org  Thu Mar 25 08:42:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Mar 2010 07:42:27 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269476792.6.0.0307394473374.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BAB13DE.9090302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> MaL> It unconditionally overrides CFLAGS - even if it is not 
> MaL> set and defined by AC_PROG_CC as "-g -O2". That would need 
> MaL> to be corrected.
> MaL>
> MaL> Other than that it does help a little work around the mess :-)
> 
> I commited my patch: r79392 (trunk). I'm waiting for the buildbots before porting to other branches :-)
> 
> On my Linux, .c files are now compiled with:
>  - "-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall ..." (default)
>  - "-fno-strict-aliasing -g -Wall ..." (--with-pydebug): no more compiler optimization hurting gdb ;-)

The patch you checked in still unconditionally overrides the
CFLAGS setting applied by AC_PROG_CC in case no CFLAGS variable
is set.

Please fix that or revert the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 08:44:01 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Mar 2010 07:44:01 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269479181.36.0.161490506952.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BAB143D.8080502@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I commited my patch: r79392 (trunk). I'm waiting for the buildbots before porting to other branches :-)
> 
> The buildbots look happy => r79401 (py3k), blocked in 2.6 and 3.1
> 
> The issue title was "configure: ignore AC_PROG_CC hardcoded CFLAGS", and not "fix configure", so I can close the issue.

The issue now is: AC_PROG_CC no longer initializes CFLAGS if not set.

> Marc-Andre: open a new issue if you are motivated to fix "configure mess" :-)

Some other day...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 08:55:52 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Thu, 25 Mar 2010 07:55:52 +0000
Subject: [issue8228] pprint, single/multiple items per line parameter
In-Reply-To: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>
Message-ID: <1269503752.58.0.156725060448.issue8228@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

Quick, dirty and utterly incorrect patch that works for me. Includes issue_5131.patch (defaultdict support, etc). Targets trunk (2.6), revision 77310.

----------
keywords: +patch
Added file: http://bugs.python.org/file16640/issue_8228.dirty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8228>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:17:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Mar 2010 08:17:03 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269505023.83.0.733779186851.issue6543@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Storing unicode in c_filename would not solve the problem: "surrogateescape" characters are not printable.
There is no need to support non-decodable filenames in the import mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:31:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 25 Mar 2010 08:31:41 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269505901.8.0.760620990186.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

@Antoine Pitrou: ok, I think I'll have to be able to replicate the error in order to try to fix this. I'm gonna try on FreeBSD and another Linux box later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:32:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 08:32:50 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269505970.38.0.957182757772.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I don't know if it is better to fix it in the ftplib or the ssl module.

The previous patch fixes it at the SSL level (stdlib only).
This patch implements the fix at the ftplib level (stdlib + test).

----------
Added file: http://bugs.python.org/file16641/issue8108_ftplib_ssl_098m.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:50:58 2010
From: report at bugs.python.org (tb220)
Date: Thu, 25 Mar 2010 08:50:58 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>


New submission from tb220 <tb220 at yahoo.com>:

Attached the error report generated by Windows. The problem occurs in 1 out of 10 shutdowns.

----------
components: Interpreter Core, Windows
files: cabb_appcompat.txt
messages: 101679
nosy: tb220
severity: normal
status: open
title: Interpreter crash on application shutdown
versions: Python 2.6
Added file: http://bugs.python.org/file16642/cabb_appcompat.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 09:52:57 2010
From: report at bugs.python.org (tb220)
Date: Thu, 25 Mar 2010 08:52:57 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269507177.76.0.793489306587.issue8229@psf.upfronthosting.co.za>


Changes by tb220 <tb220 at yahoo.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:14:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 09:14:36 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269508476.61.0.76435997971.issue8211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MaL> The patch you checked in still unconditionally overrides the
MaL> CFLAGS setting applied by AC_PROG_CC in case no CFLAGS variable
MaL> is set.
MaL>
MaL> The issue now is: AC_PROG_CC no longer initializes CFLAGS 
MaL> if not set.

Sorry, but I don't understand. Why should it be initialized?

I don't like the default value because it enables optimization when --with-pydebug is used and I consider that as a bug. If no configure option is used, Python adds -O3 as before. About -g: Python always add it, so the -g from AC_PROG_CC was redundant.

In Makefile.pre.in, prefixes and suffixes are added to the CFLAGS: "CFLAGS= $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)". But I consider this as a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:17:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 09:17:50 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269508670.22.0.45613551561.issue8214@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Good point. So that makes the implementation more like:

import traceback
import syslog
import sys

def syslog_exception(etype, evalue, etb):
    # The result of traceback.format_exception might contain
    # embedded newlines, so we have the nested loops.
    for line in traceback.format_exception(etype, evalue, etb):
        for line in line.rstrip().split('\n'):
            syslog.syslog(line)

def logexceptions(chain=True):
    # Should we chain to the existing sys.excepthook?
    current_hook = sys.excepthook if chain else None

    def hook(etype, evalue, etb):
        if current_hook:
            current_hook(etype, evalue, etb)
        syslog_exception(etype, evalue, etb)
    sys.excepthook = hook

We could then make syslog_exception take a tuple instead of the 3 values. I'm not sure which is more convenient, or more widely used in other APIs.

Once it's moved into syslog, maybe syslog_exception named syslog.log_exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:26:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 09:26:16 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269509176.95.0.417998038144.issue8214@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Once it's moved into syslog, maybe syslog_exception named syslog.log_exception.

In that case, how would be called the second function? Can write a patch with an unit test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:30:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 09:30:27 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269509427.37.0.625361481323.issue8214@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

>> Once it's moved into syslog, maybe syslog_exception named syslog.log_exception.

That's "should be named", of course. Although on second thought maybe syslog.syslog_exception really is the right name, to mirror syslog.syslog.

> In that case, how would be called the second function? Can write a patch with an unit test?

I'm not sure which second function you mean.

As far as the implementation, Sean's working on it, although I'm willing to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:35:05 2010
From: report at bugs.python.org (tb220)
Date: Thu, 25 Mar 2010 09:35:05 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269509705.4.0.212481725928.issue8229@psf.upfronthosting.co.za>


tb220 <tb220 at yahoo.com> added the comment:

Please let me know how I can provide you with additional information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:35:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 09:35:36 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269509736.78.0.475621891545.issue8214@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure which second function you mean.

"logexceptions" which replaces sys.excepthook. "log_exception" and "log_exceptions" are very close.

cgitb has a function "enable" which sets sys.excepthook.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:41:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 09:41:39 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269510099.34.0.462462024233.issue8214@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Ah, I see. Yes, logexceptions needs a better name. Maybe enable_exception_logging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 10:56:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 09:56:09 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269510969.14.0.490821612334.issue8214@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's a version that would be more analogous to what the C implementation would look like. It uses a class instead of a closure to capture the "chain" value. The 2 exposed functions syslog_exception and enable_exception_logging are the new APIs in this proposal, which would be written in C as part of the syslog module. The class is a hidden implementation detail.

########################
import traceback
import syslog
import sys

def syslog_exception(etype, evalue, etb):
    # The result of traceback.format_exception might contain
    # embedded newlines, so we have the nested loops.
    for line in traceback.format_exception(etype, evalue, etb):
        for line in line.rstrip().split('\n'):
            syslog.syslog(line)

class _Hook(object):
    def __init__(self, chain):
        # Should we chain to the existing sys.excepthook?
        self._current_hook = sys.excepthook if chain else None

    def _hook(self, etype, evalue, etb):
        if self._current_hook:
            self._current_hook(etype, evalue, etb)
        syslog_exception(etype, evalue, etb)

def enable_exception_logging(chain=True):
    sys.excepthook = _Hook(chain)._hook

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:08:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 10:08:30 +0000
Subject: [issue8224] subprocess.Popen raises WindowsError if there is a dot in
	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269511710.35.0.488094332084.issue8224@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with David that this is a Windows problem. I copied xcopy.exe into a local directory as xcopy.exe and xcopy.a.exe. When running this VBScript, the first line runs, the second gives me an error 0x8007002, "The system could not find the file specified".

WScript.CreateObject("WScript.Shell").Run "xcopy", 1, true
WScript.CreateObject("WScript.Shell").Run "xcopy.a", 1, true

I only tested on XP.

----------
nosy: +eric.smith
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8224>
_______________________________________

From report at bugs.python.org  Thu Mar 25 11:31:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Mar 2010 10:31:32 +0000
Subject: [issue8211] configure: ignore AC_PROG_CC hardcoded CFLAGS
In-Reply-To: <1269508476.61.0.76435997971.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BAB3B80.9020400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> MaL> The patch you checked in still unconditionally overrides the
> MaL> CFLAGS setting applied by AC_PROG_CC in case no CFLAGS variable
> MaL> is set.
> MaL>
> MaL> The issue now is: AC_PROG_CC no longer initializes CFLAGS 
> MaL> if not set.
> 
> Sorry, but I don't understand. Why should it be initialized?

Sorry, perhaps I wasn't clear enough.

The purpose of AC_PROG_CC is to setup the env vars depending on
the found C compiler. One of these settings is the CFLAGS env
var and you patch causes those settings to be overwritten
if CFLAGS has not been defined as env var before starting
./configure.

Since CFLAGS will most of the time not be set by the user
running ./configure, the patch effectively disables the
default settings determined based on the compiler by AC_PROG_CC.

> I don't like the default value because it enables optimization when --with-pydebug is used and I consider that as a bug. If no configure option is used, Python adds -O3 as before. About -g: Python always add it, so the -g from AC_PROG_CC was redundant.

Right, but it's possible that AC_PROG_CC adds other flags
as well (it currently doesn't, but that may well change in
future versions of autoconf).

I'd suggest to only override the CFLAGS setting in case it
was defined before running the AC_PROG_CC code.

In addition, it may be useful to have --with-pydebug replace OPT
with "-O0" or add "-O0" to it the end of it.

> In Makefile.pre.in, prefixes and suffixes are added to the CFLAGS: "CFLAGS= $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)". But I consider this as a separate issue.

Right. That's for historic reasons. OPT is very old, BASECFLAGS
and EXTRA_CFLAGS are newer additions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8211>
_______________________________________

From report at bugs.python.org  Thu Mar 25 12:32:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Mar 2010 11:32:43 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269516763.31.0.813838365716.issue8229@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A recipe for reproducing the problem would be the most useful thing.  I suspect the windows error report is pretty much useless in this context.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 13:25:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 12:25:41 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269519941.41.0.265086857164.issue7992@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

All windows buildbots fail to compile:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%20trunk
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%20trunk
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%20trunk

----------
keywords: +buildbot
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:00:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Mar 2010 13:00:20 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1269522020.6.0.3927200936.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It occurs to me that Raymond's use case could be satisfied using existing Python, by slightly changing the format string. After all, str.format() supports mapping lookup already:

$ ./python.exe
Python 2.6.5+ (release26-maint:79421, Mar 25 2010, 08:51:39)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Default(dict):
...  def __missing__(self, key):
...   return key
...
>>> s = '{m[name]} was born in {m[country]}'
>>> s.format(m=Default(name='Guido'))
'Guido was born in country'
>>>

Considering that, maybe the best thing is to do nothing. Or maybe update the documentation with this example.

Plus, you could mix and match this with *args as you'd like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6081>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:04:28 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Thu, 25 Mar 2010 13:04:28 +0000
Subject: [issue8230] Lib/test/sortperf.py fails to run
In-Reply-To: <1269522267.95.0.58025957624.issue8230@psf.upfronthosting.co.za>
Message-ID: <1269522267.95.0.58025957624.issue8230@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

There is a test file Lib/test/sortperf.py, which isn't properly updated
to python3, because it considers map and range returning a list instead of an iterator and therefore throwing an exception when run. I have attached a patch to fix it.

----------
components: Tests
files: sortperf.diff
keywords: patch
messages: 101693
nosy: pyfex
severity: normal
status: open
title: Lib/test/sortperf.py fails to run
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16643/sortperf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8230>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:30:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 13:30:14 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269523814.66.0.306073628679.issue8108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Florent, you shouldn't need to silence socket.error at this level.

I think what needs to happen is that, when unwrap() fails in SSLConnection.close(), handle_read() and handle_write() retry the unwrap() call. That's what I gather from the explanation of the new behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:31:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 13:31:28 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269523888.33.0.972678559031.issue7992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Marc-Andr? pointed out, you shouldn't have converted old uses of PyCObject. It breaks compatibility, and I don't think there's any point since 2.7 will probably be the last in the 2.x line.

----------
nosy: +lemburg, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:37:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 13:37:17 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269524237.37.0.234576519059.issue7992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(if you want to be perfectionist, you can have those modules provide both a PyCObject and a PyCapsule interface...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:52:07 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 13:52:07 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269525127.79.0.860393046214.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I upload an updated bfs.patch. Apply to updated py32 and ignore the error with:

$ patch -fp1 < bfs.patch
$ ./configure


> Please give understandable benchmark numbers, including an explicit comparison with baseline 3.2, and patched 3.2 (e.g. gilinter.patch)

Below.

> Please also measure single-thread performance, because it looks like you are adding significant work inside the core eval loop

Removed most of it now. last bit will be removed soon.

> Do you need a hi-res clock? gettimeofday() already gives you microseconds. It looks like a bit of imprecision shouldn't be detrimental.

I use clock_gettime() to get the thread running time to calculate slice depletion. Wall clock can not help with that.

> The magic number DEADLINE_FACTOR looks gratuitous (why 1.1^20 ?) 

To my understanding it controls the CPU load (~6) beyond which threads tend to expire. Since expired threads are handled in FIFO order, IO threads do not preempt them (IO threads are chronically expired). So beyond that load IO threads become less responsive.

> By the way, I would put COND_SIGNAL inside the LOCK_MUTEX / UNLOCK_MUTEX pair in bfs_yield().

Done.

Here are benchmark results of the UDP test as timed with ipython, where client.work() is a single run of the client:

System: Core 2 Duo (locked at 2.4 GHz) with Ubuntu Karmic 64 bit.

Vanilla Python 3.2: 

* Note on my system the original problem discussed in this issue report does not manifest since conditions wake up threads according to OS scheduling policy.

In [28]: %timeit -n3 client.work()
1.290 seconds (8127084.435 bytes/sec)
1.488 seconds (7045285.926 bytes/sec)
2.449 seconds (4281485.217 bytes/sec)
1.874 seconds (5594303.222 bytes/sec)
1.853 seconds (5659626.496 bytes/sec)
0.872 seconds (12023425.779 bytes/sec)
4.951 seconds (2117942.079 bytes/sec)
0.728 seconds (14409157.126 bytes/sec)
1.743 seconds (6016999.707 bytes/sec)
3 loops, best of 3: 1.53 s per loop

gilinter.patch:

In [31]: %timeit -n3 client.work()
5.192 seconds (2019676.396 bytes/sec)
1.613 seconds (6500071.475 bytes/sec)
3.057 seconds (3429689.199 bytes/sec)
3.486 seconds (3007596.468 bytes/sec)
4.324 seconds (2424791.868 bytes/sec)
0.964 seconds (10872708.606 bytes/sec)
3.510 seconds (2987722.960 bytes/sec)
1.362 seconds (7698999.458 bytes/sec)
1.013 seconds (10353913.920 bytes/sec)
3 loops, best of 3: 1.96 s per loop

PyCON patch:

In [32]: %timeit -n3 client.work()
2.483 seconds (4223256.889 bytes/sec)
1.330 seconds (7882880.263 bytes/sec)
1.737 seconds (6036251.315 bytes/sec)
1.348 seconds (7778296.679 bytes/sec)
0.983 seconds (10670811.638 bytes/sec)
1.419 seconds (7387226.333 bytes/sec)
1.057 seconds (9919412.977 bytes/sec)
2.483 seconds (4223205.791 bytes/sec)
2.121 seconds (4944231.292 bytes/sec)
3 loops, best of 3: 1.25 s per loop

bfs.patch:

In [33]: %timeit -n3 client.work()
0.289 seconds (36341875.356 bytes/sec)
0.271 seconds (38677439.991 bytes/sec)
0.476 seconds (22033958.947 bytes/sec)
0.329 seconds (31872974.070 bytes/sec)
0.478 seconds (21925125.894 bytes/sec)
0.242 seconds (43386204.271 bytes/sec)
0.213 seconds (49195701.418 bytes/sec)
0.309 seconds (33967467.196 bytes/sec)
0.256 seconds (41008076.688 bytes/sec)
3 loops, best of 3: 259 ms per loop


Output of cpued.py test:

Vanilla Python 3.2, gilinter.patch and PyCON patch all starve the pure Python threads and output the following:

$ ~/build/python/python32/python cpued.py 
t0 0 False
t1 0 False
t2-interactive 0 True
t2-interactive 1 True
t2-interactive 2 True
t2-interactive 3 True
t2-interactive 4 True
t2-interactive 5 True
t2-interactive 6 True
t2-interactive 7 True
.
.
.


Output from bfs.patch run:

$ ~/build/python/bfs/python cpued.py 
t0 0 False
t1 0 False
t2-interactive 0 True
t0 1 False
t1 1 False
t2-interactive 1 True
t0 2 False
t1 2 False
t2-interactive 2 True
t0 3 False
t1 3 False
t2-interactive 3 True
.
.
.

Note: I have not tested on other Posix systems, and expect to have some complications on Windows, since its thread timers are low resolution (10ms+), and there are issues with its high-precision wall clock. ...will soon know better.

----------
Added file: http://bugs.python.org/file16644/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:54:52 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 13:54:52 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269525292.62.0.381091092986.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16634/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:55:11 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 13:55:11 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269525311.42.0.16285152411.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16567/linux-7946.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 14:56:29 2010
From: report at bugs.python.org (David Fraser)
Date: Thu, 25 Mar 2010 13:56:29 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1269525389.3.0.0271999801243.issue8032@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


----------
nosy: +davidfraser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:00:59 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 25 Mar 2010 14:00:59 +0000
Subject: [issue5872] New C API for declaring Python types
In-Reply-To: <1240973984.42.0.154845882855.issue5872@psf.upfronthosting.co.za>
Message-ID: <1269525659.52.0.0431888294589.issue5872@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5872>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:09:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 14:09:57 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269526197.63.0.416437783161.issue7992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyCapsule comes from issues #5630 and #5872.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:11:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 14:11:59 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269526319.78.0.0670482727337.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

You're right, there's no need to catch the socket error in "ftplib" module.

Here is the result of the "debugging" patch in the console:

$ ./python -m test.regrtest -uall test_ftplib
test_ftplib
success
success
success
success
success
success
success
success
2702 ssl want read
2801 ssl want read
2661 ssl want read
2274 ssl want read
16742 ssl want read
2397 ssl want read
1 test OK.



IMHO, there's no need to loop on "unwrap()", according to Darryl's analysis.

----------
Added file: http://bugs.python.org/file16645/issue8108_print_ssl_want_read.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:21:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 14:21:52 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269526912.6.0.87485298842.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I use clock_gettime() to get the thread running time to calculate slice depletion.

Ouch. CLOCK_THREAD_CPUTIME_ID is not a required part of the standard. Only CLOCK_REALTIME is guaranteed to exist.

By the way, it's not obvious cpued tests anything meaningful. I understand the bias you are trying to avoid but constructing artificial test cases is not very useful, because we are playing with heuristics and it's always possible to defeat some expectations. That's why benchmarks should try to model/represent real-world situations.


I've tried ccbench with your patch and there's a clear regression in latency numbers:

Background CPU task: Pi calculation (Python)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 1 ms. (std dev: 0 ms.)
CPU threads=2: 0 ms. (std dev: 2 ms.)
CPU threads=3: 0 ms. (std dev: 2 ms.)
CPU threads=4: 2 ms. (std dev: 8 ms.)

Background CPU task: regular expression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 969 ms. (std dev: 577 ms.)
CPU threads=2: 1050 ms. (std dev: 577 ms.)
CPU threads=3: 1217 ms. (std dev: 577 ms.)
CPU threads=4: 1416 ms. (std dev: 577 ms.)

Vanilla py3k and py3k+gilinter both don't have this problem (on the regular expression workload).

IO bandwidth numbers are similar between the BFS patch:

Background CPU task: Pi calculation (Python)

CPU threads=0: 6952.7 packets/s.
CPU threads=1: 4350.3 ( 62 %)
CPU threads=2: 3332.2 ( 47 %)
CPU threads=3: 2632.0 ( 37 %)
CPU threads=4: 2052.0 ( 29 %)

and py3k + gilinter:

Background CPU task: Pi calculation (Python)

CPU threads=0: 7023.4 packets/s.
CPU threads=1: 5019.4 ( 71 %)
CPU threads=2: 4474.6 ( 63 %)
CPU threads=3: 2728.5 ( 38 %)
CPU threads=4: 2244.9 ( 31 %)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:37:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 14:37:32 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269527852.61.0.410618578149.issue8229@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Are you running a service? I can't say I'm too familiar with the file you uploaded, but the file contains a few things that lead me to believe you may be. As David said, it would be helpful to know what you were doing.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:40:05 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 14:40:05 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1269528005.17.0.873759918059.issue6231@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

It looks like this issue was missed in the recent ElementTree update.

Attached is an updated diff for py3k.

----------
nosy: +flox
Added file: http://bugs.python.org/file16646/ElementInclude_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6231>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:41:35 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 14:41:35 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1269528095.08.0.391136115738.issue6231@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Similiarly updated patch against current trunk

----------
Added file: http://bugs.python.org/file16647/ElementInclude.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6231>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:49:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 14:49:06 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269528546.29.0.16346427811.issue8108@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16641/issue8108_ftplib_ssl_098m.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:50:53 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 25 Mar 2010 14:50:53 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269528653.91.0.603524592019.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Florent can you give me a clue on how to make python use OpenSSL 0.9.8k on Ubuntu?
Despite I compiled and installed 0.9.8k from sources the system version keeps being 0.9.8g and I guess that Python is using that one.
Do I have to recompile Python by using a directive to tell what specific OpenSSL version to use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:53:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 14:53:00 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269528780.24.0.946736298976.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Patch ftplib/test_ftplib updated.
It is as before (0.9.8k): SSL_ERROR_WANT_READ is ignored on connection unwrap().

----------
Added file: http://bugs.python.org/file16648/issue8108_ftplib_ssl_098m_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 15:57:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 25 Mar 2010 14:57:13 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269529033.3.0.436842365795.issue8108@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Giampaolo, IMHO you need 0.9.8m to reproduce the issue.

I installed it from the Debian testing repo (I'm on debian).
~ $ apt-cache policy openssl
openssl:
  Installed?: 0.9.8m-2
  Candidate?: 0.9.8m-2
 Table de version?:
 *** 0.9.8m-2 0
        400 ftp://ftp.lip6.fr testing/main Packages
        300 ftp://ftp.lip6.fr sid/main Packages
        100 /var/lib/dpkg/status
     0.9.8g-15+lenny6 0
        900 ftp://ftp.lip6.fr lenny/main Packages
        900 http://security.debian.org lenny/updates/main Packages

Maybe you could catch it on "Lucid" repositories, and if you have some chance, it may be compatible with your ubuntu version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:32:39 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 15:32:39 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269531159.16.0.774435758434.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> Ouch. CLOCK_THREAD_CPUTIME_ID is not a required part of the standard. Only CLOCK_REALTIME is guaranteed to exist.

Right, however the man page at kernel.org says the following on CLOCK_THREAD_CPUTIME_ID: 
"Sufficiently recent versions of glibc and the Linux kernel support the following clocks"
http://www.kernel.org/doc/man-pages/online/pages/man2/clock_getres.2.html

The same statement shows up as early as 2003:
http://www.tin.org/bin/man.cgi?section=3&topic=clock_gettime

However, if this is indeed a problem on some systems (none Linux?), then a fall back could be attempted for them. 

There could also be a problem on systems where the counter exists but has low resolution 10ms+

What platforms do you think this could be a problem on?

> By the way, it's not obvious cpued tests anything meaningful. I understand the bias you are trying to avoid but constructing artificial test cases is not very useful, because we are playing with heuristics and it's always possible to defeat some expectations. That's why benchmarks should try to model/represent real-world situations.

I came up with cpued.py after reading the patches in an attempt to understand how they behave. In this case one thread is pure Python while the other occasionally releases the GIL, both CPU bound. I don't claim this is a real-world situation. However, it is a case in which bfs.patch behaves as expected.

> I've tried ccbench with your patch and there's a clear regression in latency numbers.

Please specify system and test details so I can try to look into it. On my system ccbench behaves as expected:

$ ~/build/python/bfs/python ccbench.py
== CPython 3.2a0.0 (py3k) ==
== x86_64 Linux on '' ==

--- Throughput ---

Pi calculation (Python)

threads=1: 1252 iterations/s.
threads=2: 1199 ( 95 %)
threads=3: 1178 ( 94 %)
threads=4: 1173 ( 93 %)

regular expression (C)

threads=1: 491 iterations/s.
threads=2: 478 ( 97 %)
threads=3: 472 ( 96 %)
threads=4: 477 ( 97 %)

SHA1 hashing (C)

threads=1: 2239 iterations/s.
threads=2: 3719 ( 166 %)
threads=3: 3772 ( 168 %)
threads=4: 3464 ( 154 %)

--- Latency ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 0 ms. (std dev: 1 ms.)
CPU threads=1: 0 ms. (std dev: 1 ms.)
CPU threads=2: 0 ms. (std dev: 1 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

Background CPU task: regular expression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 6 ms. (std dev: 0 ms.)
CPU threads=2: 2 ms. (std dev: 2 ms.)
CPU threads=3: 1 ms. (std dev: 0 ms.)
CPU threads=4: 5 ms. (std dev: 7 ms.)

Background CPU task: SHA1 hashing (C)

CPU threads=0: 0 ms. (std dev: 1 ms.)
CPU threads=1: 0 ms. (std dev: 1 ms.)
CPU threads=2: 0 ms. (std dev: 1 ms.)
CPU threads=3: 1 ms. (std dev: 1 ms.)
CPU threads=4: 1 ms. (std dev: 0 ms.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:39:29 2010
From: report at bugs.python.org (cane)
Date: Thu, 25 Mar 2010 15:39:29 +0000
Subject: [issue8231] Subprocess Startup Error - unable to create user config
	directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>


New submission from cane <bryan.hoffman at mnsu.edu>:

When trying to run Python 2.6.5 & 3.1 IDLE GUI on Windows 7, I receive the following error that the "IDLE's subprocess didnt make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection."

I've researched this error and tried following the steps to troubleshoot this error without any success.  I do not have any firewall software installed or have the Microsoft firewall enabled.  When following issue 8099 and tring to set the TCL and TK library to the idle.py I get the error that I need to check the path and permissions. (see attached screenshot)

These workstations are setup in active directory enviroment where each username that logs into the workstation is a local administrator and the referenced "M:\" drive is a home directory that is mapped for them.

When the local administrator account logs into the workstation the user can execute the IDLE GUI without any issues.

I found reference in one article that the os.py creates a directory called ".idlerc". 

I'm wondering if there is a way to hardcode a reference path that doesnt point to my "M:\" drive for this directory or is there something else that I can try to fix this issue?

Thanks,
Bryan

----------
components: Windows
files: error.png
messages: 101708
nosy: cane
severity: normal
status: open
title: Subprocess Startup Error - unable to create user config directory
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file16649/error.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:45:20 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 15:45:20 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269531920.46.0.856733228225.issue2768@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Poking this issue with updated patches.

Patch against py3k.

----------
Added file: http://bugs.python.org/file16650/posixmodule_comb_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:46:28 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 15:46:28 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269531988.7.0.840366724347.issue2768@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


Added file: http://bugs.python.org/file16651/posixmodule_comb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:51:58 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 25 Mar 2010 15:51:58 +0000
Subject: [issue6544] Fix refleak in kqueue implementation
In-Reply-To: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>
Message-ID: <1269532318.93.0.441424812045.issue6544@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

This issue seems to have been fixed in r78386 (trunk), r79223 (2.6) and r78958 (py3k). It should be still backported to 3.1.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6544>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:52:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 15:52:58 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1269531159.16.0.774435758434.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269532487.3360.19.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please specify system and test details so I can try to look into it.

It's a dual-core Linux x86-64 system. But, looking at the patch again,
the reason is obvious:

#define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate->tick_counter % 1000 == 0))

`tstate->tick_counter % 1000` is replicating the behaviour of the old
GIL, which based its speculative operation on the number of elapsed
opcodes (and which also gave bad latency numbers on the regex workload).

By the way, I configure --with-computed-gotos.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 16:54:02 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 15:54:02 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1269532442.38.0.147992521047.issue1491@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Poking the issue with an updated patch for trunk.

----------
Added file: http://bugs.python.org/file16652/BaseHTTPServer_continue_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:00:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 16:00:30 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269532830.07.0.457793799944.issue2768@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, I'm not sure it's a good idea. For example, calling os.ftruncate(fobj) on a py3k file object will bypass the object's internal buffering, ignoring any pending buffered data; the right thing to do is to call fobj.truncate() instead.

It may be better to simply mention in the docs that fileno() can be used on file-like objects to get a file descriptor, if needed.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:03:53 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 16:03:53 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269533033.73.0.657183118612.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> It's a dual-core Linux x86-64 system. But, looking at the patch again, the reason is obvious:
>
> #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate
> >tick_counter % 1000 == 0))
>
> `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, which based its speculative operation on the number of elapsed opcodes (and which also gave bad latency numbers on the regex workload).

The flag_check_depleted is there to work around this problem. It is raised by waiters which timeout.

What distribution and version of GNU/Linux are you using?

As for the CLOCK_THREAD_CPUTIME_ID clock, support was added to FreeBSD recently in version 7.1, which I guess is not good enough:
http://www.freebsd.org/releases/7.1R/relnotes.html

I did not find yet anything on Solaris. Do you know of an alternative way to measure thread running time on Posix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:08:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 16:08:13 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1269533033.73.0.657183118612.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269533401.3360.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What distribution and version of GNU/Linux are you using?

$ cat /etc/mandriva-release 
Mandriva Linux release 2010.0 (Official) for x86_64

$ rpm -qv glibc
glibc-2.10.1-6.2mnb2

$ uname -a
Linux localhost 2.6.31.5-desktop-1mnb #1 SMP Fri Oct 23 00:05:22 EDT
2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ GNU/Linux

I'll try on an Ubuntu system some other day, if I find the time.

> I did not find yet anything on Solaris. Do you know of an alternative
> way to measure thread running time on Posix?

No, but I'm not an expert.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:13:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 16:13:27 +0000
Subject: [issue8231] Unable to run IDLE without write-access to config
	directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1269533607.81.0.153143108749.issue8231@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just reproduced this by removing write access from my user for my home directory.

It seems odd that you wouldn't have write access to your home directory in the first place, but that's tangent to the issue. I'll see if there are other acceptable locations to attempt to place the config directory.

----------
components: +Library (Lib)
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch
title: Subprocess Startup Error - unable to create user config directory -> Unable to run IDLE without write-access to config directory
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:22:29 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 16:22:29 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1269534149.21.0.243152189582.issue1491@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

And a py3k version (although the conversion can be improved).

----------
Added file: http://bugs.python.org/file16653/BaseHTTPServer_continue_3_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:23:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 16:23:40 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1269534220.51.0.177334587455.issue1491@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:23:59 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 16:23:59 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269534239.08.0.711797346428.issue2768@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Fair enough.

Possible doc patch attached.

----------
Added file: http://bugs.python.org/file16654/fileno_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:27:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Mar 2010 16:27:23 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269534443.17.0.581891811761.issue2768@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl
components: +Documentation -Extension Modules
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:45:48 2010
From: report at bugs.python.org (Neil Muller)
Date: Thu, 25 Mar 2010 16:45:48 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1269535548.73.0.831066135497.issue2768@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

More fleshed out doc patch. Mention caveats about using file descriptors directly, add note to ftruncate similar to that for other dangerous methods.

----------
Added file: http://bugs.python.org/file16655/fileno_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2768>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:53:56 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 25 Mar 2010 16:53:56 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1269536036.38.0.267324720685.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a new version of the patch (v4), against svn trunk (r79422)

Changes since v3:
  * added support for PySetObject (set/frozenset)
  * added support for PyBaseExceptionObject (BaseException)
  * fixed a signed vs unsigned char issue that led to exceptions in gdb for PyStringObject instances containing bytes in the range 0x80-0xff
  * handle the case of loops in the object reference graph.  In previous versions, the gdb prettyprinter would get stuck in infinite recursion following the pointers.  The new version keeps track of the set of all pointers we've visited so far, stopping the traversal at object's we've already reached (analagous to Py_ReprEnter and Py_ReprLeave).
  * unit tests for all of the above (full test suite passes on my machine thus: "Ran 35 tests in 13.547s"; this is a Fedora 12 x86_64 box with gdb-7.0.1-33.fc12)

----------
Added file: http://bugs.python.org/file16656/add-gdb7-python-hooks-to-trunk-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 25 17:55:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 25 Mar 2010 16:55:33 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1269536133.3.0.749637396369.issue8032@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

(adding diff from v3 to v4, for ease of review)

----------
Added file: http://bugs.python.org/file16657/diff-of-gdb7-hooks-v4-relative-to-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:12:02 2010
From: report at bugs.python.org (Jim Duchek)
Date: Thu, 25 Mar 2010 17:12:02 +0000
Subject: [issue5103] ssl.SSLSocket timeout not working correctly when remote
	end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1269537122.49.0.786113324375.issue5103@psf.upfronthosting.co.za>


Jim Duchek <jim.duchek at gmail.com> added the comment:

This is happening 'in the wild' to me fairly regularly.  Since it's not hanging in python, I can't watchdog/kill the thread it's happening in.  matejcik seems correct on fixing this, there's no need to unset the timeout here.

----------
nosy: +Jim.Duchek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5103>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:28:18 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 25 Mar 2010 17:28:18 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1269538098.35.0.333022552038.issue8032@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin <jyasskin at gmail.com>:


----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:41:28 2010
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 25 Mar 2010 17:41:28 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269538888.2.0.0228084920124.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

This is also (naturally) being discussed on python-dev.  I've posted a long message there about it; you can find that message here:

http://mail.python.org/pipermail/python-dev/2010-March/098904.html

I don't know whether it's best to conduct such a discussion here, in Python-Dev, or both.  I assumed Python-Dev is superior because more people will see it.  If it makes sense to move the discussion here we can move it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 18:58:06 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 17:58:06 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269539886.34.0.951160418724.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Well, on initial check the scheduler seems to work well with regular gettimeofday() wall clock instead of clock_gettime().

:)

/* Return thread running time in seconds (with nsec precision). */
static inline long double get_thread_timestamp(void) {
    return get_timestamp(); // wall clock via gettimeofday()
    /*struct timespec ts;
    clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
    return (long double) ts.tv_sec + ts.tv_nsec * 0.000000001;*/
}

Does it make things better on your system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Thu Mar 25 19:32:42 2010
From: report at bugs.python.org (Jonathan Chao)
Date: Thu, 25 Mar 2010 18:32:42 +0000
Subject: [issue8232] webbrowser open(), open_new(),
	and open_new_tab() Broken Functionality
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>


New submission from Jonathan Chao <joncwchao at gmail.com>:

webbrowser.open(), webbrowser.open_new(), and webbrowser.open_new_tab() all do the exact same thing, regardless of the flags that I set. In Firefox, open('www.google.com', new=0), open_new('www.google.com'), and open_new_tab('www.google.com') all open either three new www.google.com tabs (if "Open new windows in a new tab instead" is selected in FF options) or three new www.google.com windows (if "Open new windows in a new tab instead" is not selected in FF options). In Internet Explorer, three new www.google.com tabs are created.

The issue exhibits itself the same way whether or not I have the browser open before running the script.

Environment was a Windows Vista 32-bit machine, running Python 3.1.2.

Example script reads:
import webbrowser
import time
ff = webbrowser.get('firefox')
ff.open('www.google.com', new=0)
time.sleep(3)
ff.open_new('www.google.com')
time.sleep(3)
ff.open_new_tab('www.google.com')

----------
components: Library (Lib)
messages: 101725
nosy: joncwchao
severity: normal
status: open
title: webbrowser open(), open_new(), and open_new_tab() Broken Functionality
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 25 19:34:38 2010
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 25 Mar 2010 18:34:38 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269542078.58.0.0349798697353.issue7992@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Florent: that's because the Windows build projects don't build capsule.c.  I don't have an appropriate Windows development environment; I'll try to fix them by hand tonight, but if that doesn't work we'll have to call for help from some Windows core developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 19:38:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 18:38:40 +0000
Subject: [issue7992] Backport capsule object
In-Reply-To: <1266863326.18.0.347467422477.issue7992@psf.upfronthosting.co.za>
Message-ID: <1269542320.84.0.594646742734.issue7992@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

(adding myself to the nosy list as a Windows dev)

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7992>
_______________________________________

From report at bugs.python.org  Thu Mar 25 20:26:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 19:26:08 +0000
Subject: [issue8232] webbrowser open(), open_new(),
	and open_new_tab() Broken Functionality
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1269545168.68.0.885574390506.issue8232@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

On Windows, the WindowsDefault class gets used and it doesn't make use of anything other than the URL (no 'new' or 'autoraise'). All it does is pass the URL onto os.startfile.

It should make a better attempt at running the URL. Patches welcome, or I'll try to come up with one shortly.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 25 20:26:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 19:26:42 +0000
Subject: [issue8232] webbrowser.open incomplete on Windows
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1269545202.71.0.550565499341.issue8232@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: webbrowser open(), open_new(), and open_new_tab() Broken Functionality -> webbrowser.open incomplete on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 25 20:33:21 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 25 Mar 2010 19:33:21 +0000
Subject: [issue8108] test_ftplib fails with OpenSSL 0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1269545601.31.0.0602952173445.issue8108@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Ok, I've finally been able to reproduce the issue by installing OpenSSL 0.9.8m on my Ubuntu box.
By doing some debugging I'm starting to think that maybe there's something wrong with the shutdown() method implementation itself because no matter what, sooner or later it always ends up raising "error: [Errno 0] Error".

I've cheated by trapping shutdown() in a while loop waiting for it to succeed, I've tried to manually call handle_read() and handle_write(), I've also tried to set the socket back to blocking mode just to see if shutdown() would return but I've always ended up encountering "error: [Errno 0] Error".

IMHO, before going any further I'd investigate on why this call can just fail without providing any information about what happened.
>From the upper application's point of view there's nothing it can do in case of such an error.
Assuming that "the remote side closed the connection abruptly" and close the socket is just wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8108>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:30:40 2010
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Thu, 25 Mar 2010 20:30:40 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>


New submission from Piotr O?arowski <piotr at debian.org>:

Following issue 8140 - attached patches add functionality to take file names to be compiled from standard input in py_compile module (if '-' is the only parameter in args)

----------
components: Library (Lib)
files: py_compile.py.diff
keywords: patch
messages: 101730
nosy: barry, piotr
severity: normal
status: open
title: extend py_compile to compile files from stdin
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16658/py_compile.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:31:07 2010
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Thu, 25 Mar 2010 20:31:07 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1269549068.0.0.627522040811.issue8233@psf.upfronthosting.co.za>


Changes by Piotr O?arowski <piotr at debian.org>:


Added file: http://bugs.python.org/file16659/py_compile.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Thu Mar 25 21:57:13 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 25 Mar 2010 20:57:13 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1269550633.37.0.591365936137.issue8233@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Thu Mar 25 22:06:19 2010
From: report at bugs.python.org (tb220)
Date: Thu, 25 Mar 2010 21:06:19 +0000
Subject: [issue8229] Interpreter crash on application shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269551179.55.0.485896077104.issue8229@psf.upfronthosting.co.za>


tb220 <tb220 at yahoo.com> added the comment:

The application consists of three processes: Process A provides a web interface to the remote user and watchdog services for process B, which A creates by using the multiprocessing module. Process B does the real work and provides a GUI to the local user. Process A communicates with process B via the xmlrpclib module. Both A and B are python processes. Process B uses the subprocess module to start process C, which is not a python process, and it communicates with it using the xmlrpclib module. Process B is the one that crashes every now and then when sys.exit is invoked.

I will try to produce the smallest possible application I can that still suffers from the problem and I will upload it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8229>
_______________________________________

From report at bugs.python.org  Thu Mar 25 22:06:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Mar 2010 21:06:52 +0000
Subject: [issue8232] webbrowser.open incomplete on Windows
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1269551212.27.0.646197901799.issue8232@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Minor correction: BackgroundBrowser gets used in this case, but it still lacks in the same area and causes what you are seeing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8232>
_______________________________________

From report at bugs.python.org  Thu Mar 25 22:47:46 2010
From: report at bugs.python.org (Yuv Gre)
Date: Thu, 25 Mar 2010 21:47:46 +0000
Subject: [issue8234] Spelling and text in howto/webservers
In-Reply-To: <1269553665.96.0.465279813253.issue8234@psf.upfronthosting.co.za>
Message-ID: <1269553665.96.0.465279813253.issue8234@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

A spelling mistake ("recommentation") and a bit rephrasing for clarity. I think better can be done, but more text would have to be moved around.

----------
assignee: georg.brandl
components: Documentation
files: webservers_spelling.patch
keywords: patch
messages: 101733
nosy: georg.brandl, ubershmekel
severity: normal
status: open
title: Spelling and text in howto/webservers
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file16660/webservers_spelling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8234>
_______________________________________

From report at bugs.python.org  Thu Mar 25 23:11:07 2010
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 25 Mar 2010 22:11:07 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269555067.21.0.694827640319.issue8222@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Looks like a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:23:06 2010
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 25 Mar 2010 23:23:06 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1269559386.42.0.0393504884634.issue2704@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Rather than change the core code of IDLE, I've attached an extension to achieve terminal-like behavior. It provides a toggle to enable/disable. However, this extension as-is only works on the 2.x series, although it can be modified slightly to work on 3.x.

----------
Added file: http://bugs.python.org/file16661/Terminal.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:26:28 2010
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 25 Mar 2010 23:26:28 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1269559588.02.0.650243555473.issue3851@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:40:01 2010
From: report at bugs.python.org (Kyle VanderBeek)
Date: Thu, 25 Mar 2010 23:40:01 +0000
Subject: [issue8235] Support FreeBSD's SO_SETFIB in socketmodule.c
In-Reply-To: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>
Message-ID: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>


New submission from Kyle VanderBeek <kylev at kylev.com>:

FreeBSD has a [gs]etsockopt() constant used to cause a given socket to use an alternate routing table (FIB); it appeared in FreeBSD 7.1.  It would be useful to have this exposed as a constant in the socket module to allow special routing rules in complex environments.

----------
components: Extension Modules
files: python-SO_SETFIB.patch
keywords: patch
messages: 101736
nosy: kylev
severity: normal
status: open
title: Support FreeBSD's SO_SETFIB in socketmodule.c
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16662/python-SO_SETFIB.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8235>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:47:29 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 23:47:29 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269560849.1.0.0165691647499.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16644/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 00:52:13 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 25 Mar 2010 23:52:13 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269561133.57.0.403571625521.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Uploaded an updated bfs.patch

The latency problem was related to the --with-computed-gotos flag. I fixed it and it seems to work fine now. 

I also switched to gettimeofday() so it should work now on all Posix with high resolution timer.

----------
Added file: http://bugs.python.org/file16663/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 03:13:41 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Mar 2010 02:13:41 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I'm seeing this error with 2.6 and 3.1 maint branches (not sure about 2.7) on both Linux & Mac 32-bit builds. Does not happen on Linux 64-bit though. Also this is possibly caused by a recent commit, as we never saw this issue before.

[...]
creating Makefile
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/home/apy/as/pypm-trunk/bin/python", line 49, in <module>
    execfile(__file__)
  File "./Parser/asdl_c.py", line 9, in <module>
    import asdl
ImportError: No module named asdl
make: *** [Include/Python-ast.h] Error 1

----------
components: Build, Interpreter Core
messages: 101738
nosy: srid
severity: normal
status: open
title: ./configure: ImportError: No module named asdl
type: compile error
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Fri Mar 26 03:30:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Mar 2010 02:30:30 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1269570630.58.0.420480902108.issue6538@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in trunk (r79430), release26-maint (r79631), py3k (r79434), and release31-maint (r79435). Thanks for the patch.

----------
assignee: georg.brandl -> brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Fri Mar 26 03:36:12 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Mar 2010 02:36:12 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269570972.97.0.752860762093.issue8236@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file16664/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Fri Mar 26 03:36:28 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Mar 2010 02:36:28 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269570988.78.0.791552765384.issue8236@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file16665/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Fri Mar 26 04:32:27 2010
From: report at bugs.python.org (Erdem U. Altinyurt)
Date: Fri, 26 Mar 2010 03:32:27 +0000
Subject: [issue8237] multiprocessing.Queue() blocks program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>


New submission from Erdem U. Altinyurt <spamjunkeater at gmail.com>:

multiprocessing.Queue() blocking program on my computer after adding 1400 entry (depending addition size).

Tested with 2.6.2 and 2.6.5(compiled from source with gcc 4.4.1)
Using 64 bit OpenSUSE  11.2.

Output is:
-----------
....
1398  done
1399  done
-----------

and enters deadlock because Q.put() cannot completed.
No problems with basic array with lock().
Here the result after pressing CTRL+C:

-----------------------------------
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in testQ
KeyboardInterrupt
>>> 
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/opt/python/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/python/lib/python2.6/multiprocessing/util.py", line 269, in _exit_function
    p.join()
  File "/opt/python/lib/python2.6/multiprocessing/process.py", line 119, in join
    res = self._popen.wait(timeout)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 117, in wait
    return self.poll(0)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/opt/python/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/python/lib/python2.6/multiprocessing/util.py", line 269, in _exit_function
    p.join()
  File "/opt/python/lib/python2.6/multiprocessing/process.py", line 119, in join
    res = self._popen.wait(timeout)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 117, in wait
    return self.poll(0)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt

----------
components: Library (Lib)
files: damine6.py
messages: 101740
nosy: eua
severity: normal
status: open
title: multiprocessing.Queue() blocks program
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16666/damine6.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8237>
_______________________________________

From report at bugs.python.org  Fri Mar 26 06:23:26 2010
From: report at bugs.python.org (John Levon)
Date: Fri, 26 Mar 2010 05:23:26 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269581006.64.0.349956079711.issue7946@psf.upfronthosting.co.za>


Changes by John Levon <movement at users.sourceforge.net>:


----------
nosy: +movement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:15:21 2010
From: report at bugs.python.org (Eric Devolder)
Date: Fri, 26 Mar 2010 07:15:21 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1269587721.34.0.810527081742.issue2698@psf.upfronthosting.co.za>


Eric Devolder <eric.devolder at gmail.com> added the comment:

This seems to be fixed now under 3.1.2, and works properly for me.

Great stuff, thank you.

Eric

P.S. Last time I mistakenly tagged the bug to be "Python 3.2" as well, correcting this now.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:33:17 2010
From: report at bugs.python.org (Ciprian Trofin)
Date: Fri, 26 Mar 2010 07:33:17 +0000
Subject: [issue8238] Proxy handling
In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>
Message-ID: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>


New submission from Ciprian Trofin <ciprian.trofin at ktd.ro>:

After I installed Python 2.6.5, I noticed a drop in performance of web connections via proxy.

This script:
---------------------------------------------------------
import time
import urllib2

timeMark = time.time()
opener = urllib2.build_opener()
textWeb = opener.open("http://www.google.com/").read()
print time.time() - timeMark
---------------------------------------------------------

takes about 60 seconds to complete (consistently)

The same script, run using Python 2.6.2 is completed in less than 1 second  (0.2seconds)

The test system:
- Windows XP SP3
- internet connection via corporate connection, using a proxy (the proxy is set in Control Panel - Internet Options etc)

----------
components: None
messages: 101742
nosy: ciprian.trofin
severity: normal
status: open
title: Proxy handling
type: performance
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8238>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:55:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 26 Mar 2010 07:55:13 +0000
Subject: [issue8238] Proxy handling
In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>
Message-ID: <1269590113.12.0.711538645806.issue8238@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

How are setting up and using your proxy? It would also help you discuss your approach at python-help at python.org and if you see any specific issues, raise it in the bug report.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8238>
_______________________________________

From report at bugs.python.org  Fri Mar 26 08:59:48 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 26 Mar 2010 07:59:48 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1269590388.4.0.0897868257257.issue6716@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

r78994 (exclude 2to3 tests from compileall) should be backported to trunk and the 2.6 branch, but I don't see them (yet).

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Fri Mar 26 09:43:03 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 26 Mar 2010 08:43:03 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269592983.95.0.471025920735.issue7946@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 09:43:55 2010
From: report at bugs.python.org (Ciprian Trofin)
Date: Fri, 26 Mar 2010 08:43:55 +0000
Subject: [issue8238] Proxy handling
In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>
Message-ID: <1269593035.91.0.623078965909.issue8238@psf.upfronthosting.co.za>


Ciprian Trofin <ciprian.trofin at ktd.ro> added the comment:

I attached a screenshot.

The proxy is on the corporate network. I'm not setting it up, I'm only using it. Internet Explorer needs that setting in order to connect. Firefox needs this proxy set as "manual proxy configuration".

I looked deeper into the situatioan, usign the following (modified) script:

---------------------------------------------------
import time
import urllib2

timeMark = time.time()
opener = urllib2.build_opener()

proxy = urllib2.ProxyHandler({"http" : "http://10.249.1.63:80"})
opener.add_handler(proxy)

textWeb = opener.open("http://www.google.com/").read()

print time.time() - timeMark

---------------------------------------------------

The only difference from the script above: I set up the proxy manually.
I tested the new script in 2.6.5

With Windows proxy active: same problem, long waiting time.
With Windows proxy disabled: fast execution.

----------
Added file: http://bugs.python.org/file16667/proxy.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8238>
_______________________________________

From report at bugs.python.org  Fri Mar 26 10:10:55 2010
From: report at bugs.python.org (Peter)
Date: Fri, 26 Mar 2010 09:10:55 +0000
Subject: [issue8239] Windows 2.6.5 Installer Advanced Option Generates Error
	Message During Compile Step
In-Reply-To: <1269594655.23.0.434243069051.issue8239@psf.upfronthosting.co.za>
Message-ID: <1269594655.23.0.434243069051.issue8239@psf.upfronthosting.co.za>


New submission from Peter <ps1956 at users.sourceforge.net>:

If the installer is run in Windows XP/SP3 without selecting the Advanced compiling option, it works fine.  If the installer is run in Windows XP/SP3 and the Advanced compiling option is selected, the following error message is generated during the compile step:

"There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support 
personnel or package vendor."

The relevant part of the log when the installer fails using the Advanced compiling option is as follows:

--------------------

MSI (s) (4C:B4) [14:41:27:205]: Doing action: CompilePyc
Action 14:41:27: CompilePyc. 
Action start 14:41:27: CompilePyc.
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 1722 2: CompilePyc 3: C:\bin
\Python26\python.exe 4: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A 
program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action CompilePyc, location: C:\bin\Python26\python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:47:41:133]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (4C:B4) [14:47:41:133]: Product: Python 2.6.5 -- Error 1722. 
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support 
personnel or package vendor.  Action CompilePyc, location: C:\bin\Python26 \python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 

Action ended 14:47:41: CompilePyc. Return value 3.
Action ended 14:47:41: INSTALL. Return value 3.

--------------------

I believe the cause of this installation failure message is due to the 
syntax of the following command:

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib"

If this command is run in the Windows XP shell, it yields an error.  If the -x option's args are wrapped in double quotes, it runs ok (except for a syntax error when compiling one of the python source files - I don't remember which one):

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x "bad_coding|badsyntax|site-packages|py3_" "C:\bin\Python26\Lib"

So it appears that the Windows XP shell is interpreting the "|" 
characters within the -x option's args as pipe characters and tries to 
pipe the "multiple commands" together.

The simple work around is to not use the Advanced compiling option with this release.  If wanted, the compilation step can be performed manually after the installation completes.

----------
components: Installation, Windows
messages: 101746
nosy: ps1956
severity: normal
status: open
title: Windows 2.6.5 Installer Advanced Option Generates Error Message During Compile Step
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8239>
_______________________________________

From report at bugs.python.org  Fri Mar 26 12:31:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 11:31:39 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1269603099.4.0.935729990487.issue8194@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In Python 2.6/3.1, xmlrpclib.Transport.parse_response() accepts a file like object. But Python 2.7/3.2 requires a HTTPResponse object because parse_response() calls response.getheader() method.

The patch moves the call to .getheader() in single_request() to accept a file-like object in parse_response(). But I don't understand why the gzip support is implemented in xmlrpclib instead of httplib.

The problem is related to M2Crypto which pass a BIO object (file-like object, without .getresponse() method).

----------
nosy: +haypo
title: broken API in xmlrpclib.Transport -> Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
versions: +Python 2.7, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Fri Mar 26 14:51:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Mar 2010 13:51:46 +0000
Subject: [issue8239] Windows 2.6.5 Installer Advanced Option Generates Error
	Message During Compile Step
In-Reply-To: <1269594655.23.0.434243069051.issue8239@psf.upfronthosting.co.za>
Message-ID: <1269611506.11.0.228166781101.issue8239@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This is fixed as of r79248.

----------
nosy: +brian.curtin
priority:  -> normal
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8239>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:46:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Mar 2010 14:46:17 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269614777.29.0.694730415278.issue8236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can't reproduce this on 2.6 maint on Linux 32 bit (Gentoo).

Did you try doing a make distclean before redoing the configure/make?

----------
nosy: +benjamin.peterson, r.david.murray
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:51:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Mar 2010 14:51:49 +0000
Subject: [issue8237] multiprocessing.Queue() blocks program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1269615109.25.0.16345000218.issue8237@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Crash is for interpreter segfaults, changing to type 'behavior'.  Setting stage to 'test needed' because if this is a valid bug the test will need to be turned into a unit test.

----------
nosy: +jnoller, r.david.murray
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8237>
_______________________________________

From report at bugs.python.org  Fri Mar 26 15:54:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Mar 2010 14:54:29 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269615269.11.0.41344882834.issue8193@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

According to http://www.zlib.net/ChangeLog.txt, since zlib 1.2.3.5::
    - Use zlib header window size if windowBits is 0 in inflateInit2()

The failing test should be changed, for example::
    self.assertRaises(ValueError, zlib.decompressobj, -1)

----------
keywords: +easy, patch
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:20:14 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 26 Mar 2010 15:20:14 +0000
Subject: [issue8237] multiprocessing.Queue() blocks program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1269616814.36.0.327823469004.issue8237@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

multiprocessing.Queue.Put() acts the same as Queue.put() - if the queue is full, the put call "hangs" until the queue is no longer full. The process will not exit, as the Queue is full, and it's waiting in put.

This works as designed, unless I'm missing something painfully obvious, which is entirely possible.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8237>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:30:34 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 15:30:34 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>


New submission from Cyril <cbay at excellency.fr>:

ssl.SSLSocket.write on non-blocking sockets will fail with:

_ssl.c:1217: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry

on a write retry, if the buffer address has changed between the initial call and the retry (when the initial call returned 0 bytes written, which means you should try again later).

>From OpenSSL docs (http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html):

SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer location (the buffer contents must stay the same). This is not the default to avoid the misconception that non-blocking SSL_write() behaves like non-blocking write().

Attached patch fixes the problem (tested on Python 2.6.5, 2.7 trunk) by calling SSL_CTX_set_mode with SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER. It's a single line patch.

----------
components: Library (Lib)
files: _ssl.c.patch
keywords: patch
messages: 101753
nosy: cbay
severity: normal
status: open
title: ssl.SSLSocket.write may fail on non-blocking sockets
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16668/_ssl.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:35:20 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 15:35:20 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269617720.19.0.0827981415417.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

The following test case exhibits the bug, but I'm not sure it will fail every time as it depends on 2 things:

 - your connection speed (I guess)
 - I used the following trick to have 2 identical strings with a different id (memory address):

data = (('xx'[0] + 'xx'[1:])*10000, ('xx'[0] + 'xx'[1:])*10000)

I'm not sure it will work all the time though.

----------
Added file: http://bugs.python.org/file16669/test_ssl.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:57:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Mar 2010 15:57:01 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269619021.9.0.745122715579.issue8240@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Extension Modules -Library (Lib)
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 16:57:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Mar 2010 15:57:19 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269619039.24.0.704476274753.issue8240@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:01:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 16:01:11 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1269619271.65.0.790421943526.issue6543@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> "surrogateescape" characters are not printable

stderr uses backslashescape error handler, and so non-decodable characters will be displayed as \xHH.

... see also #8092 :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:11:05 2010
From: report at bugs.python.org (Erdem U. Altinyurt)
Date: Fri, 26 Mar 2010 16:11:05 +0000
Subject: [issue8237] multiprocessing.Queue() blocks program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1269619865.36.0.41884883067.issue8237@psf.upfronthosting.co.za>


Erdem U. Altinyurt <spamjunkeater at gmail.com> added the comment:

Firstly I think as you but this is not correct.
Added Q.full() to know if Queue is full or not to the testQ code..

def testQ():
   for i in range(10000):
      mp.Process( None, QueueWorker, None, (i,Q,lock) ).start()
      while len(mp.active_children())>=mp.cpu_count()+4:
        time.sleep(0.01)
        print Q.full()

output is:
1397  done
1398  done
1399  done
False
False
False

So Queue is not full. And you can also add some things to queue at this state(by adding extra line to  while loop) and this will not blocks while loop.

Please test..

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8237>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:14:15 2010
From: report at bugs.python.org (Konrad Delong)
Date: Fri, 26 Mar 2010 16:14:15 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269620055.02.0.68024186622.issue7946@psf.upfronthosting.co.za>


Changes by Konrad Delong <konryd at gmail.com>:


----------
nosy: +konryd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:32:23 2010
From: report at bugs.python.org (Alexandre Conrad)
Date: Fri, 26 Mar 2010 16:32:23 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269621143.77.0.175561454582.issue7946@psf.upfronthosting.co.za>


Changes by Alexandre Conrad <alexandre.conrad at gmail.com>:


----------
nosy: +aconrad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 17:37:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 16:37:09 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269621429.64.0.818986707242.issue8240@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 18:47:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 17:47:47 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269625667.56.0.192488380101.issue8240@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If I understood correctly, the patch only concerns non blocking socket if SSL_write() returns 0? If SSL_write() returns a non zero value, can you use: ssl_socket.send(data[count:])?

About the string identifier trick, you should add an assertion to ensure that identifiers are differents. Example:
--------
a = 'x' * 20000
# create a copy with a different memory address
b = a[0:] + a[1:]
assert (a == b) and (a is not b)
data = a, b
--------

See also issue #8222: enabling SSL_MODE_AUTO_RETRY on SSL sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 18:48:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 17:48:34 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269625714.93.0.97558804766.issue8222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #8240 about SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER (ssl.SSLSocket.write may fail on non-blocking sockets).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 18:49:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 17:49:38 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269625778.83.0.841727054338.issue8222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> letting the C OpenSSL runtime do it for us is certainly more efficient

+1 if it's more efficient ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 18:51:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Mar 2010 17:51:27 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269625887.24.0.573722973929.issue8222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Would it be possible to add an option to disable SSL_MODE_AUTO_RETRY for a specific socket? Existing applications may rely on / prefer the current behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:05:03 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 18:05:03 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269626703.51.0.537211356487.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

You're right about the assert, I've just uploaded a new patch.

In non-blocking mode, ssl_socket.send(data) will return either 0 (which means nothing was sent, you'll have to try again), or len(data) when everything was sent. It can't return anything inbetween. This is because SSL_MODE_ENABLE_PARTIAL_WRITE is not enabled.

In my opinion, SSL_MODE_ENABLE_PARTIAL_WRITE should probably be enabled, although I don't know if it would have any consequence on existing code. Note that _ssl.c header has:

   XXX should partial writes be enabled, SSL_MODE_ENABLE_PARTIAL_WRITE?

However, it's totally unrelated to our bug. Issue #8222 is also unrelated since SSL_MODE_AUTO_RETRY only applies to blocking sockets.

By the way, this bug was triaged "test needed". Am I missing anything? This is my first reported bug, I'm not sure about the process.

----------
Added file: http://bugs.python.org/file16670/test_ssl.py.patch.v2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:09:23 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 18:09:23 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269626963.62.0.325930435582.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

I forgot to talk about the conditions in which I stumbled upon that bug. I use a cStringIO.StringIO as a send buffer. When the socket is ready to send data, I call ssl_socket.send(send_buffer.getvalue()).

Unfortunately, two consecutive calls to send_buffer.getvalue() may return a different object (i.e. a string with a different memory address).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:24:29 2010
From: report at bugs.python.org (Guilherme Salgado)
Date: Fri, 26 Mar 2010 18:24:29 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269627869.04.0.787837465584.issue7946@psf.upfronthosting.co.za>


Changes by Guilherme Salgado <gsalgado at gmail.com>:


----------
nosy: +salgado

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:26:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Mar 2010 18:26:57 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269628017.77.0.0692172821819.issue8240@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"test needed" is in reference to your assertion that you weren't sure your test would fail reliably.  A test that fails some times and passes some times is...suboptimal when dealing with a buildbot testing infrastructure :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:28:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 18:28:57 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269625887.24.0.573722973929.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269628247.3327.10.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Would it be possible to add an option to disable SSL_MODE_AUTO_RETRY
> for a specific socket? Existing applications may rely on / prefer the
> current behaviour.

I don't think so, since recv() used to emulate that behaviour anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:30:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 18:30:35 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269628235.78.0.152585476252.issue8240@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:36:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 26 Mar 2010 18:36:23 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1269628583.23.0.0127114892817.issue6716@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Gabriel: can you explain why that should be backported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:36:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 18:36:23 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269628583.31.0.56866004315.issue8240@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since this error seems to be aimed at warning about potential programming errors, I'm not sure it should be silenced. The obvious fix should be to pass the same argument every time (until the data finally gets written).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:41:47 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 18:41:47 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269628907.42.0.299807879301.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

r.david.murray: ah, sure :) However, I'm not sure a test case is absolutely required for this issue for two reasons:

 - the fix is trivial: it's a one-liner that enables a SSL mode that explicitely authorizes SSL_write to be called a second time with a a different memory pointer than the first time. Since memory pointers are opaque to Python programmers anyway, I doubt it could break code (unless you'd expect the failure, of course :) )

 - tests about SSL in non-blocking mode are almost inexistant, I think. The only one I could find tests the handshake. See issue #3890 for instance. Probably because writing tests in non-blocking mode isn't easy.

However, my test may be correct, I'm just not sure it will pass everywhere :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:47:41 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 18:47:41 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269629261.09.0.26318395745.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

pitrou: that's debatable, since the Python programmer has no control over memory pointers. As I said, I have a cStringIO buffer, and two consecutive calls to buffer.getvalue() yield different objects. What can I do about it? I think it's a rather sane scenario, and I don't feel I'm doing anything wrong.

If you think the programmer should be alerted about it, however, then we should at least say it explicitely in the documentation and probably return an explicit Python error. I had to google quite a bit before finding out what this error meant:

error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 19:58:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 18:58:58 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269629261.09.0.26318395745.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269630048.3327.16.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pitrou: that's debatable, since the Python programmer has no control
> over memory pointers.

No, but he has control over whether he always uses the same object, or
generates a new argument everytime.

>  As I said, I have a cStringIO buffer, and two consecutive calls to
> buffer.getvalue() yield different objects. What can I do about it? I
> think it's a rather sane scenario, and I don't feel I'm doing anything
> wrong.

Hmm, indeed. What you can do, very simply, is cache the getvalue()
result once you have generated it.

> If you think the programmer should be alerted about it, however, then
> we should at least say it explicitely in the documentation and
> probably return an explicit Python error. I had to google quite a bit
> before finding out what this error meant:
> 
> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry

Indeed, this is cryptic.

By the way, I've found a thread explaining this in greater detail:
http://readlist.com/lists/openssl.org/openssl-users/0/1794.html

Basically, even when SSL_write() says the write must be retried, it does
process and buffer some of your data, so that if you retry with
different data, some junk will be written out on the SSL socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:09:15 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 19:09:15 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269630555.96.0.998944132648.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

Switching to a documentation issue is fine to me. Indeed I can just cache the result of StringIO.getvalue(), although it feels a bit crude.

I won't be able to create a documentation patch since English is not my primary language. While you're at it, the doc says about SSLSocket.write:

Returns the number of bytes written.

It actually either returns 0 or len(data), at least as long as we don't have SSL partial writes. That's a different behaviour from regular sockets, and I had to look in _ssl.c to figure out why I never had values inbetween.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Fri Mar 26 20:39:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 19:39:30 +0000
Subject: [issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269632370.79.0.504257732612.issue8222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r79448 (trunk), r79449 (py3k), r79451 (2.6), r79453 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8222>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:09:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Mar 2010 20:09:58 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269634198.55.0.998957954201.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also switched to gettimeofday() so it should work now on all Posix 
> with high resolution timer

But on a busy system, won't measuring wall clock time rather than CPU time give bogus results?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 21:25:06 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 26 Mar 2010 20:25:06 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269635106.78.0.264749903103.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> But on a busy system, won't measuring wall clock time rather than CPU time give bogus results?

This was the motivation for using clock_gettime(). I tried the wall clock version under load (including on single core system) and it seems to behave. Now it remains to rationalize it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 23:48:57 2010
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 26 Mar 2010 22:48:57 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269643737.97.0.149277406222.issue7946@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri Mar 26 23:50:11 2010
From: report at bugs.python.org (Augie Fackler)
Date: Fri, 26 Mar 2010 22:50:11 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269643811.87.0.868528377383.issue7946@psf.upfronthosting.co.za>


Changes by Augie Fackler <lists at durin42.com>:


----------
nosy: +durin42

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 00:55:52 2010
From: report at bugs.python.org (Peter Kleiweg)
Date: Fri, 26 Mar 2010 23:55:52 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1269647752.95.0.522209751002.issue4953@psf.upfronthosting.co.za>


Changes by Peter Kleiweg <pkleiweg at xs4all.nl>:


----------
nosy: +pebbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:22:23 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 00:22:23 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269649343.98.0.895643492236.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It would be really useful to be able to send signal.SIGINT to processes on Windows using os.kill(...). The patch as described sounds like it would have a different signature to the standard implementation of os.kill(...) which takes a pid and a signal type. 

IronPython 2.7 will have an os.kill implementation. Looks like it only supports signal.SIGINT and signal.SIGBREAK and just calls:

    Process toKill = Process.GetProcessById(pid);
    toKill.Kill()

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:22:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 00:22:55 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269649375.03.0.247412392118.issue1220212@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:27:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 00:27:56 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269649676.21.0.125670883463.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm wrong. First IronPython tries:

NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...)

But with the comment:

//The following calls to GenerateConsoleCtrlEvent will fail under
//most circumstances. We'll try them any ways though as this seems
//to be the only mechanism in Windows to send signals to processes

It falls back to just killing the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:29:17 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 27 Mar 2010 00:29:17 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1269649757.91.0.698626652229.issue6716@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Sorry for being so terse and not filling in the gaps! In the end, I changed my mind on this bug - it's not an installer issue.

The 2.6.5 MSI installer, when asked to compile .pyc files, exits with an error as reported here:
http://mail.python.org/pipermail/python-list/2010-March/1240182.html

Both Problem#1 and Problem#3 (as reported in this issue) apply to the 2.6.5 installer. Properly quoting the -x argument fixed Problem#1 (already done). But Problem#3 still applies: compileall fails on one test case in lib2to3 because of a syntax error (this was not so clearly stated in the c.l.p. post). The error is:

SyntaxError: ('invalid syntax', ('d:\\apps\\python26\\Lib\\lib2to3\\tests\\data\\py2_test_grammar.py', 936, 23, '        with manager(), manager():\n'))

That syntax is not 2.6 compatible (but 2.7 does allow it).

My initial idea was to completely exclude lib2to3\tests from being precompiled, as done in r78994 for py3k, and both for 2.6 and 2.7. But after looking more closely to the error (and noticing that it is legal in 2.7) I'd leave the installer as it is, and report the issue in py2_test_grammar.py as a separate bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:30:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 00:30:59 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269649859.16.0.0278421622229.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Aaaand the IronPython implementation of NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...)
 delegates to Kernel32.GenerateConsoleCtrlEvent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:37:14 2010
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Paulo_Farias?=)
Date: Sat, 27 Mar 2010 00:37:14 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1269650234.36.0.6318486892.issue4749@psf.upfronthosting.co.za>


Jo?o Paulo Farias <jpaulofarias at gmail.com> added the comment:

I dont see the resolution for this problem yet... What should I do to not have it happen?

----------
nosy: +jpfarias

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:49:00 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 27 Mar 2010 00:49:00 +0000
Subject: [issue8241] py2_test_grammar.py contains invalid syntax for 2.6
In-Reply-To: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>
Message-ID: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Lib\lib2to3\tests\data\py2_test_grammar.py, in test_with_statement, requires a variant of the with statement (multiple targets) that is not available in Python 2.6.  Compiling py2_test_grammar.py raises a SyntaxError.  This makes the 2.6.5 installer exit with an error message when asked to pre-compile all .pyc files, as reported in issue6716.

The fix is simply to remove the last three 'with' statements in function test_with_statement, around line 923 in Lib\lib2to3\tests\data\py2_test_grammar.py, as this is invalid code for this Python version.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101779
nosy: gagenellina
severity: normal
status: open
title: py2_test_grammar.py contains invalid syntax for 2.6
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:50:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Mar 2010 00:50:53 +0000
Subject: [issue8241] py2_test_grammar.py contains invalid syntax for 2.6
In-Reply-To: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>
Message-ID: <1269651053.35.0.598267234933.issue8241@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:53:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Mar 2010 00:53:45 +0000
Subject: [issue8234] Spelling and text in howto/webservers
In-Reply-To: <1269553665.96.0.465279813253.issue8234@psf.upfronthosting.co.za>
Message-ID: <1269651225.36.0.0432627359007.issue8234@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closed as duplicate of #8218.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8234>
_______________________________________

From report at bugs.python.org  Sat Mar 27 01:54:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Mar 2010 00:54:55 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269651295.55.0.302911218685.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #8234 that has a patch with some rephrasing too.

----------
nosy: +ubershmekel
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:06:07 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Mar 2010 01:06:07 +0000
Subject: [issue8241] py2_test_grammar.py contains invalid syntax for 2.6
In-Reply-To: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>
Message-ID: <1269651967.71.0.444023504797.issue8241@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The correct thing to do is actually to ignore py2_test_grammar.py when compiling the pyc files.

----------
assignee: benjamin.peterson -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8241>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:12:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Mar 2010 01:12:37 +0000
Subject: [issue8242] Support surrogates in import ;
	install Python in a non-ASCII directory
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If the fullpath to the python3 binary contains a non-ASCII character and the file system encoding is ASCII, Python fails with:
---
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8
Abandon
---

The file system encoding is set to ASCII if there is no locale (eg. LANG=C).

The problem is that the command line argument, especially argv[0], is stored to a wchar_t* string using surrogates to store undecodable bytes.

Attached patch fixes calculate_path() and import functions to support surrogates. Details:

 * Initialize Py_FileSystemDefaultEncoding earlier in Py_InitializeEx(), because its value is required to encode unicode using surrogates to bytes
 * Rename char2wchar() to _Py_char2wchar(), the function is not more static ; and create function _Py_wchar2char()
 * Escape surrogates (reimplement surrogateescape decoder) in calculate_path() subfunctions (_wstat, _wgetcwd, _Py_wreadlink)
 * Use surrogateescape error handler in find_module(), NullImporter_init() and zipimporter_init()
 * Write a "fastpath" (I don't know the right term: is it an hack?) for utf-8 encoding with surrogateescape error handler in PyUnicode_AsEncodedObject() and PyUnicode_AsEncodedString(): required because these functions are called by codecs module is initialized

The patch is a work in progress: there are some FIXME (I don't know if the string should be encoded/decoded using surrogates or not).

I only tested ASCII and UTF-8 file system encodings. I don't know if we can support more encodings. Python has few builtin encodings. Other encodings are implemented in Python: we have to import them, but we need the codec to import a module, so...

I don't think that Windows is affected by this issue because it has a better API for unicode filenames and command line arguments, and most patched functions are surrounded by #ifndef WINDOWS ... #endif

----------
components: Unicode
files: surrogates_bootstrap-4.patch
keywords: patch
messages: 101815
nosy: haypo
severity: normal
status: open
title: Support surrogates in import ; install Python in a non-ASCII directory
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16671/surrogates_bootstrap-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:17:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Mar 2010 01:17:34 +0000
Subject: [issue8242] Support surrogates in import ;
	install Python in a non-ASCII directory
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1269652654.58.0.502986764922.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If I understood correctly, my patch is also required to import a module having a non-ASCII full path if the file system encoding is ASCII.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:22:30 2010
From: report at bugs.python.org (Kyle VanderBeek)
Date: Sat, 27 Mar 2010 01:22:30 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1269652950.56.0.481452514319.issue8086@psf.upfronthosting.co.za>


Changes by Kyle VanderBeek <kylev at kylev.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16672/python-ssl-PEM_FOOTER.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:25:15 2010
From: report at bugs.python.org (Kyle VanderBeek)
Date: Sat, 27 Mar 2010 01:25:15 +0000
Subject: [issue8086] ssl.get_server_certificate new line missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1269653115.94.0.943634788137.issue8086@psf.upfronthosting.co.za>


Kyle VanderBeek <kylev at kylev.com> added the comment:

Forgot to note that my patch is against 2.7 current trunk.

----------
nosy: +kylev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8086>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:51:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Mar 2010 01:51:07 +0000
Subject: [issue8242] Support surrogates in import ;
	install Python in a non-ASCII directory
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1269654667.1.0.495795915419.issue8242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Initialize Py_FileSystemDefaultEncoding earlier in Py_InitializeEx(),
> because its value is required to encode unicode using surrogates to bytes

Oh, it doesn't work: get_codeset() returns NULL, because the codec register is empty when get_codeset() is called (with my patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Sat Mar 27 02:57:46 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 27 Mar 2010 01:57:46 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1269655066.62.0.609342833584.issue4749@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

@jpfarias: could you be more specific? Which error(s) do you have? in which scenario?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:01:07 2010
From: report at bugs.python.org (Daniel Vim)
Date: Sat, 27 Mar 2010 05:01:07 +0000
Subject: [issue8243] curses writing to window's bottom right position raises:
	`_curses.error: addstr() returned ERR'
Message-ID: <1269666067.28.0.32380615709.issue8243@psf.upfronthosting.co.za>


Changes by Daniel Vim <333222 at gmail.com>:


----------
files: curses_bug.py
nosy: theosp
severity: normal
status: open
title: curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR'
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16673/curses_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8243>
_______________________________________

From report at bugs.python.org  Sat Mar 27 06:48:23 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 27 Mar 2010 05:48:23 +0000
Subject: [issue4621] zipfile returns string but expects binary
In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>
Message-ID: <1269668903.25.0.157324655743.issue4621@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

I just "discovered" that attempting to open zip member "test\file" fails where attempting to open "test/file" works.  Granted the zip contains "/" not "\" characters, but using the os.path stuff (on windows) to manipulate the names before attempting to open the zip member produces "\" characters.  Clearly, I could switch them back.  It seems pretty clear that zipfile should do that for me, though.

A small, self-contained zip file test case is attached, being a zip that is named .py 

My testing using Python 3.1.1

----------
nosy: +v+python
Added file: http://bugs.python.org/file16674/testzip.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4621>
_______________________________________

From report at bugs.python.org  Sat Mar 27 09:46:51 2010
From: report at bugs.python.org (Nir Aides)
Date: Sat, 27 Mar 2010 08:46:51 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269679611.62.0.052294510531.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

gilinter.patch has good IO latency in UDP test on my system when built with --with-computed-gotos:

In [34]: %timeit -n3 client.work()
0.320 seconds (32782026.509 bytes/sec)
0.343 seconds (30561727.443 bytes/sec)
0.496 seconds (21154075.417 bytes/sec)
0.326 seconds (32171215.998 bytes/sec)
0.462 seconds (22701809.421 bytes/sec)
0.378 seconds (27722146.793 bytes/sec)
0.391 seconds (26826713.409 bytes/sec)
0.315 seconds (33335858.720 bytes/sec)
0.281 seconds (37349508.136 bytes/sec)
3 loops, best of 3: 329 ms per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:44:25 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Mar 2010 10:44:25 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1269650234.36.0.6318486892.issue4749@psf.upfronthosting.co.za>
Message-ID: <237075.77879.qm@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> From: Jo?o Paulo Farias <report at bugs.python.org>

> I dont see the resolution for this problem yet... What should I 
> do to not have it happen?

Don't use RotatingFileHandler in any process which spawns a subprocess. In a multiprocess situation where you want to use rotating log files, have a dedicated subprocess (which does not spawn any children) which listens for logging events on a socket and writes them to the rotated log. Have every other process use SocketHandler to log events to the aforementioned dedicated process. There is an example in the Python documentation of listening for events on a socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat Mar 27 11:58:21 2010
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Paulo_Farias?=)
Date: Sat, 27 Mar 2010 10:58:21 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1269687501.3.0.0205743205878.issue4749@psf.upfronthosting.co.za>


Jo?o Paulo Farias <jpaulofarias at gmail.com> added the comment:

Ok.. I was hoping for a solution that did not involve running a separate process just for logging.

Gabriel: Yeah, I have a python application that uses threads and spawns processes, even tho the processes it spawns have nothing related to the log file.

Also, I noticed that I get the problem even before spawning any processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat Mar 27 12:49:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 27 Mar 2010 11:49:29 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269690569.11.0.448069350946.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a version of the patch that adds exact comparisons between the various numeric types.  The only slightly tricky comparison is the Fraction <-> Decimal one:  an obvious strategy is to convert the Decimal exactly to a Fraction and then use the fraction comparison, but this is inefficient for Decimal instances with large exponent.  So instead, we compare a Decimal `x` with a Fraction `n/d` by comparing `x*d` with `n` in the Decimal domain.

----------
Added file: http://bugs.python.org/file16675/numeric_hash5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:26:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 13:26:47 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269696407.16.0.295328048726.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, the gilinter patch shouldn't be sensitive to whether computed gotos are enabled or not. Here is an updated patch, though, the previous one didn't apply cleanly anymore. I've also made the priority condition a bit stricter.

----------
Added file: http://bugs.python.org/file16676/gilinter2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:26:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 13:26:54 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269696414.6.0.780736207368.issue7946@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16238/issuegil.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:27:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 13:27:01 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269696421.72.0.61048319964.issue7946@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16317/gilprio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:27:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 13:27:06 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269696426.46.0.839147790426.issue7946@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16329/gilinter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:29:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Mar 2010 13:29:51 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269630555.96.0.998944132648.issue8240@psf.upfronthosting.co.za>
Message-ID: <201003271429.41912.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ..., the doc says about SSLSocket.write:
> 
> Returns the number of bytes written.
> 
> It actually either returns 0 or len(data), at least as long as we don't
>  have SSL partial writes. That's a different behaviour from regular
>  sockets, and I had to look in _ssl.c to figure out why I never had values
>  inbetween.

You should open a new issue for this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:39:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 13:39:06 +0000
Subject: [issue8242] Support surrogates in import ;
	install Python in a non-ASCII directory
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1269697146.87.0.742600210531.issue8242@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8242>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:46:45 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Mar 2010 13:46:45 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1269687501.3.0.0205743205878.issue4749@psf.upfronthosting.co.za>
Message-ID: <714221.58327.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Jo?o Paulo Farias <jpaulofarias at gmail.com> 
added the comment:

> Ok.. I was hoping for a solution that did not involve running a 
> separate process just for logging.

It needn't *just* be for logging - as long as it doesn't spawn any child processes. And the need to run a separate process stems from the fact that there's no reliable cross-platform way (in the Python stdlib) of synchronising access to a resource (such as a file) from multiple processes.

There are other solutions, no doubt, but the separate process will probably be the quickest and easiest to implement.

> Also, I noticed that I get 
> the problem even before spawning any 
> processes.

If you're sure about this, and not running into any of the other gotchas mentioned in the thread, then please post a small script which succinctly demonstrates the problem, and I'll look at it. Numerous people have posted problem scripts in this thread (e.g. Neyro, Robert Cronk, Frans) but the problem has generally turned out to be not related to logging specifically, but more generically handle inheritance, differences/limitations in implementations of subprocess under Windows etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:52:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 13:52:14 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269697934.79.0.521990270946.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons).

An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:52:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 13:52:18 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269697938.94.0.705183814263.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons).

An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:52:37 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 13:52:37 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269697957.58.0.0519063222516.issue1220212@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 14:58:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 13:58:43 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269698323.88.0.00126881477482.issue1220212@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 15:29:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Mar 2010 14:29:28 +0000
Subject: [issue8244] Remove obsolete update.sh in PEPs repo
In-Reply-To: <1269700168.47.0.104127262998.issue8244@psf.upfronthosting.co.za>
Message-ID: <1269700168.47.0.104127262998.issue8244@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello

A script named update.sh was added to the PEPs repository seven years ago to batch convert text PEPs to HTML and push them to a public server (http://svn.python.org/view/peps/trunk/update.sh). I suggest removing it  as it appears to have been unmaintained and superseded by a makefile that is maintained and used (http://svn.python.org/view/peps/trunk/Makefile) together with a post-commit hook.

Regards

----------
assignee: georg.brandl
components: Documentation
messages: 101830
nosy: georg.brandl, merwok
severity: normal
status: open
title: Remove obsolete update.sh in PEPs repo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8244>
_______________________________________

From report at bugs.python.org  Sat Mar 27 16:42:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 15:42:31 +0000
Subject: [issue8244] Remove obsolete update.sh in PEPs repo
In-Reply-To: <1269700168.47.0.104127262998.issue8244@psf.upfronthosting.co.za>
Message-ID: <1269704551.2.0.844732178992.issue8244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You're right, the script even uses CVS. Fixed in r79470.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8244>
_______________________________________

From report at bugs.python.org  Sat Mar 27 17:10:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Mar 2010 16:10:14 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1269706214.37.0.789629018035.issue2706@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________

From report at bugs.python.org  Sat Mar 27 18:37:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 17:37:34 +0000
Subject: [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1269711454.77.0.236918909757.issue8074@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ctrl-C handling now implemented (-c command line option). Still needs documentation, but there is a bunch of this outstanding and I will do it in one go and rework the unittest docs at the same time.

----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8074>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:20:48 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2010 18:20:48 +0000
Subject: [issue8245] email examples don't actually work (SMTP.connect is not
	called)
In-Reply-To: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>
Message-ID: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Documentation for Python 2.6.5 and 3.1.2 both describe using the smtplib as so:

    s = smtplib.SMTP()
    s.sendmail(me, [you], msg.as_string())
    s.quit()

However, this sample usage is incorrect and doesn't work in practice, because s.connect() is never called. If the reader copies the example code, he will get an error on the call to sendmail:

    smtplib.SMTPServerDisconnected: please run connect() first

The documentation should be updated to reflect the requisite s.connect() call (or to supply sample host/port parameters in the construction).

It appears that in the 2.3.5 docs, the .connect() call was there. I have not yet investigated why it was removed.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 101833
nosy: georg.brandl, jaraco
severity: normal
status: open
title: email examples don't actually work (SMTP.connect is not called)
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8245>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:28:37 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 27 Mar 2010 18:28:37 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269714517.79.0.0679440295284.issue8236@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I didn't have to run 'make distclean', because this is a fresh clone.

$ hg clone http://code.python.org/hg/branches/release2.6-maint/
$ cd release2.6-maint
$ ./configure --prefix=`pwd`/i

$ make
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/home/apy/as/pypm-trunk/bin/python", line 49, in <module>
    execfile(__file__)
  File "./Parser/asdl_c.py", line 9, in <module>
    import asdl
ImportError: No module named asdl
make: *** [Include/Python-ast.h] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:31:52 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 27 Mar 2010 18:31:52 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl (when run
	from buildout's python)
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269714712.13.0.96130742201.issue8236@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ah, I see what is happening. My $PATH has a buildout's python (bin/python) path. Apparently that is messing up with sys.path. Using /usr/local/bin/python, for instance, in $PATH does not give this problem.

----------
title: ./configure: ImportError: No module named asdl -> ./configure: ImportError: No module named asdl (when run from buildout's python)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:32:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 18:32:21 +0000
Subject: [issue8246] test_signal in test_subprocess displays traceback
In-Reply-To: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>
Message-ID: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_signal in test_subprocess doesn't mute the subprocess stderr, which gives output such as:

test_subprocess
.
    this bit of output is from a test of stdout in a different process ...
.
    this bit of output is from a test of stdout in a different process ...
.
    this bit of output is from a test of stdout in a different process ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt

----------
components: Tests
messages: 101836
nosy: flox, gps, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_signal in test_subprocess displays traceback
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8246>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:33:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Mar 2010 18:33:14 +0000
Subject: [issue7913] Enhance Cmd support for docstrings and document it.
In-Reply-To: <1265914642.07.0.496715269242.issue7913@psf.upfronthosting.co.za>
Message-ID: <1269714794.01.0.553554795621.issue7913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

This would be a nice improvement. This weakness is indeed mentioned on PyMotW.

How about using textwrap.dedent?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7913>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:33:59 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 27 Mar 2010 18:33:59 +0000
Subject: [issue8246] test_signal in test_subprocess displays traceback
In-Reply-To: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>
Message-ID: <1269714839.35.0.838144605061.issue8246@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8246>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:34:37 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 27 Mar 2010 18:34:37 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl (when run
	from buildout's python)
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269714877.98.0.640648211582.issue8236@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I am not sure how "import asdl" works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:34:47 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2010 18:34:47 +0000
Subject: [issue8245] email examples don't actually work (SMTP.connect is not
	called)
In-Reply-To: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>
Message-ID: <1269714887.99.0.650511421658.issue8245@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

It appears in r71882, the change was made in deference to issue4239.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8245>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:38:23 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2010 18:38:23 +0000
Subject: [issue8245] email examples don't actually work (SMTP.connect is not
	called)
In-Reply-To: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>
Message-ID: <1269715103.13.0.528996170521.issue8245@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

According to issue4239#msg75355, the connect call is not required, but I believe he is mistaken. The connect call is required unless the s object is constructed with host/port parameters, in which case the call to connect (without any parameters) will result in various output depending on how localhost responds to the connection request.

In any case, the original recommendation still stands, that the .connect() call should be restored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8245>
_______________________________________

From report at bugs.python.org  Sat Mar 27 19:39:57 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2010 18:39:57 +0000
Subject: [issue8245] email examples don't actually work (SMTP.connect is not
	called)
In-Reply-To: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>
Message-ID: <1269715197.3.0.201772584705.issue8245@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Matt, I hope you don't mind, but I added you as nosy on this issue as it relates to a change you suggested.

----------
nosy: +matt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8245>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:03:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 27 Mar 2010 19:03:47 +0000
Subject: [issue8246] test_signal in test_subprocess displays traceback
In-Reply-To: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>
Message-ID: <1269716627.08.0.206060948376.issue8246@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It is already fixed in 2.7, with r79344, r79346 and r79350.

Need porting to other branches.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8246>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:09:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Mar 2010 19:09:59 +0000
Subject: [issue7913] Enhance Cmd support for docstrings and document it.
In-Reply-To: <1265914642.07.0.496715269242.issue7913@psf.upfronthosting.co.za>
Message-ID: <1269716999.3.0.194889722273.issue7913@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem with using textwrap is that you'd have to identify paragraph boundaries and example code to avoid messing up the meaning of the doc string.  At that point, one might as well go for full ReST markup parsing, and I don't think that is appropriate :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7913>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:24:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Mar 2010 19:24:01 +0000
Subject: [issue7913] Enhance Cmd support for docstrings and document it.
In-Reply-To: <1269716999.3.0.194889722273.issue7913@psf.upfronthosting.co.za>
Message-ID: <4BAE5B4E.7000106@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> The problem with using textwrap is that you'd have to identify paragraph boundaries
> and example code to avoid messing up the meaning of the doc string.

I thought dedent just worked. Can you provide a simple example to help 
me understand this problem?

Does this help:
http://code.activestate.com/recipes/358228-extend-textwraptextwrapper-to-handle-multiple-para/

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7913>
_______________________________________

From report at bugs.python.org  Sat Mar 27 20:48:22 2010
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 27 Mar 2010 19:48:22 +0000
Subject: [issue8235] Support FreeBSD's SO_SETFIB in socketmodule.c
In-Reply-To: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>
Message-ID: <1269719302.32.0.354911543583.issue8235@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Kyle asked me to look at this; I think it looks ready for checkin, so unless someone else jumps in with something to say I'll check it in in a day or two.  It's not going in to 2.6 however, just 2.7 trunk and probably 3.2.

----------
nosy: +larry
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8235>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:09:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 27 Mar 2010 22:09:57 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269727797.05.0.79940547398.issue1220212@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So, Michael, what do you think: should os.kill expect a process handle, or a process ID?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:18:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Mar 2010 22:18:33 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269728313.59.0.816404574497.issue1220212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmm... well my particular use case is that it should work with the value returned by os.getpid(). If that is a process handle then it is nice and convenient to just use process handles. The docs don't specify so I bet it returns a pid. :-(

However Brian Curtin might want to weigh in on this as he has been looking at implementing this and there might be constraints.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sat Mar 27 23:50:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 27 Mar 2010 22:50:30 +0000
Subject: [issue8246] test_signal in test_subprocess displays traceback
In-Reply-To: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>
Message-ID: <1269730230.39.0.153763212855.issue8246@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Merged in 3.x with r79473

----------
assignee: gregory.p.smith -> flox
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8246>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:06:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 00:06:57 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1269734817.35.0.351765198615.issue5094@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:36:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 00:36:51 +0000
Subject: [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269736611.09.0.596121751322.issue8207@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed on trunk with r79426 and on 3.x with r79474

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8207>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:45:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 00:45:41 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1269737141.53.0.159869787154.issue4758@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:51:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 00:51:01 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1269737461.67.0.214945231754.issue7900@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sun Mar 28 01:51:38 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Mar 2010 00:51:38 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1269737498.26.0.258705648983.issue7900@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I have a consistently failing test on my machine. If the answer is indeed "won't fix" and both os.getgroups() and os.setgroups() are not expected to work correctly on Mac OS X then the tests should be disabled for that platform.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sun Mar 28 03:03:46 2010
From: report at bugs.python.org (Scott Tsai)
Date: Sun, 28 Mar 2010 01:03:46 +0000
Subject: [issue8032] Add gdb7 hooks to make it easier to debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1269738226.35.0.473432853592.issue8032@psf.upfronthosting.co.za>


Changes by Scott Tsai <scottt.tw at gmail.com>:


----------
nosy: +scott.tsai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8032>
_______________________________________

From report at bugs.python.org  Sun Mar 28 03:52:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 28 Mar 2010 01:52:54 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1269741174.49.0.133693757676.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I have this working with process IDs and my vote would be to keep it that way, as it would stay in-line with the other platforms, and it seems to work so far. I would imagine that was also IronPython's goal.

I'm still working on the test portion of the patch. It should be ready shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Sun Mar 28 03:59:29 2010
From: report at bugs.python.org (Matt B)
Date: Sun, 28 Mar 2010 01:59:29 +0000
Subject: [issue8247] Can't Import Tkinter
In-Reply-To: <1269741569.3.0.106756150038.issue8247@psf.upfronthosting.co.za>
Message-ID: <1269741569.3.0.106756150038.issue8247@psf.upfronthosting.co.za>


New submission from Matt B <mattcbro at earthlink.net>:

>>> import _tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: %1 is not a valid Win32 application.

I 'upgraded' to python 2.6.5 by downloading the windows 64 bit installer.  I'm running windows 7 64 bit.  Everything worked great in 2.6.4 by the way.  I had a similar problem with numpy,  but reinstalling it from this site seemed to fix it:
http://www.lfd.uci.edu/~gohlke/pythonlibs/

I can only speculate what happened.  If I knew what DLL failed to load I could easily check to see if there were dependency issues or 64/32 bit issues.  Perhaps the old dll is still around? If so then there is an issue with the installer I think.

No doubt the issues extends beyond just Tkinter.

----------
components: Tkinter
messages: 101852
nosy: SevenThunders
severity: normal
status: open
title: Can't Import Tkinter
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8247>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:03:13 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Sun, 28 Mar 2010 03:03:13 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

These patches add these new test cases to test_bool.py.

Python 2+3:
- Conversion to float
- Conversion to Decimal
- Calling bool() of built-in types

Python 2 only:
- __index__()
- Conversion to long
- sprintf formatting

NOTE: I'm currently helping Dino Viehland port IronPython tests into CPython. This is the first of that series.

----------
components: Tests
files: test_bool.v2.patch
keywords: patch
messages: 101853
nosy: dino.viehland, gnofi
severity: normal
status: open
title: Add test cases for bool
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16677/test_bool.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Sun Mar 28 05:04:37 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Sun, 28 Mar 2010 03:04:37 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269745477.89.0.771935830579.issue8248@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file16678/test_bool.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Sun Mar 28 06:30:25 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 28 Mar 2010 04:30:25 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269750625.11.0.350240090444.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16663/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Mar 28 06:32:26 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 28 Mar 2010 04:32:26 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269750746.52.0.437326835141.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I update bfs.patch. It now builds on Windows (and Posix).

----------
Added file: http://bugs.python.org/file16679/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Mar 28 07:56:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Mar 2010 05:56:34 +0000
Subject: [issue8247] Can't Import Tkinter
In-Reply-To: <1269741569.3.0.106756150038.issue8247@psf.upfronthosting.co.za>
Message-ID: <1269755794.25.0.168720576087.issue8247@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please check the event log?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8247>
_______________________________________

From report at bugs.python.org  Sun Mar 28 07:58:08 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 28 Mar 2010 05:58:08 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269755888.46.0.484291993497.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16679/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Mar 28 07:58:40 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 28 Mar 2010 05:58:40 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269755920.1.0.730436502496.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Added file: http://bugs.python.org/file16680/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Mar 28 10:26:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 08:26:46 +0000
Subject: [issue8249] expat.ParserCreate - SystemError bad argument to internal
	function
In-Reply-To: <1269764806.84.0.114625164995.issue8249@psf.upfronthosting.co.za>
Message-ID: <1269764806.84.0.114625164995.issue8249@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

First call gave a segfault. Following calls were successful.

Python 2.7a4+ (trunk:79443M, Mar 26 2010, 16:46:11)

~ $ python ../svnmerge.py -F -M merge -r79450,79427,79426,79425,79382,79310,79297
Traceback (most recent call last):
  File "../svnmerge.py", line 2366, in <module>
    main(sys.argv[1:])
  File "../svnmerge.py", line 2361, in main
    cmd(branch_dir, branch_props)
  File "../svnmerge.py", line 1813, in __call__
    return self.func(*args, **kwargs)
  File "../svnmerge.py", line 1483, in action_merge
    should_find_reflected(branch_dir))
  File "../svnmerge.py", line 1263, in analyze_source_revs
    return analyze_revs(branch_pathid, source_url, base, end_rev, **kwargs)
  File "../svnmerge.py", line 1215, in analyze_revs
    logs[url] = RevisionLog(url, begin, end, find_reflected)
  File "../svnmerge.py", line 535, in __init__
    split_lines=False)):
  File "../svnmerge.py", line 1034, in __getitem__
    for event, node in self._events:
  File "/opt/lib/python2.7/xml/dom/pulldom.py", line 232, in next
    rc = self.getEvent()
  File "/opt/lib/python2.7/xml/dom/pulldom.py", line 265, in getEvent
    self.parser.feed(buf)
  File "/opt/lib/python2.7/xml/sax/expatreader.py", line 198, in feed
    self.reset()
  File "/opt/lib/python2.7/xml/sax/expatreader.py", line 247, in reset
    intern=self._interning)
SystemError: Objects/methodobject.c:120: bad argument to internal function
Segmentation fault

----------
components: Extension Modules, XML
messages: 101856
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: expat.ParserCreate - SystemError bad argument to internal function
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8249>
_______________________________________

From report at bugs.python.org  Sun Mar 28 10:31:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 08:31:12 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1269765072.27.0.931836732851.issue6906@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ported to 2.6 with r79336

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:16:06 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 11:16:06 +0000
Subject: [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269774966.39.0.538919761435.issue8190@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:16:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 11:16:17 +0000
Subject: [issue8250] Implement pkgutil APIs as described in PEP 376
Message-ID: <1269774977.39.0.584076815206.issue8250@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: tarek
components: Distutils2
nosy: tarek
priority: normal
severity: normal
status: open
title: Implement pkgutil APIs as described in PEP 376
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8250>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:27:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Mar 2010 11:27:39 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1269775659.19.0.511344867083.issue7279@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, this looks great, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Sun Mar 28 13:39:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Mar 2010 11:39:05 +0000
Subject: [issue8251] WeakRefSet
In-Reply-To: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>
Message-ID: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

WeakRefSet would be a useful addition to the weakref module. I needed this for unittest recently but made do with a WeakRefKeyDictionary and setting the values to 1.

----------
components: Library (Lib)
messages: 101859
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: WeakRefSet
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8251>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:28:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:28:36 +0000
Subject: [issue8252] add a metada section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

let's add a metatadata section in setup.cfg, to express all the metadata fields instead of using setup.py options.

----------
assignee: tarek
components: Distutils2
messages: 101860
nosy: tarek
priority: normal
severity: normal
status: open
title: add a metada section in setup.cfg
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:34:16 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:34:16 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Implement the [resources] section described in:

http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst

We also need to add a description of packages, scripts and modules.
The result should be that projects will not need a setup.py file anymore

----------
assignee: tarek
components: Distutils2
messages: 101861
nosy: tarek
priority: normal
severity: normal
status: open
title: add a resource+files section in setup.cfg
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:35:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:35:01 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269786901.32.0.541525955304.issue8252@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: add a metada section in setup.cfg -> add a metadata section in setup.cfg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:36:09 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:36:09 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269786969.43.0.495813444904.issue8252@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

and change the mkpkg script accordingly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:36:27 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:36:27 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269786987.37.0.400945703682.issue8253@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

and change the mkpkg script accordingly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:41:24 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:41:24 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This command will contain all options that are used to build extensions (out of the build* and install* commands) and will create a confifuration file.

build* and install* commands will be able to read back the file if present, and use its values, so we don't have to pass the options again.

See 4Suite configure command for an example

----------
assignee: tarek
components: Distutils2
messages: 101864
nosy: tarek
priority: normal
severity: normal
status: open
title: write a configure command
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:44:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 14:44:05 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269787445.4.0.0285754461621.issue8252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:44:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 14:44:20 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269787460.83.0.53998312061.issue8253@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:45:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 14:45:07 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1269787507.75.0.56988044582.issue8254@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:47:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:47:17 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Write a tutorial to describe the cycle of a Python project that is built, released and deployed, using Distutils2. This project will need to be complete enough to cover most use cases.

This tutorial will be part of the Distutils2 documentation and will be also added in the hitchhicker guide.

----------
assignee: tarek
components: Distutils2
messages: 101865
nosy: tarek
priority: normal
severity: normal
status: open
title: step-by-step tutorial
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Sun Mar 28 16:49:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 14:49:03 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1269787743.62.0.313204651967.issue8255@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Sun Mar 28 17:15:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 15:15:24 +0000
Subject: [issue8250] Implement pkgutil APIs as described in PEP 376
Message-ID: <1269789324.43.0.232213102307.issue8250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8250>
_______________________________________

From report at bugs.python.org  Sun Mar 28 17:52:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 15:52:04 +0000
Subject: [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269791524.77.0.87400927501.issue8190@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

XML-RPC is a legacy protocol that works against the Web, i.e. it does not respect and benefit from the Web architecture. Why not going the REST way?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:02:50 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 28 Mar 2010 16:02:50 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1269792170.42.0.591622207427.issue7559@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I was also hit by this today.

For the sake of clarity, I will restate two of the scenarios that have been mentioned in this discussion:

(1) An ImportError raised whilst importing a module (original issue)
(2) A sub-module not existing.

I think the error text should be better in both cases and not just in case (1).

Currently, both (1) and (2) yield an error like the following:

AttributeError: 'module' object has no attribute 'subpackage1'

But also in case (2), the AttributeError reveals less information than the exception that was trapped earlier:

ImportError: No module named subpackage1.subpackage2

I think in both cases the error text should state not just what module was being imported but also what module was being imported from -- e.g. root_package.subpackage1.subpackage2.  In other words, it should also include the leading parts of--

'.'.join(parts_copy)  

In my case, I passed a list of modules to unittest, and it wasn't clear which one it was failing on by looking at only the trailing segment.  Thanks.

----------
nosy: +cjerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Sun Mar 28 18:54:10 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 28 Mar 2010 16:54:10 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1269795250.93.0.451796516204.issue7946@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun Mar 28 19:16:07 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Mar 2010 17:16:07 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1269796567.35.0.577791948141.issue6488@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I agree. I found the documentation very difficult to understand.  The term "top-level" can be confusing. Consider instead something like "search the entire tree".

A few other comments about the documentation of findtext:

findtext(path[, default])
    ... Returns the text content of the first matching element, or the default value no element was found...

The first comma (,) following 'element' is unnecessary and in fact incorrect. Also, 'if' is missing. Sentence should read "Returns the text content of the first matching element or the default value if no element was found."

findtext(path[, default])
    ... Note that if the element has is found, but has no text content, this method returns an empty string.

Again, an unnecessary comma exist and there's an extra word. Should read, "Note that if the element is found but has no text content, this method returns an empty string."

Note, the wording changes should be made. The other suggestions should be considered soft suggestions and merely my preference.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Sun Mar 28 19:26:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 17:26:05 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1269797165.49.0.25486439163.issue6488@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As per PEP 257, ?Returns? should become ?Return? (it?s a command, not a description).

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:09:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 18:09:12 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1269799752.57.0.145129590333.issue6488@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +XML
stage:  -> needs patch
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:09:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 18:09:47 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1269799787.05.0.00491973410083.issue6488@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:52:13 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 18:52:13 +0000
Subject: [issue8250] Implement pkgutil APIs as described in PEP 376
Message-ID: <1269802333.36.0.437561839799.issue8250@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8250>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:52:36 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 18:52:36 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269802356.54.0.506658862527.issue8252@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:52:59 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 18:52:59 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269802379.14.0.267252727886.issue8253@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:53:19 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 18:53:19 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1269802399.3.0.484846716442.issue8254@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:53:38 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 28 Mar 2010 18:53:38 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1269802418.62.0.626819202758.issue8255@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Sun Mar 28 20:59:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 18:59:10 +0000
Subject: [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269802750.5.0.900846864594.issue8190@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

We want to add a PyPI client in Distutils2, and PyPI provides these information via XML-RPC.

PyPI could probably have a REST interface to grab these info as well, but this is another topic/project.

On our side (distutils2), we want to provide a nice set of APIs to get some info PyPI has, and the fact that it's via XML-RPC is an implementation detail: if PyPI switch to something else, this should just impact the internals of the client, and not change our APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 21:34:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 19:34:01 +0000
Subject: [issue8190] Add a PyPI client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269804841.09.0.389687380043.issue8190@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for clarifying. I?m rephrasing the title to minimize the presence of the protocol used as implementation detail.

Regards

----------
title: Add an xml-rpc client for PyPi -> Add a PyPI client module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 21:36:29 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 19:36:29 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269804989.9.0.500134209296.issue8190@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please don't. This is confusing because some commands already interact with PyPI (upload/register).

I don't see the problem in mentioning XML-RPC in the title here. It makes what we need to do crystal clear.

----------
title: Add a PyPI client module -> Add a PyPI XML-RPC client module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 21:39:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Mar 2010 19:39:59 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269804989.9.0.500134209296.issue8190@psf.upfronthosting.co.za>
Message-ID: <4BAFB08C.7080301@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

You?re right, sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Sun Mar 28 22:15:16 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sun, 28 Mar 2010 20:15:16 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

I'm getting a "TypeError: bad argument type for built-in operation" on a print() with no arguments.  This seems to be a problem in both 3.1 and 3.1.2 (haven't tried 3.1.1).

I've narrowed the problem down in a very small demo program that you can run to reproduce the bug.  Just do "python3.1 bug.py" and hit <ENTER> at the "prompt:".

Removing the doctest call (and calling "foo" directly) doesn't get the error.  Also removing the "input" call (and leaving the doctest call in) doesn't get the error.

The startup banner on my python3.1 is:
Python 3.1.2 (r312:79147, Mar 26 2010, 16:55:44) 
[GCC 4.3.3] on linux2

I compiled python 3.1.2 with ./configure, make, make altinstall without any options.  I'm running ubuntu 9.04 with the 2.6.28-18-generic (32-bit) kernel.

----------
components: IO, Interpreter Core, Library (Lib)
files: bug.py
messages: 101874
nosy: dangyogi
severity: normal
status: open
title: TypeError: bad argument type for built-in operation
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16681/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Sun Mar 28 22:20:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Mar 2010 20:20:44 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269807644.56.0.959715251294.issue8248@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Sun Mar 28 23:59:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Mar 2010 21:59:18 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269813558.89.0.0870434083026.issue8252@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:14:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Mar 2010 22:14:22 +0000
Subject: [issue6488] ElementTree documentation refers to "path" with no
	explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1269814462.35.0.721553480167.issue6488@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think you are incorrect about the comma after element.  Without the comma 'the first matching element or the default value' are tightly bound, meaning that if either of those is true, then the default value is returned.  That's obviously incorrect, so a human will parse the sentence the way you expect.  But I think technically the comma after element turns the sentence into two independent clauses conjoined by 'or', so that either the first matching element is returned, or the default is returned (if no element was found).  I think it also reads better rhythmically (you will note that I used a comma in my sentence, as well, even though in that case no technical ambiguity results from leaving it out).

The comma in the other sentence I think is optional, and I agree that it reads better without it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:46:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 22:46:03 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269816363.4.0.305261205329.issue8256@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Confirmed.

There's something wrong around the doctest._SpoofOut class.
This script triggers the same bug (both 3.x and 3.1).


Output:

$ ./python issue8256_case.py 
prompt:
Traceback (most recent call last):
  File "issue8256_case.py", line 13, in <module>
    foo()
  File "issue8256_case.py", line 7, in foo
    print()
TypeError: bad argument type for built-in operation

----------
components:  -Interpreter Core
nosy: +flox
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2
Added file: http://bugs.python.org/file16682/issue8256_case.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:55:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Mar 2010 22:55:52 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269816952.38.0.396518108226.issue8248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Decimal tests should probably be in test_decimal, not test_bool.
Also, I'm not sure why the __index__ and format tests aren't in the py3k patch.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:57:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Mar 2010 22:57:31 +0000
Subject: [issue8251] WeakRefSet
In-Reply-To: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>
Message-ID: <1269817051.42.0.993527530277.issue8251@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Python 3.2a0 (py3k:79464, Mar 27 2010, 19:18:14) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from weakref import WeakSet
>>>

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8251>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:59:12 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 28 Mar 2010 22:59:12 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269817152.03.0.0757620123292.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

The bug is triggered by input, not by print. The exact place is _PyUnicode_AsStringAndSize, where unicode check happens. Then print checks PyError_Occured and catches this error. Either this error should not be raised or should be cleared input finishes.

I'd love to provide a patch, but I have no idea, what should be corrected and how. If some would tutor me a little, I would be very happy to learn and code this.

----------
nosy: +gruszczy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 00:59:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 22:59:36 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269817176.89.0.412446322335.issue8256@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16682/issue8256_case.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:01:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 23:01:54 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269817314.37.0.417129984567.issue8256@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Right. It does not involve doctest.

#
import io, sys

original_stdout = sys.stdout

try:
    sys.stdout = io.StringIO()
    input("prompt:")
    print()
finally:
    sys.stdout = original_stdout

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:09:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Mar 2010 23:09:43 +0000
Subject: [issue8251] WeakRefSet
In-Reply-To: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>
Message-ID: <1269817783.9.0.45176859538.issue8251@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ha. I tried 2.7. I guess it would be nice if it was backported.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8251>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:12:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Mar 2010 23:12:21 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Per discussion on python-dev, let Decimal(x) accept floats as a possible input, making Decimal.from_float unnecessary.

See attached patch.

----------
assignee: mark.dickinson
files: deci_float_constructor.diff
keywords: easy, patch
messages: 101882
nosy: mark.dickinson, rhettinger
severity: normal
stage: patch review
status: open
title: Decimal constructor to accept float
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16683/deci_float_constructor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8257>
_______________________________________

From report at bugs.python.org  Mon Mar 29 01:14:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Mar 2010 23:14:12 +0000
Subject: [issue8251] WeakRefSet
In-Reply-To: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>
Message-ID: <1269818052.04.0.652385639195.issue8251@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8251>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:05:31 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 29 Mar 2010 01:05:31 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269824731.69.0.387524252175.issue8248@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

Indeed, the Decimal test is better off in test_decimal.DecimalExplicitConstructionTest so I moved it there.

I forgot to include the index test for the py3k patch. That's in the updated patch, too.

There is already a format test in the py3k branch.

----------
Added file: http://bugs.python.org/file16684/test_bool.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Mon Mar 29 03:06:53 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 29 Mar 2010 01:06:53 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269824813.45.0.554496991049.issue8248@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file16685/test_bool.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Mon Mar 29 05:34:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Mar 2010 03:34:45 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269833685.08.0.862843013595.issue8218@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a patch that fixes the typos found by David and Yuv and rephrases a couple of parts.

----------
keywords: +easy, needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16686/issue8218.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Mon Mar 29 07:54:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 29 Mar 2010 05:54:03 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1269842043.47.0.220196436777.issue8257@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8257>
_______________________________________

From report at bugs.python.org  Mon Mar 29 10:20:55 2010
From: report at bugs.python.org (Torsten Bronger)
Date: Mon, 29 Mar 2010 08:20:55 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1269850855.77.0.80874359445.issue1596321@psf.upfronthosting.co.za>


Changes by Torsten Bronger <bronger at physik.rwth-aachen.de>:


----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Mon Mar 29 12:08:13 2010
From: report at bugs.python.org (William)
Date: Mon, 29 Mar 2010 10:08:13 +0000
Subject: [issue8258] Multiple Python Interpreter Memory Leak
In-Reply-To: <1269857293.22.0.576084159776.issue8258@psf.upfronthosting.co.za>
Message-ID: <1269857293.22.0.576084159776.issue8258@psf.upfronthosting.co.za>


New submission from William <william.lewis at mastek.com>:

Context:
I am embedding Python into a Windows based C++ application, where a new Python interpreter (using Py_NewInterpreter) is created for each user who connects to the system. When the user logs off, the function "Py_EndInterpreter" is used to free all the associated resources.

Problem:
After starting the application on a server, the memory usage increases rapidly as some users login and log-off from the system.

Some Tests:
I have conducted some tests along with the Python interpreter. I have written a simple C++ program which simply creates 100 Python interpreters and then ends them one by one. If we check the Windows Task Manager, the following are the observations:-

Memory usage before starting to create the Python Interpreters: 4316K
Memory usage after creating 100 Python Interpreters: 61248K
Memory usage after ending the 100 Python Interpreters: 47664K

This shows that there has been a memory leak of approximately 43348K

Please do consider this problem for fixing at the earliest or let me know if I am doing something wrong.

----------
components: Interpreter Core, Windows
files: PythonCall.cpp
messages: 101885
nosy: ewillie007
severity: normal
status: open
title: Multiple Python Interpreter Memory Leak
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file16687/PythonCall.cpp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8258>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:21:01 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 29 Mar 2010 12:21:01 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269865261.22.0.152270090487.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

The problem occurs in line in bltinmodule.c:

		po = PyUnicode_AsEncodedString(stringpo,
			_PyUnicode_AsString(stdout_encoding), NULL);

Where _PyUnicode_AsString returns NULL, since stdout_encoding is Py_None and that won't pass PyUnicode_Check in _PyUnicode_AsStringAndSize. To what object can _PyUnicode_AsString be turned and then passed to _PyUnicode_AsStringAndSize? Is there some default 'utf-8' encoding object?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 14:29:22 2010
From: report at bugs.python.org (owirj)
Date: Mon, 29 Mar 2010 12:29:22 +0000
Subject: [issue8259] left shift operator doesn't accepts long as second
	argument
In-Reply-To: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>
Message-ID: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>


New submission from owirj <cemu at mail.ru>:

python -V:
Python 2.6.5

Executing on 32-bit machine.

>From documentation ( http://docs.python.org/reference/expressions.html ), "5.7. Shifting operations":
"These operators accept plain or long integers as arguments. The arguments are converted to a common type. They shift the first argument to the left or right by the number of bits given by the second argument."

In interpreter:
>>> x = 2677691728509L << 2147483648L
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

hint: 2147483648 = (1 << 31)

First argument is long, second is long too, so expected behavior was normal execution. But as seen from the code above interpreter gives overflow error. Looks like he tries to convert second argument to int type, because this code works gracefully:
>>> x = 2677691728509L << 2147483647L

----------
components: None
messages: 101887
nosy: owirj
severity: normal
status: open
title: left shift operator doesn't accepts long as second argument
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8259>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:05:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Mar 2010 13:05:36 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269867936.98.0.849764286159.issue8256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Whatever the solution to this issue is, it certainly looks like a bug that the return value of that function isn't being checked for errors.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 15:13:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Mar 2010 13:13:08 +0000
Subject: [issue8259] left shift operator doesn't accepts long as second
	argument
In-Reply-To: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>
Message-ID: <1269868388.89.0.157032997381.issue8259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This appears to be working as designed, and so is probably a doc issue.  Python 3, which only has one integer type, has the same behavior:

>>> x = 2677691728509 << 2147483648
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

Adding Mark Dickinson as nosy to get his opinion on whether this is a doc bug or a feature request :)

----------
components: +Interpreter Core -None
nosy: +mark.dickinson, r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8259>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:50:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Mar 2010 14:50:44 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1269874244.56.0.156282180376.issue1596321@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the fix to Christian's issue is just:

Index: Lib/threading.py
===================================================================
--- Lib/threading.py	(r?vision 79470)
+++ Lib/threading.py	(copie de travail)
@@ -579,7 +579,7 @@
                 try:
                     # We don't call self.__delete() because it also
                     # grabs _active_limbo_lock.
-                    del _active[_get_ident()]
+                    del _active[self.__ident]
                 except:
                     pass
 
@@ -615,7 +615,7 @@
 
         try:
             with _active_limbo_lock:
-                del _active[_get_ident()]
+                del _active[self.__ident]
                 # There must not be any python code between the previous line
                 # and after the lock is released.  Otherwise a tracing function
                 # could try to acquire the lock again in the same thread, (in


Now we just need to add a test for it in test_threading.
And, yes, Amaury's test case looks like a different issue.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Mon Mar 29 16:55:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Mar 2010 14:55:30 +0000
Subject: [issue8259] left shift operator doesn't accepts long as second
	argument
In-Reply-To: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>
Message-ID: <1269874530.07.0.400428066256.issue8259@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I get another error on a 64-bit build:

>>> x = 2677691728509L << 2147483648L
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: outrageous left shift count

(yes, Python is outraged by such a large amount of left shifting)

The reason you get an OverflowError in 32-bit mode is that 2**31 is too large to be represented as a (signed) C long, rather than unsigned.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8259>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:09:56 2010
From: report at bugs.python.org (harobed)
Date: Mon, 29 Mar 2010 15:09:56 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

This is an example, last assert return an error :

f = open('data.txt', 'w')
f.write("""line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
""")
f.close()


f = open('data.txt', 'r')
assert f.readline() == 'line 1\n'

assert f.read() == """line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

import codecs

f = codecs.open('data.txt', 'r', 'utf8')

assert f.read() == """line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

f = codecs.open('data.txt', 'r', 'utf8')

assert f.readline() == 'line 1\n'

# this assert return a ERROR
assert f.read() == """line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

Regards,
Stephane

----------
components: Library (Lib)
messages: 101892
nosy: harobed
severity: normal
status: open
title: When I use codecs.open(...) and f.readline() follow up by f.read() return bad result
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Mon Mar 29 17:26:26 2010
From: report at bugs.python.org (owirj)
Date: Mon, 29 Mar 2010 15:26:26 +0000
Subject: [issue8259] left shift operator doesn't accepts long as second
	argument
In-Reply-To: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>
Message-ID: <1269876386.34.0.448778319852.issue8259@psf.upfronthosting.co.za>


owirj <cemu at mail.ru> added the comment:

Antoine Pitrou:
The reason you get an OverflowError in 32-bit mode is that 2**31 is too large to be represented as a (signed) C long, rather than unsigned.

I understand that, but after reading documentation, was expecting it to convert second argument to long type, which is not concerned with architecture dependant implementation of int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8259>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:10:38 2010
From: report at bugs.python.org (Jason Mobarak)
Date: Mon, 29 Mar 2010 16:10:38 +0000
Subject: [issue8261] License link for Python 2.6.5 release is broken
In-Reply-To: <1269879038.0.0.542921448766.issue8261@psf.upfronthosting.co.za>
Message-ID: <1269879038.0.0.542921448766.issue8261@psf.upfronthosting.co.za>


New submission from Jason Mobarak <jmob at cs.unm.edu>:

The 'Python License' link at

http://www.python.org/download/releases/2.6.5/

results in a 404.

----------
assignee: georg.brandl
components: Documentation
messages: 101894
nosy: georg.brandl, silverjam
severity: normal
status: open
title: License link for Python 2.6.5 release is broken
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8261>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:24:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Mar 2010 16:24:56 +0000
Subject: [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269879896.69.0.431377344176.issue8218@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/framewors/frameworks/g

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:34:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Mar 2010 16:34:49 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269880489.14.0.0698025098762.issue8218@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The rest of the patch seems good to me. Note that ?the majority of users is? is as correct as ?the majority of users are?, choosing one is a matter of preference.

----------
title: typo currect -> Fix typos and phrasing in the Web servers howto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:42:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Mar 2010 16:42:53 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269880973.67.0.754876018383.issue8218@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

'is' may be technically correct, however it will sound wrong to a native speaker's ear, at least in America.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Mon Mar 29 18:57:05 2010
From: report at bugs.python.org (John Trammell)
Date: Mon, 29 Mar 2010 16:57:05 +0000
Subject: [issue1785] "inspect" gets broken by some descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1269881825.5.0.155687721401.issue1785@psf.upfronthosting.co.za>


Changes by John Trammell <johntrammell at gmail.com>:


----------
nosy: +jotr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:02:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Mar 2010 17:02:43 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1269882163.48.0.0179038000417.issue8257@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Will Decimal.from_float be deprecated and eventually removed?

Could you provide a link to said discussion thread for us outsiders? :)

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8257>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:33:31 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:33:31 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269884011.35.0.890321658145.issue8190@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:33:55 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:33:55 +0000
Subject: [issue8250] Implement pkgutil APIs as described in PEP 376
Message-ID: <1269884035.67.0.177162484986.issue8250@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8250>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:34:14 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:34:14 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269884054.8.0.61466488992.issue8252@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:34:28 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:34:28 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269884068.51.0.183570168864.issue8253@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:34:41 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:34:41 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1269884081.68.0.914738599835.issue8254@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:34:54 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Mon, 29 Mar 2010 17:34:54 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1269884094.23.0.596686670761.issue8255@psf.upfronthosting.co.za>


Changes by Zubin Mithra <zubin.mithra at gmail.com>:


----------
nosy: +zubin71

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8255>
_______________________________________

From report at bugs.python.org  Mon Mar 29 19:45:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Mar 2010 17:45:06 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1269884706.23.0.517655363109.issue8257@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

?ric, there is no place to deprecate Decimal.from_float().  It will be redundant but there is no need to break working code.  Also, it has the nice property of being explicit about what it is doing.


Link to my proposal:
  http://mail.python.org/pipermail/python-dev/2010-March/098699.html

Guido's "If you really want this I won't stop you":
  http://mail.python.org/pipermail/python-dev/2010-March/098701.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8257>
_______________________________________

From report at bugs.python.org  Mon Mar 29 21:21:45 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 29 Mar 2010 19:21:45 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269890505.2.0.0593471454528.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have written a small patch, that solves the problem, but is disgusting. Could anyone tell me, how I can get some default encoding from Python internals (I have no idea where to look) and return it inside _PyUnicode_AsStringAndSize? Anyway, now when the error happens inside input, it raises an Exception properly. So now I only need to know, how to correct the bug in an elegant fashion.

----------
keywords: +patch
Added file: http://bugs.python.org/file16688/8256_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 21:27:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Mar 2010 19:27:36 +0000
Subject: [issue8209] OptionParser keyword arg 'epilog' not mentioned in the
	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269890856.96.0.0011539973919.issue8209@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged into py3k in r79333 and release31-maint revision 79490.
This specific issue can be closed.
But yes, I agree with issue 8158, there is a lot in OptParse Module documentation that could be improved and be made more helpful. If I have any thing more, I shall add it as part of issue 8158.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8209>
_______________________________________

From report at bugs.python.org  Mon Mar 29 21:31:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Mar 2010 19:31:34 +0000
Subject: [issue8135] urllib.unquote doesn't decode mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1269891094.29.0.620635851621.issue8135@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged into release26-maint as r79492. This issue can be closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8135>
_______________________________________

From report at bugs.python.org  Mon Mar 29 21:36:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Mar 2010 19:36:39 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1269891399.46.0.290197943775.issue8158@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Mon Mar 29 22:32:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Mar 2010 20:32:08 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269894728.2.0.778189175823.issue8218@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It seems that a lot of non-native speakers (of English) are participating in this thread. By nature, this is something that native speakers should resolve. Unless I'm mistaken (and Ezio actually *does* speak English as a first language), I propose that one of the native speakers provide a patch (perhaps based on Ezio's patch), and that all non-native speakers abstain from commenting on what they believe is English grammar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Mon Mar 29 22:56:05 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 29 Mar 2010 20:56:05 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269896165.2.0.81559562433.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Ok, I have found Py_FileDefaultSystemEncoding and use it, however I had to cast it to (char *), because it's a const char *. Maybe I could do it better?

----------
Added file: http://bugs.python.org/file16689/8256_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:12:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Mar 2010 21:12:19 +0000
Subject: [issue8257] Decimal constructor to accept float
In-Reply-To: <1269884706.23.0.517655363109.issue8257@psf.upfronthosting.co.za>
Message-ID: <4BB117B1.4000208@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

(Assuming ?no place? means ?no reason?) Apart from TOOTDI, there is 
indeed none.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8257>
_______________________________________

From report at bugs.python.org  Mon Mar 29 23:17:24 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Mar 2010 21:17:24 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1269897444.27.0.457799041596.issue8203@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

idlelib_textView_encoding.patch fixes the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:21:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 29 Mar 2010 22:21:36 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269901296.71.0.755179068212.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Now that WeakSet has been backported to trunk, I've backported the fix for this reference-leak (patch with test case attached).

However, after making the patch, I discovered that old-style classes are not weak-referenceable.  Consequently, the patch is not suitable for commiting.  

If old-style classes can be made weak-referenceable, then the patch should work.  If not, then this bug is essentially impossible to solve in 2.x unless the ABC cache is done away with entirely.

Other notes:

Since abc.py is imported during bootstrapping before paths are set up, I needed to add _weakref as a built-in module.  (It's already a built-in module in the py3k branch.)

Since the patch tweaks Modules/Setup.dist, you need to "make distclean" and rerun ./configure after applying the patch.

Also, on unpatched trunk the example posted by Amaury no longer seems to trigger the issue.  However, the example I posted in Issue 8022 still triggers the leak.  I used that as the basis for the test case in the patch.

----------
keywords: +patch
nosy: +stutzbach
Added file: http://bugs.python.org/file16690/abc_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Tue Mar 30 00:28:14 2010
From: report at bugs.python.org (Valerio)
Date: Mon, 29 Mar 2010 22:28:14 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269901694.82.0.186349878429.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

I can pick up this bug.

----------
nosy: +valerio.turturici

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 01:09:06 2010
From: report at bugs.python.org (Valerio)
Date: Mon, 29 Mar 2010 23:09:06 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269904146.15.0.786243739112.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

I confirm that the bug still exists on trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 02:02:57 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 00:02:57 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269907377.97.0.874359001222.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

This is my first patch, i apologize if i make some mistakes.

----------
Added file: http://bugs.python.org/file16691/8193.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 03:08:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Mar 2010 01:08:45 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269911325.53.0.270258341924.issue8193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I imagine the problem exists in 3.x as well (unless someone proves otherwise), so I'm adjusting the versions to the places it can be fixed.

Does the patched test still work with the older zlib?

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:24:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 30 Mar 2010 02:24:44 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269915884.1.0.825225379135.issue8218@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I went through and made a lot of grammar corrections and rewording throughout the file. See attached patch.

I have no idea if this doc is technically correct. I only made grammar changes since I'm not a big web developer, but it could probably use a look from someone who is pretty knowledgeable on the topic.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file16692/issue8218_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:43:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Mar 2010 02:43:40 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269915884.1.0.825225379135.issue8218@psf.upfronthosting.co.za>
Message-ID: <4BB16559.5000502@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

I noticed that ?a user? is ?he? in the current text; gender-neutral 
language may be more in conformity with the recent diversity statement.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:46:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 30 Mar 2010 02:46:20 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269917180.15.0.000863581457147.issue8218@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16692/issue8218_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Tue Mar 30 04:48:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 30 Mar 2010 02:48:17 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269917297.9.0.291825503232.issue8218@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

My first patch removed a lot of the he/him/his wording, but now that you mentioned it found another one. Updated the patch.

----------
Added file: http://bugs.python.org/file16693/issue8218_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:24:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Mar 2010 04:24:08 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl (when run
	from buildout's python)
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269923048.92.0.354623985204.issue8236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python is used to build python.  Theoretically you should be able to avoid that rebuild. cf the following thread:

http://mail.python.org/pipermail/python-dev/2006-April/063511.html

and the referenced issue 1465408.  asdl_c.py is going to be importing asdl.py from the same directory it is run from (it is run as a script).  So the question is, why is your buildout python failing to support that import?

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:29:04 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 30 Mar 2010 04:29:04 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl (when run
	from buildout's python)
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269923344.22.0.813978679152.issue8236@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> why is your buildout python failing to support that import?

I believe it is because "" (current directory) is not in sys.path for buildout python. Buildout explicitly sets sys.path. Perhaps that's why.

Feel free to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Tue Mar 30 06:44:50 2010
From: report at bugs.python.org (Aditya Bhargava)
Date: Tue, 30 Mar 2010 04:44:50 +0000
Subject: [issue8218] Fix typos and phrasing in the Web servers howto
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269924290.44.0.317237819124.issue8218@psf.upfronthosting.co.za>


Aditya Bhargava <aditya at wefoundland.com> added the comment:

Another patch. This contains all the patches from Brian Curtin's issue8218_v3.diff patch along with more edits, including
an -> in
teh -> the
wordspushedtogether spaced out
unnecessary _a_ words _is_ taken out

----------
nosy: +abhargava
Added file: http://bugs.python.org/file16694/issue8218_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8218>
_______________________________________

From report at bugs.python.org  Tue Mar 30 07:09:42 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 30 Mar 2010 05:09:42 +0000
Subject: [issue8262] bad wording in error message attempting to start a Thread
	twice
In-Reply-To: <1269925782.78.0.466554273109.issue8262@psf.upfronthosting.co.za>
Message-ID: <1269925782.78.0.466554273109.issue8262@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Steve Holden, in <http://permalink.gmane.org/gmane.comp.python.general/658347>, about the RuntimeError you get when  a Thread object is started twice:

?"thread already started" implies that the thread is running, but you
actually get the same message if you try to start any terminated thread
(including a canceled one), so "threads cannot be restarted" might be a
better message. Or, better still, "Threads can only be started once".?

This patch fixes the wording as suggested.

----------
components: Library (Lib)
files: threading.diff
keywords: patch
messages: 101918
nosy: gagenellina
severity: normal
status: open
title: bad wording in error message attempting to start a Thread twice
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16695/threading.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8262>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:13:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Mar 2010 06:13:51 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1269929631.39.0.708255527435.issue3326@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a patch for configure.in and configure that implements Benjamin's suggestion.  The patch sets things up to continue to use -fno-strict-aliasing on gcc versions that support -fno-strict-aliasing *and* generate spurious warnings without it.  Effectively, that means it adds -fno-strict-aliasing for gcc versions < 4.3.

I tested it with gcc-3.4.4 and gcc-4.3.2.  It added -fno-strict-aliasing with gcc-3.4.4 and did not with gcc-4.3.2, as desired.  

With the gcc-4.3.2 build, I did a "make test" and no tests failed.  

I also found that pybench ran around 1% faster with the patch.

----------
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16696/strict-aliasing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Tue Mar 30 08:33:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Mar 2010 06:33:55 +0000
Subject: [issue8236] ./configure: ImportError: No module named asdl (when run
	from buildout's python)
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269930835.86.0.0971140861047.issue8236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That sounds like the likely explanation.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8236>
_______________________________________

From report at bugs.python.org  Tue Mar 30 09:13:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 30 Mar 2010 07:13:18 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1269933198.22.0.279999107789.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Meador: Your patch (-3) looks identical to mine (-2), unless I'm making some mistake. Could you check? I'd like to get this applied in the next few days, before 2.7b1.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:01:41 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 09:01:41 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269939701.35.0.427990666995.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

Now i make patches for other versions of Python. 
How i try if the patched test still work with the older zlib?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:10:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Mar 2010 09:10:32 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269940232.05.0.059681088919.issue8193@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm not sure simply changing the value is the right thing to do - with older zlib versions (which do the wrong thing with 0), we definitely want that exception to be triggered.

For newer versions, we want to check that passing in 0 worked as specified in the zlib patch note and that -1 still raises the exception.

Changing the test behaviour based on zlib.ZLIB_VERSION is likely the best option.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:24:06 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 09:24:06 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269941046.13.0.281101233707.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

Seems that from Python 2.6 to 3.2 the test work fine. With -1 still raises the exception. By the way, the original problem of Arkadiusz was with Python 2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 11:32:57 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 09:32:57 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269941577.39.0.965610379759.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

The original test, with 0, pass in all versions of Python, from 2.6 to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:16:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:16:15 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The regrtest returns "success", even if the test suite is not run completely.
The last running test is "test_unittest".


http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk/builds/171
...
51 tests OK.
2 tests skipped:
    test_ascii_formatd test_py3kwarn
1 skip unexpected on freebsd6:
    test_ascii_formatd
[294584 refs]
program finished with exit code 0
elapsedTime=1082.949696

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk/builds/168
...
37 tests OK.
5 tests skipped:
    test_bsddb185 test_macostools test_py3kwarn test_startfile
    test_winreg
1 skip unexpected on freebsd6:
    test_bsddb185
[184731 refs]
program finished with exit code 0
elapsedTime=507.756584

----------
components: Tests
keywords: buildbot
messages: 101926
nosy: flox, michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: regrtest stops prematurately on FreeBSD buildbot, with "success" result.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:51:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 30 Mar 2010 10:51:05 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269946265.17.0.706524474043.issue8263@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I wonder if unittest.test.test_break runs and the signals.SIGINT it sends terminates a process early? Do you have access to this platform to try it Florent?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:52:26 2010
From: report at bugs.python.org (Nick Craig-Wood)
Date: Tue, 30 Mar 2010 10:52:26 +0000
Subject: [issue8264] hasattr doensn't show private (double underscore)
	attributes exist
In-Reply-To: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>
Message-ID: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>


New submission from Nick Craig-Wood <nick at craig-wood.com>:

I just spend a while tracking down a bug in my code which turned out to be an unexpected behaviour of hasattr.

Running this

class Test(object):
    def __init__(self):
        self.__private = "Hello"
    def test(self):
        print(self.__private)
        print(hasattr(self, "__private"))
        print(getattr(self, "__private"))


t = Test()
t.test()

Prints

>>> t.test()
Hello
False
Traceback (most recent call last):
  File "private_test.py", line 10, in <module>
    t.test()
  File "private_test.py", line 7, in test
    print(getattr(self, "__private"))
AttributeError: 'Test' object has no attribute '__private'
>>>

Indicating that even though we just printed self.__private hasattr() can't find it nor getattr().

I think this is probably the intended behaviour, but it does seem inconsistent.

Probably all that is required is a documentation patch...

Maybe something add something like this to the end of

  http://docs.python.org/library/functions.html#hasattr

Note that hasattr won't find private (double underscore) attributes unless the mangled name is used.

----------
components: Interpreter Core
messages: 101928
nosy: ncw
severity: normal
status: open
title: hasattr doensn't show private (double underscore) attributes exist
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8264>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:52:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:52:46 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

All the ARM Linux EABI buildbots fail on the same test.

http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%202.6/builds/5

test_float
test test_float failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 665, in test_from_hex
    self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY)
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 375, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: 2.2250738585071999e-308 not identical to 2.2250738585071984e-308

----------
components: Interpreter Core
keywords: buildbot
messages: 101929
nosy: flox, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_float fails on ARM Linux EABI
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:53:02 2010
From: report at bugs.python.org (Neil Muller)
Date: Tue, 30 Mar 2010 10:53:02 +0000
Subject: [issue3409] ElementPath.Path.findall problem with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1269946382.33.0.987570348205.issue3409@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

With the recent ElementTree changes on trunk, this bug no longer applies, AFAICS.

----------
nosy: +Neil Muller, flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:56:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:56:00 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1269946560.27.0.274018900766.issue8265@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Same failure on trunk:
http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%20trunk/builds/12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Tue Mar 30 12:58:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:58:11 +0000
Subject: [issue3409] ElementPath.Path.findall problem with unicode input
In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za>
Message-ID: <1269946691.37.0.79155394626.issue3409@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3409>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:22:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Mar 2010 11:22:37 +0000
Subject: [issue8264] hasattr doensn't show private (double underscore)
	attributes exist
In-Reply-To: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>
Message-ID: <1269948157.69.0.541442681489.issue8264@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct, this is the expected behavior.  Name mangling happens only at compilation time (see http://docs.python.org/reference/expressions.html#atom-identifiers).  A doc note for get/setattr would probably be useful.

(I removed 3.3; that version doesn't exist yet and should only be set on issues that can only be dealt with in 3.3, such as removing something deprecated in 3.2.)

----------
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
nosy: +georg.brandl, r.david.murray
priority:  -> normal
stage:  -> needs patch
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8264>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:32:11 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 11:32:11 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269948731.82.0.542699964385.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

I try again and ValueError not raised. The test pass without problem, both Python 2.6 and next.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:33:17 2010
From: report at bugs.python.org (Valerio)
Date: Tue, 30 Mar 2010 11:33:17 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269948797.75.0.675309379007.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

P.S: the value it's default, 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Tue Mar 30 13:38:51 2010
From: report at bugs.python.org (Neil Muller)
Date: Tue, 30 Mar 2010 11:38:51 +0000
Subject: [issue1028432] Specify a source baseurl for bdist_rpm.
Message-ID: <1269949131.54.0.142507291011.issue1028432@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

> Is it preferable to specify a URL for the "Source"
> field in a .spec file (rather than just a filename)?

Fedora (see for example http://fedoraproject.org/wiki/Packaging/SourceURL ) encourages using a full url when available, so having some way of specifying the url looks like a useful addition to me.

----------
nosy: +Neil Muller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028432>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:44:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 12:44:49 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269953089.48.0.19433620201.issue8263@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Sorry, but I don't have such environment.

Proposed patch will add a notice if the regrtest is interrupted (Ctrl+C).
And the exitcode is set to 1, meaning test failed for the buildbot.

----------
keywords: +patch
Added file: http://bugs.python.org/file16697/issue8263_regtest_SIGINT.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 14:50:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 30 Mar 2010 12:50:59 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269953459.26.0.248540784837.issue8263@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

That sounds very useful from a diagnostic point of view. If it does turn out to be the problem then we will have to disable the test for that platform. At the moment test_break runs on all platforms that have os.kill(...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:38:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 13:38:24 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269956304.57.0.222167975234.issue8263@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16697/issue8263_regtest_SIGINT.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 15:39:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 13:39:28 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269956368.96.0.267763881478.issue8263@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Slightly different, with a count of omitted tests
And removed "All .. tests OK" is there's some tests omitted.

----------
Added file: http://bugs.python.org/file16698/issue8263_regtest_SIGINT_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:34:13 2010
From: report at bugs.python.org (tdjacr)
Date: Tue, 30 Mar 2010 14:34:13 +0000
Subject: [issue8266] tarfile library should support xz compression
Message-ID: <1269959653.86.0.383069027285.issue8266@psf.upfronthosting.co.za>


Changes by tdjacr <tdjacr.foss at gmail.com>:


----------
nosy: thedjatclubrock
severity: normal
status: open
title: tarfile library should support xz compression
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8266>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:35:22 2010
From: report at bugs.python.org (tdjacr)
Date: Tue, 30 Mar 2010 14:35:22 +0000
Subject: [issue8266] tarfile library should support xz compression
In-Reply-To: <1269959722.11.0.848606343601.issue8266@psf.upfronthosting.co.za>
Message-ID: <1269959722.11.0.848606343601.issue8266@psf.upfronthosting.co.za>


New submission from tdjacr <tdjacr.foss at gmail.com>:

See http://bugs.python.org/issue6715 for more info regarding support of .xz in general

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8266>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:38:30 2010
From: report at bugs.python.org (tdjacr)
Date: Tue, 30 Mar 2010 14:38:30 +0000
Subject: [issue8266] tarfile library should support xz compression
In-Reply-To: <1269959722.11.0.848606343601.issue8266@psf.upfronthosting.co.za>
Message-ID: <1269959910.85.0.97554594262.issue8266@psf.upfronthosting.co.za>


tdjacr <tdjacr.foss at gmail.com> added the comment:

https://launchpad.net/pyliblzma may help?

----------
components: +Library (Lib)
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8266>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:41:20 2010
From: report at bugs.python.org (tdjacr)
Date: Tue, 30 Mar 2010 14:41:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1269960080.12.0.250609914635.issue6715@psf.upfronthosting.co.za>


tdjacr <tdjacr.foss at gmail.com> added the comment:

Once xz is implemented, xz compatibility should be added to the tarfile library.

----------
nosy: +thedjatclubrock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Mar 30 16:44:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 30 Mar 2010 14:44:03 +0000
Subject: [issue8266] tarfile library should support xz compression
In-Reply-To: <1269959722.11.0.848606343601.issue8266@psf.upfronthosting.co.za>
Message-ID: <1269960243.15.0.436614935613.issue8266@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #5689.

----------
nosy: +brian.curtin
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8266>
_______________________________________

From report at bugs.python.org  Tue Mar 30 17:27:12 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 30 Mar 2010 15:27:12 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1269962832.06.0.983208922555.issue7994@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Hi Eric,

(-2) and (-3) are different.  The changes that I made, however, are pretty minor.  Also, they are all in 'test_builtin.py'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Tue Mar 30 18:43:21 2010
From: report at bugs.python.org (Cyril)
Date: Tue, 30 Mar 2010 16:43:21 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269967401.36.0.387374361347.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

> Hmm, indeed. What you can do, very simply, is cache the getvalue()
> result once you have generated it.

After some thoughts, it's not really an option: my cStringIO.StringIO buffer is, well a buffer. To append data to the buffer, I call buffer.write(). When I've got a chance to send data over the socket (remember, it's async, so I don't really know when it's going to happen), I call buffer.getvalue().

If socket.write() returns zero byte written, I'll have to wait until I get another chance to send my buffer. But in the meantime, some more data might get appended to the buffer, and the string returned by getvalue() will be different from the first call (and thus, I can't really cache it).

I could find some tricks (like using multiple buffers), but it would be ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Tue Mar 30 18:45:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Mar 2010 16:45:27 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1269967527.46.0.416697509436.issue7643@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Which functions are affected by this change?
Py_UNICODE_ISLINEBREAK()? unicode.splitlines()?

----------
assignee:  -> flox
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Tue Mar 30 18:46:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 16:46:48 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269967401.36.0.387374361347.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269967719.3440.37.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If socket.write() returns zero byte written, I'll have to wait until I
> get another chance to send my buffer. But in the meantime, some more
> data might get appended to the buffer, and the string returned by
> getvalue() will be different from the first call (and thus, I can't
> really cache it).
> 
> I could find some tricks (like using multiple buffers), but it would
> be ugly.

Right. I think we should somehow support your use case, but I'm not sure
whether it should be the default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Tue Mar 30 18:58:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 16:58:59 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269968339.99.0.891255063446.issue8263@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file16698/issue8263_regtest_SIGINT_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:00:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 17:00:35 +0000
Subject: [issue8263] regrtest stops prematurately on FreeBSD buildbot,
	with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269968435.48.0.883932013568.issue8263@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Regrtest.py fixed with r79497 to report keyboard interrupt as a "failure".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8263>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:05:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 17:05:57 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1269968757.57.0.0551593237655.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Committed to trunk: r79494 and r79496.

Afaict, it changes Py_UNICODE_ISLINEBREAK, _PyUnicode_IsLinebreak and the Unicode functions which depend on it (splitlines(), _sre module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:19:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Mar 2010 17:19:09 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1269969549.96.0.972703102688.issue8265@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Matthias, can you please take a look?

----------
nosy: +doko, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:35:09 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Mar 2010 17:35:09 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1269970509.76.0.4411481595.issue3326@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch. Applied in r79499.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:35:47 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 30 Mar 2010 17:35:47 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1269970547.22.0.548459600385.issue1553375@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


----------
nosy: +pakal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Tue Mar 30 19:59:45 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Mar 2010 17:59:45 +0000
Subject: [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1269971985.9.0.354758040769.issue3135@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r79500. Note I removed the error checking that a bound method received an instance of the class as the first argument because that error checking is a function of the calling of the function, not the binding of the arguments.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3135>
_______________________________________

From report at bugs.python.org  Tue Mar 30 21:01:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 19:01:01 +0000
Subject: [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269975661.76.0.428807762183.issue8248@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r79502, r79504 (trunk) and r79503 (py3k). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8248>
_______________________________________

From report at bugs.python.org  Tue Mar 30 21:18:53 2010
From: report at bugs.python.org (=?utf-8?q?Kent_Engstr=C3=B6m?=)
Date: Tue, 30 Mar 2010 19:18:53 +0000
Subject: [issue8267] Tutorial secion on dictionary keys recommends sort
	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>


New submission from Kent Engstr?m <kent at lysator.liu.se>:

The 2.[567] documentation recommends the use of the sort() method
to get a sorted list of dictionary keys. If would be less confusing
to new users if we recommended the sorted() functions instead.

The corresponding piece of Python 3 documentation already uses
the sorted() function.

----------
assignee: georg.brandl
components: Documentation
files: dict.patch
keywords: patch
messages: 101953
nosy: georg.brandl, kent
severity: normal
status: open
title: Tutorial secion on dictionary keys recommends sort instead of sorted
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16699/dict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8267>
_______________________________________

From report at bugs.python.org  Tue Mar 30 21:20:46 2010
From: report at bugs.python.org (=?utf-8?q?Kent_Engstr=C3=B6m?=)
Date: Tue, 30 Mar 2010 19:20:46 +0000
Subject: [issue8267] Tutorial section on dictionary keys recommends sort
	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1269976846.06.0.844069279194.issue8267@psf.upfronthosting.co.za>


Changes by Kent Engstr?m <kent at lysator.liu.se>:


----------
title: Tutorial secion on dictionary keys recommends sort instead of sorted -> Tutorial section on dictionary keys recommends sort instead of sorted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8267>
_______________________________________

From report at bugs.python.org  Tue Mar 30 22:14:31 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 30 Mar 2010 20:14:31 +0000
Subject: [issue8265] test_float fails on ARM Linux EABI with soft floating
	point
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1269980071.53.0.578875244778.issue8265@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the buildbot labeled "ARM Linux 3.x" is an ARM EABI as well, compiler defaults -march=armv7 -math=vfp -float-abi=softfp.

The failing test_float test is an ARM EABI, armv4, ARM mode, soft floating point. I never did see the test_float test suceed on this platform/configuration.

----------
title: test_float fails on ARM Linux EABI -> test_float fails on ARM Linux EABI with soft floating point

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Tue Mar 30 22:21:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 20:21:47 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1269980507.36.0.517282243521.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Ported to 3.x with r79506

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Tue Mar 30 22:35:33 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 30 Mar 2010 20:35:33 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269981333.69.0.452640295237.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I have read, that I shouldn't directly use Py_FileSystemDefaultEncoding and rather use PyUnicode_GetDefaultEncoding, so I have changed the code a little.

----------
Added file: http://bugs.python.org/file16700/8256_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Tue Mar 30 22:35:44 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 30 Mar 2010 20:35:44 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269981344.31.0.448114557093.issue8256@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


Removed file: http://bugs.python.org/file16688/8256_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Tue Mar 30 22:35:48 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 30 Mar 2010 20:35:48 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269981348.26.0.279877696415.issue8256@psf.upfronthosting.co.za>


Changes by Filip Gruszczy?ski <gruszczy at gmail.com>:


Removed file: http://bugs.python.org/file16689/8256_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:58:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 22:58:14 +0000
Subject: [issue8268] Make old-style classes weak referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

New-style classes are weak referenceable, but old-style classes are not.
For a proper implementation of ABC caches without any memory leaks (see issue2521), this limitation should be raised.

----------
components: Interpreter Core
messages: 101957
nosy: pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Make old-style classes weak referenceable
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8268>
_______________________________________

From report at bugs.python.org  Wed Mar 31 00:58:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 22:58:36 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269989916.87.0.598732435966.issue2521@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +Make old-style classes weak referenceable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:21:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 23:21:23 +0000
Subject: [issue8268] Make old-style classes weak referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1269991283.47.0.52618109414.issue8268@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16701/weakref-classobj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8268>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:22:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 23:22:17 +0000
Subject: [issue8268] Make old-style classes weak referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1269991337.88.0.704481118887.issue8268@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file16701/weakref-classobj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8268>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:22:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 23:22:24 +0000
Subject: [issue8268] Make old-style classes weak referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1269991344.77.0.291915468512.issue8268@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file16702/weakref-classobj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8268>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:26:57 2010
From: report at bugs.python.org (Arnaud Fontaine)
Date: Tue, 30 Mar 2010 23:26:57 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>


New submission from Arnaud Fontaine <arnau at debian.org>:

For example, PyUnicode_FromFormat() does not specify the return value but it does not seem to be only one. I only have a basic knowledge of Python C/API, so I am not sure whether it is meaningful.

----------
assignee: georg.brandl
components: Documentation
messages: 101959
nosy: arnau, georg.brandl
severity: normal
status: open
title: Missing return values for PyUnicode C/API functions
type: feature request
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:35:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 23:35:50 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269992150.87.0.595963997438.issue2521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, Benjamin pointed out that ABCs only support new-style classes, so old-style classes could be detected early instead of being added to the _abc_negative_cache.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:38:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 23:38:21 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269992301.95.0.379697735666.issue2521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, Daniel, your patch doesn't look right.
First, you shouldn't need all the sortedlist/sortedset hierarchy.
Second, len(gc.get_objects()) is a truly horrible way of checking the classes have been destroyed. Just take a weakref to the class before deleting it, and check that calling the weakref returns None.
(besides, we also have a refleak-detection run (regrtest -R) which can detect leaks even if you don't check them explicitly in your tests)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:48:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Mar 2010 23:48:14 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269992894.92.0.431603374148.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I hadn't realized that old style classes didn't support ABCs.  That certainly simplifies things!  I'm working on a new patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 01:58:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Mar 2010 23:58:08 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269993488.65.0.274776696901.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Are you sure the old-style classes don't support ABCs?

ABCTestCase.validate_isinstance in Lib/test/test_collection.py specifically tests that both new-style and old-style classes work, unless I'm reading it wrong.

(and those tests fail if I make ABCMeta.__instancecheck__ and ABCMeta.__subclasscheck__ always return False for old-style classes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:02:09 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 31 Mar 2010 00:02:09 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269993729.28.0.0898954980998.issue2521@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

In those cases, it's because __subclasscheck__ is overridden. You can't register a old-style class.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:06:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 31 Mar 2010 00:06:10 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269993970.65.0.287275928679.issue2521@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> ABCTestCase.validate_isinstance ... specifically tests that
> both new-style and old-style classes work...

I fixed some parts with issue #7624, and changeset r78800.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:06:38 2010
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Wed, 31 Mar 2010 00:06:38 +0000
Subject: [issue8270] Should socket.PF_PACKET be removed,
	in favor of socket.AF_PACKET?
In-Reply-To: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>
Message-ID: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>


New submission from Denilson Figueiredo de S? <denilsonsa at gmail.com>:

If you look at socket module, there are around 29 AF_* constants (like AF_INET).

On the other hand, there is only one PF_ constant: PF_PACKET. This constant is also defined as AF_PACKET.

Following the "There should be one-- and preferably only one --obvious way to do it." advice, Python 3 removed the <> operator.  I know it's a bit late to change things in Python 3, but should socket.PF_PACKET be removed, in favor of socket.AF_PACKET? (of course, before being removed, it would be left as deprecated for quite some time)

----------
messages: 101966
nosy: denilsonsa
severity: normal
status: open
title: Should socket.PF_PACKET be removed, in favor of socket.AF_PACKET?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8270>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:07:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 00:07:59 +0000
Subject: [issue8270] Should socket.PF_PACKET be removed,
	in favor of socket.AF_PACKET?
In-Reply-To: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>
Message-ID: <1269994079.79.0.322598966862.issue8270@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +loewis
priority:  -> low
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8270>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:09:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 00:09:27 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1269994167.42.0.0146305572464.issue8269@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:36:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 31 Mar 2010 00:36:35 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1269995795.85.0.944035344728.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

You can't register an old-style class, but many ABCs support duck-typing by implementing __subclasshook__.  ABCMeta caches those results and stores a reference to old-style classes, sometimes in _abc_cache and sometimes in _abc_negative_cache.  It can't simply return False.

I guess that leaves two options:

1) Make old-style classes weak-referenceable and cache the results of __subclasshook__.
2) Refuse to cache old-style classes and call __subclasshook__ every time for old-style classes.

Python 2.7a4+ (trunk:79493, Mar 30 2010, 19:19:13)
>>> class old_iterable_class:
...   def __iter__(self):
...     pass
...
>>> import collections
>>> issubclass(old_iterable_class, collections.Iterable)
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 02:57:49 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 31 Mar 2010 00:57:49 +0000
Subject: [issue8208] test_issue7820 fails: "name '?' is not defined"
In-Reply-To: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>
Message-ID: <1269997069.3.0.964342309881.issue8208@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I did not find any issue here.

Trunk running on OS X 10.6.2:

06:25:00 l0nwlf-MBP:test $ python2.7 -V
Python 2.7a4+
06:25:05 l0nwlf-MBP:test $ python2.7 test_pep263.py 
test_compilestring (__main__.PEP263Test) ... ok
test_issue3297 (__main__.PEP263Test) ... ok
test_issue7820 (__main__.PEP263Test) ... ok
test_pep263 (__main__.PEP263Test) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.003s

OK

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8208>
_______________________________________

From report at bugs.python.org  Wed Mar 31 03:14:25 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 31 Mar 2010 01:14:25 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1269998065.14.0.675729813767.issue1083@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I do not understand why python2.7 is marked in Version tag ?

I reproduced the error on 3.1 but no isues on 2.7

06:39:30 l0nwlf-MBP:data $ python2.7
Python 2.7a4+ (trunk:78750, Mar  7 2010, 08:09:00) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> d = datetime.timedelta(1)
>>> d / 2
datetime.timedelta(0, 43200)
>>> d // 2
datetime.timedelta(0, 43200)
>>> 

06:41:13 l0nwlf-MBP:data $ python3.1
Python 3.1.1 (r311:74480, Mar 21 2010, 20:21:46) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> d = datetime.timedelta(1)
>>> d / 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int'
>>> d // 2
datetime.timedelta(0, 43200)
>>>

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Wed Mar 31 03:25:58 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 31 Mar 2010 01:25:58 +0000
Subject: [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1269998758.93.0.824516437818.issue7040@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7040>
_______________________________________

From report at bugs.python.org  Wed Mar 31 03:29:17 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 31 Mar 2010 01:29:17 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1269998957.44.0.8432003501.issue1693050@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:10:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 02:10:27 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270001427.86.0.0555316019209.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch with some tests and doc changes.

I'm having trouble coming up with tests which will work with CTRL_C_EVENT and CTRL_BREAK_EVENT. Based on my understanding of GenerateConsoleCtrlEvent, I figured this example (http://msdn.microsoft.com/en-us/library/ms685049%28v=VS.85%29.aspx) would be receptive to CTRL+C when started as a subprocess, but it doesn't work. I also figured "python -c "input()"" started as a subprocess could be killed with CTRL_C_EVENT, but it doesn't work either.

----------
Added file: http://bugs.python.org/file16703/issue1220212.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:27:16 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Wed, 31 Mar 2010 02:27:16 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1270002436.14.0.57699387023.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Is there anything else I can do for this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:28:12 2010
From: report at bugs.python.org (John Machin)
Date: Wed, 31 Mar 2010 02:28:12 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

Unicode 5.2.0 chapter 3 (Conformance) has a new section (headed "Constraints on Conversion Processes) after requirement D93. Recent Pythons e.g. 3.1.2 don't comply. Using the Unicode example:

 >>> print(ascii(b"\xc2\x41\x42".decode('utf8', 'replace')))
 '\ufffdB'
 # should produce u'\ufffdAB'

Resynchronisation currently starts at a position derived by considering the length implied by the start byte:

 >>> print(ascii(b"\xf1ABCD".decode('utf8', 'replace')))
 '\ufffdD'
 # should produce u'\ufffdABCD'; resync should start from the *failing* byte.

Notes: This applies to the 'ignore' option as well as the 'replace' option. The Unicode discussion mentions "security exploits".

----------
messages: 101972
nosy: sjmachin
severity: normal
status: open
title: str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:41:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 02:41:31 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270003291.11.0.504839251454.issue1220212@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16703/issue1220212.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Wed Mar 31 04:50:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 02:50:23 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1270003823.72.0.423561351641.issue1220212@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Removed an unnecessary goto and fixed a few tab/space inconsistencies (ugh).

----------
Added file: http://bugs.python.org/file16704/issue1220212.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Wed Mar 31 05:23:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 03:23:28 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1270005808.28.0.133086697147.issue8225@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in trunk (r79518), release26-maint (r79519), py3k (r79520), and release31-maint (r79521).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:07:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 05:07:20 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270012040.44.0.173591780155.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Anyone opposed to this being checked in? Other than some style issues which I'll fix on checkin, I believe this is ready to go. I'd like to get it in so I can backport it to 2.7 before the beta on Saturday.

----------
assignee: eric.smith -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:10:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 31 Mar 2010 05:10:47 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270012247.82.0.0484072669551.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I had some style issues at one point, but I haven't looked at it closely recently. I won't have time to look at this before next week, so proceed without me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:14:41 2010
From: report at bugs.python.org (sorin)
Date: Wed, 31 Mar 2010 05:14:41 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1270012481.91.0.463084741832.issue1578269@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

For me the patch worked. It would be really nice to have it in 2.7 - I really hate Python functions that are not working on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 07:54:32 2010
From: report at bugs.python.org (workshed)
Date: Wed, 31 Mar 2010 05:54:32 +0000
Subject: [issue8272] Odd exception messages when using cStringIO.StringIO
	instances as callables.
In-Reply-To: <1270014872.55.0.791249061919.issue8272@psf.upfronthosting.co.za>
Message-ID: <1270014872.55.0.791249061919.issue8272@psf.upfronthosting.co.za>


New submission from workshed <workshed55 at gmail.com>:

Just a minor nit (or I'm missing something), but the results of trying to use a cStringIO.StringIO instance as a callable look wrong to me.  It should of course raise an exception, but shouldn't the 'cStringIO.StringO' and 'cStringIO.StringI' strings reported in the errors below both read 'cStringIO.StringIO'?


winston at eee:~/Python-2.6.5$ ./python
Python 2.6.5 (r265:79063, Mar 30 2010, 22:38:30)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cStringIO
>>> cStringIO.StringIO()()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'cStringIO.StringO' object is not callable
>>> cStringIO.StringIO('')()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'cStringIO.StringI' object is not callable

I get the same results on my Ubuntu 9.10 system with a new build of 2.6.5 and the built in 2.6.4, as well as the 2.5.4 and 2.4.6 versions available in the repos.

Workshed

----------
components: Library (Lib)
messages: 101978
nosy: workshed
severity: normal
status: open
title: Odd exception messages when using cStringIO.StringIO instances as callables.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8272>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:03:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 31 Mar 2010 06:03:13 +0000
Subject: [issue8272] Odd exception messages when using cStringIO.StringIO
	instances as callables.
In-Reply-To: <1270014872.55.0.791249061919.issue8272@psf.upfronthosting.co.za>
Message-ID: <1270015393.0.0.309311619179.issue8272@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

cStringIO.StringIO is a factory function, so those messages are correct. This is mentioned in http://docs.python.org/library/stringio.html#module-cStringIO .

----------
nosy: +eric.smith
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8272>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:12:23 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 31 Mar 2010 06:12:23 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1270015943.88.0.43622293005.issue8260@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hi Stephane,

I think you're seeing different buffering behavior, which I suspect is correct according to docs.

codecs.open should default to line buffering[1], while open uses the system default[2].

The read() where the assert fails is returning the remaining buffer from the readline (which read 72 chars).

Asserting e.g. "f.read(1024) == ..." will give you the expected result.

[1] http://docs.python.org/library/codecs.html#codecs.open
[2] http://docs.python.org/library/functions.html#open

----------
nosy: +ajaksu2
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:14:33 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 31 Mar 2010 06:14:33 +0000
Subject: [issue8198] Importing pydoc and overwriting sys.stdout,
	causes one char to be sent to the console when calling help()
In-Reply-To: <1269235324.89.0.336122945296.issue8198@psf.upfronthosting.co.za>
Message-ID: <1270016073.18.0.806961616916.issue8198@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Nice buglet, please take a look at Lib/pydoc.py to follow :)

As you point out, this is issue 1700304.
 
'plainpager', which outputs the help in these cases, uses 'sys.stdout.write(plain(text))', but Helper.help has a         "self.output.write('\n')" line that causes the behavior you see.

We could change "self.output.write('\n')" to "pager('\n')", but the real bug is that self.output is bound early to sys.stdout. So 'help()' is still redirecting to the old sys.stdout with your test.

I see a solution by turning Helper.output into a property, but it smells of over-engineering :) Passing all output to pagers should work too, unless we need Helper.output as a sort of sys.stderr.

The patch below shows that importing pydoc sets self.output prematurely and includes the "self.output.write('\n')" line.

Index: pydoc.py
===================================================================
--- pydoc.py    (revision 79447)
+++ pydoc.py    (working copy)
@@ -1765,6 +1765,7 @@
         elif isinstance(request, Helper): self()
         else: doc(request, 'Help on %s:')
         self.output.write('\n')
+        print >> sys.stderr, repr(self.output)

     def intro(self):
         self.output.write('''

----------
dependencies: +pydoc.help samples sys.stdout and sys.stdin at import time
keywords: +easy
nosy: +ajaksu2
priority:  -> low
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8198>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:14:43 2010
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 31 Mar 2010 06:14:43 +0000
Subject: [issue1700304] pydoc.help samples sys.stdout and sys.stdin at import
	time
Message-ID: <1270016083.67.0.357825115528.issue1700304@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

>From #8198:

I see a solution by turning Helper.output into a property, but it smells of over-engineering :) Passing all output to pagers should work too, unless we need Helper.output as a sort of sys.stderr.

----------
keywords: +easy
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700304>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:41:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 31 Mar 2010 06:41:59 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270017719.59.0.571808572792.issue8271@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 08:48:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 31 Mar 2010 06:48:58 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1270018138.76.0.481966480672.issue8269@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

if you are referring to http://docs.python.org/dev/py3k/c-api/unicode.html#PyUnicode_FromFormat the return type is a PyObject.

See also http://docs.python.org/dev/py3k/c-api/structures.html#PyObject

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:16:49 2010
From: report at bugs.python.org (Arnaud Fontaine)
Date: Wed, 31 Mar 2010 07:16:49 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1270019809.53.0.664885166913.issue8269@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is most specified for most functions in Unicode Object (at least).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 09:17:25 2010
From: report at bugs.python.org (Arnaud Fontaine)
Date: Wed, 31 Mar 2010 07:17:25 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1270019845.33.0.228796593189.issue8269@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is not specified for most functions in Unicode Object (at least).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 11:21:49 2010
From: report at bugs.python.org (Yoann Aubineau)
Date: Wed, 31 Mar 2010 09:21:49 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1270027309.43.0.799472663533.issue3445@psf.upfronthosting.co.za>


Changes by Yoann Aubineau <yoann.aubineau at gmail.com>:


----------
nosy: +yaubi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Wed Mar 31 11:26:20 2010
From: report at bugs.python.org (Cyril)
Date: Wed, 31 Mar 2010 09:26:20 +0000
Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1270027580.78.0.0986147628582.issue8240@psf.upfronthosting.co.za>


Cyril <cbay at excellency.fr> added the comment:

I had a look at how M2Crypto and pyOpenSSL handled this:

 - M2Crypto has wrappers around SSL_set_mode that let you set the modes you want. From their changelog [1], it was required to be able to operate with Twisted. By default, though, they only set SSL_MODE_AUTO_RETRY.

 - pyOpenSSL enables everything by default, and there's no set_mode wrapper. Here is the relevant code:

/* Some initialization that's required to operate smoothly in Python */
SSL_CTX_set_mode(self->ctx, SSL_MODE_ENABLE_PARTIAL_WRITE |
                            SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER |
                            SSL_MODE_AUTO_RETRY);

I don't see any other possible alternative. I'm not sure which one is better. Implementing a set_mode wrapper with no mode set by default has no compatibility issues, although we'd still have that 'bad write retry' OpenSSL error.

On the other hand, setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default is easy but we lose some security (and, possibly, some compatibility problems, although I doubt anyone relies on the 'bad write retry' error).

What do you think? I'd be ready to write the patch for the set_mode wrapper if you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8240>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:00:21 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 31 Mar 2010 10:00:21 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1270029621.31.0.495333713529.issue8260@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Buffering applies when writing, not when reading a file.

There is indeed a problem in codecs.py: after a readline(), read() will return the content of the internal buffer, and not more.

The "size" parameter is a hint, and should not be used to decide whether the character buffer is enough to satisfy the read() request.
Patch is attached, with test.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
stage: test needed -> patch review
Added file: http://bugs.python.org/file16705/codecs_read.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Wed Mar 31 12:28:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 31 Mar 2010 10:28:22 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up
	by	f.read() return bad result
In-Reply-To: <1270029621.31.0.495333713529.issue8260@psf.upfronthosting.co.za>
Message-ID: <4BB323C1.7070107@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Buffering applies when writing, not when reading a file.
> 
> There is indeed a problem in codecs.py: after a readline(), read() will return the content of the internal buffer, and not more.
> 
> The "size" parameter is a hint, and should not be used to decide whether the character buffer is enough to satisfy the read() request.
> Patch is attached, with test.

Agreed.

The patch looks good except the if-line should read:

if chars >= 0 and len(self.charbuffer) >= chars:
  ...

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
nosy: +lemburg
title: When I use codecs.open(...) and f.readline() follow up by f.read() return bad result -> When I use codecs.open(...) and f.readline() follow up by	f.read() return bad result

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From mal at egenix.com  Wed Mar 31 12:28:17 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 31 Mar 2010 12:28:17 +0200
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow
	up by	f.read() return bad result
In-Reply-To: <1270029621.31.0.495333713529.issue8260@psf.upfronthosting.co.za>
References: <1270029621.31.0.495333713529.issue8260@psf.upfronthosting.co.za>
Message-ID: <4BB323C1.7070107@egenix.com>

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Buffering applies when writing, not when reading a file.
> 
> There is indeed a problem in codecs.py: after a readline(), read() will return the content of the internal buffer, and not more.
> 
> The "size" parameter is a hint, and should not be used to decide whether the character buffer is enough to satisfy the read() request.
> Patch is attached, with test.

Agreed.

The patch looks good except the if-line should read:

if chars >= 0 and len(self.charbuffer) >= chars:
  ...

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 31 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From report at bugs.python.org  Wed Mar 31 12:54:56 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Wed, 31 Mar 2010 10:54:56 +0000
Subject: [issue4256] optparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1270032896.3.0.983415562143.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Are you saying, that for example for this:

gruszczy at gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help
Usage: logbuilder [options] repo

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -r REGEXP, --regexp=REGEXP
                        filter revisions using regular expression
  -c CONTAINS, --contains=CONTAINS
                        filter revisions that doesn't contain given string
  -s START_REV, --start=START_REV
                        first revision to be used in log
  -e END_REV, --end=END_REV
                        last revision to be used in log
  -f FILE, --file=FILE  file where result will be stored
  -t TEMPLATE, --template=TEMPLATE
                        template used to display changes
  -p PURGE, --purge=PURGE
                        remove parts of a commit messages, that match given
                        regexp

you would like to get:

gruszczy at gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help-options

  --version
  -h, --help
  -r, --regexp
  -c, --contains
  -s, --start
  -e, --end
  -f, --file
  -t, --template
  -p, --purge

?

----------
nosy: +gruszczy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:11:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 31 Mar 2010 11:11:08 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up
	by	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1270033868.83.0.798424854437.issue8260@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Updated patch.

[I also tried to avoid reading the underlying file if len(self.bytebuffer)>=size, but it does not work with multibytes chars when size=1]

----------
Added file: http://bugs.python.org/file16706/codecs_read-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:19:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 11:19:11 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Let's move test_support in unittest !

Then maybe, let's expose some of test_support functions into a new class on the top of unittest.TestCase, so they can be used via methods.
 
The purpose is power up people when it comes to write test fixtures or work in a testing environment. These helpers were built to test Python itself, are quite unknown out there. I think it's a shame :)

http://docs.python.org/library/test.html#module-test.test_support

----------
assignee: michael.foord
components: Library (Lib)
messages: 101991
nosy: michael.foord, tarek
severity: normal
status: open
title: move test_support into the unittest package
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:23:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 11:23:27 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270034607.48.0.82794404932.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmmm... I'm not sure moving everything as is is a good idea. Any parts in particular you want?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:27:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 11:27:31 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270034851.6.0.0370109211219.issue8273@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Basically, all the APIs in test_support could live in unittest and the test package could only contain the test modules written for Python.

IOW, these tests helpers can help more people than the core devs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:31:37 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 11:31:37 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270035097.03.0.617201962142.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Not all the APIs are appropriate though, for example TestFailed and TestSkipped are not needed. Some of the APIs only make sense for the test_support runner and unittest has its own runner now.

I think the proposal needs to be more specific about which APIs you are suggesting would be generally useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:32:44 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 11:32:44 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270035164.37.0.620424308527.issue8273@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Sure, no need to have the test runner parts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:35:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 11:35:04 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270035304.04.0.972713250964.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So which parts, can you list the ones you think are most important?

At the moment we don't have to maintain backwards compatibility with test.test_support as it isn't a 'public' API - so the cost in adding it to the standard library is the same as adding any code. Once we do this we are less free to modify / evolve the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 13:54:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 11:54:47 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270036487.32.0.439491913783.issue8273@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, the list Terek posted a link to is a public doc page, and as was made clear in the recent issue about the check_warnings helper, we do have to maintain backward compatibility.  

There (should be) undocumented stuff in test_support, purposely left undocumented so that we *don't* have to maintain backward compatibility.  Myself I wish that doc page didn't even exist.  Putting stuff that users can use into unittest is a much better idea.

Maybe we could move the appropriate stuff and get rid of the test_support doc page altogether.  And when we move stuff to unittest maybe we could take the opportunity to clean up any warts in the interfaces.

----------
nosy: +georg.brandl, r.david.murray
priority:  -> low
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:03:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 31 Mar 2010 12:03:53 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270037033.31.0.575794639345.issue8273@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

> Maybe we could move the appropriate stuff and get rid of the
> test_support doc page altogether.  And when we move stuff to unittest
> maybe we could take the opportunity to clean up any warts in the
> interfaces.

+1

I don't like the burden of backward compatibility concerns for this kind of test helpers.

The "Lib/test/" directory should be exclusively for internal Python tests.
It should be clearly stated in the documentation.

If some helpers are enough generic, they could be moved to unittest.support (or unittest.util).

----------
nosy: +flox
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:06:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 12:06:34 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270037194.1.0.0692780113668.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Right - that is exactly why I want a specific proposal as to which APIs are generally useful and should be considered for moving into unittest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:09:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 12:09:35 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270037375.12.0.594288423763.issue8193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Nick's point is that we should be testing both the value 0 and the value -1, but that we should expect 0 to fail only if zlib.ZLIB_VERSION is less than 1.2.4.  So you'll need to update your patch to keep the 0 test but put it inside an appropriate conditional.

The original problem may be in 2.5, but we are doing security updates only for 2.5, so the fix won't backported to 2.5.  (At least not by us, distributors are of course free to patch their own distributions of earlier python versions.)

I'm not sure what your last comment about the default means.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:11:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 12:11:31 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270037491.1.0.00314513722379.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sorry, missed David's comment:

> Maybe we could move the appropriate stuff and get rid of the
> test_support doc page altogether.  And when we move stuff to unittest
> maybe we could take the opportunity to clean up any warts in the
> interfaces.

This I agree with. The question here is deciding what is "the appropriate stuff". 

If we have to maintain backwards compatibility in test_support we could just leave things in there... (possibly plus deprecation or deprecation via documentation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:55:43 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 12:55:43 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270040143.55.0.0192489431687.issue8273@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes, let's make things explicit as David said:

- "test" package: tests for Python itself, with private stuff, undocumented. 

- "unittest" package: the test framework that is used by the test package and that is public

I'd add a support module in unittest, containing these (maybe renamed and consolidated) and deprecate them in test_support:

- is_jython
- TESTFN
- forget
- findfile
- check_warnings
- captured_stdout
- TransientResource
- transient_internet
- EnvironmentVarGuard
- WarningsRecorder
- cpython_only
- temp_cwd
- sortdict

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:55:50 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 31 Mar 2010 12:55:50 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1270040150.49.0.151925354841.issue8233@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Wed Mar 31 14:56:06 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 31 Mar 2010 12:56:06 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1270040166.8.0.622053275308.issue8233@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
keywords: +needs review -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:18:34 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 13:18:34 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270041514.97.0.106923755426.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

This was clear. Now i make a new patch and then upload it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:20:28 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 13:20:28 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270041628.43.0.43815675411.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

A 'support' sub-module in unittest is ok. I wonder if it is the best name?

- is_jython

This is too specific and ignores the other implementations. This information is also available from sys / platform modules. 

-1

- TESTFN

This is a global for setting the directory temporary files are created in? Don't think I like the global approach. Which functions is it used by?

- forget

This is the equivalent of sys.modules.pop(module_name, None) but it also deletes bytecode. I don't think a bytecode deleting API is needed in unittest.

-1


- findfile

I need to look at the code, don't understand it from the description in the docs.

- check_warnings

Could be useful.

- captured_stdout

Could be useful.

- TransientResource

I need to look at how it is used, but sounds useful.

- transient_internet

Not documented, I need to look at the code / how it is used.

- EnvironmentVarGuard

Could be useful.

- WarningsRecorder

Used by catch_warnings I guess.

- cpython_only

Not documented but could be useful.

- temp_cwd

Not documented but could be useful.

- sortdict

Not documented but could be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:23:58 2010
From: report at bugs.python.org (Tim Golden)
Date: Wed, 31 Mar 2010 13:23:58 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270041628.43.0.43815675411.issue8273@psf.upfronthosting.co.za>
Message-ID: <4BB34CE8.1010706@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

On 31/03/2010 14:20, Michael Foord wrote:

> - TESTFN
>
> This is a global for setting the directory temporary files are created in? Don't think I like the global approach. Which functions is it used by?

It's used *all over the place*. I started trying to rip it out
ages ago but it call got far too intrusive and I just backed
away. ISTR that more recent tests have used NamedTemporaryFile
or something similar, which makes much more sense.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:24:20 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 13:24:20 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270041860.96.0.258770539273.issue8193@psf.upfronthosting.co.za>


Changes by Valerio <turturici.valerio at gmail.com>:


Removed file: http://bugs.python.org/file16691/8193.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:46:35 2010
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 31 Mar 2010 13:46:35 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1270043195.9.0.329095604027.issue1083@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

It's marked on 2.7 due to the following (this is svn 79528)

>>> from datetime import timedelta
>>> d = timedelta(1)
>>> d / 2
datetime.timedelta(0, 43200)
>>> d // 2
datetime.timedelta(0, 43200)
>>> from __future__ import division
>>> d / 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:52:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 13:52:31 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270043551.67.0.250017139709.issue8273@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

about : cpython_only / is_jython

I think the idea here is to mark some tests as being specific to some implementations.

I remember a discussion where we said that we could add in sys or platform the name of the implementation and make this somehow future-proof.

I can't recall where we said that...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:55:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 13:55:14 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270043714.59.0.0535051851168.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Something like this was discussed at the language summit. Now we have the skip decorators it is easy to skip tests on certain platforms or only run them on certain platforms.

The cpython_only decorator is fine - but I'd prefer a general solution rather than is_jython, is_pypy, is_ironpython, etc... Do we yet have a sys.implementation or equivalent? We need it. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:57:23 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 13:57:23 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270043843.43.0.524550801258.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

Here's the new patch. It's ok?

----------
Added file: http://bugs.python.org/file16707/8193.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 15:58:53 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 13:58:53 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270043933.15.0.402736586002.issue8193@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Looks good to me.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:11:47 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Wed, 31 Mar 2010 14:11:47 +0000
Subject: [issue8274] test_run failing
In-Reply-To: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>
Message-ID: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>


New submission from Zubin Mithra <zubin.mithra at gmail.com>:

======================================================================
FAIL: test_run (distutils2.tests.test_build_clib.BuildCLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/test_build_clib.py", line 137, in test_run
    self.assertTrue('libfoo.a' in os.listdir(build_temp))
AssertionError: False is not True

----------------------------------------------------------------------
Ran 135 tests in 1.004s

FAILED (failures=1, skipped=4)
Traceback (most recent call last):
  File "runtests.py", line 18, in <module>
    test_main()
  File "runtests.py", line 12, in test_main
    run_unittest(distutils2.tests.test_suite())
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/__init__.py", line 86, in run_unittest
    _run_suite(suite)
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/__init__.py", line 66, in _run_suite
    raise TestFailed(err)
distutils2.tests.TestFailed: Traceback (most recent call last):
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/test_build_clib.py", line 137, in test_run
    self.assertTrue('libfoo.a' in os.listdir(build_temp))
AssertionError: False is not True

----------
assignee: tarek
components: Distutils2
messages: 102011
nosy: tarek, zubin71
severity: normal
status: open
title: test_run failing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8274>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:38:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 14:38:26 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270046306.46.0.412586587996.issue8193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't it be
  zlib.ZLIB_VERSION < '1.2.4'
rather than
  zlib.ZLIB_VERSION <= '1.2.4'
?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:56:43 2010
From: report at bugs.python.org (=?utf-8?q?Daniel_Gra=C3=B1a?=)
Date: Wed, 31 Mar 2010 14:56:43 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270047403.83.0.328286989699.issue8271@psf.upfronthosting.co.za>


Changes by Daniel Gra?a <dangra at gmail.com>:


----------
nosy: +dangra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 16:59:31 2010
From: report at bugs.python.org (=?utf-8?q?Daniel_Gra=C3=B1a?=)
Date: Wed, 31 Mar 2010 14:59:31 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270047571.4.0.925230941138.issue8271@psf.upfronthosting.co.za>


Daniel Gra?a <dangra at gmail.com> added the comment:

Some background for this report at http://stackoverflow.com/questions/2547262/why-is-python-decode-replacing-more-than-the-invalid-bytes-from-an-encoded-string/2548480

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:16:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 15:16:42 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270048602.1.0.245323835724.issue8193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Are we safe using string comparison here?  How likely is zlib to get into double digit release numbers?  (Too bad the version comparison stuff Tarek is working on isn't already available.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:21:54 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 31 Mar 2010 15:21:54 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270048914.02.0.365879096058.issue8193@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Note that the exact version which changed the behavior is 1.2.3.5, see http://www.zlib.net/ChangeLog.txt
    - Use zlib header window size if windowBits is 0 in inflateInit2()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:22:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 15:22:36 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270048956.31.0.650552029311.issue8271@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:40:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 15:40:03 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270050003.17.0.925702260568.issue8193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The else branch of the test should also check that 0 does *not* raise an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 17:49:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 15:49:01 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270050541.48.0.499176615303.issue8193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, actually Python is only echoing the error return from zlib here, so I don't seen the point of the conditional. Just always test against -1 and we're done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:33:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Mar 2010 16:33:10 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1270053190.24.0.668905949559.issue8225@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Is it ok that the code checks ?object.__name__ not in ('xml.etree')?? Looks like a failed single-item tuple to me. Besides, what about using a simple ?!=??

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:36:59 2010
From: report at bugs.python.org (METAL XXX)
Date: Wed, 31 Mar 2010 16:36:59 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1270053419.98.0.680647313809.issue1771@psf.upfronthosting.co.za>


METAL XXX <metal29a at gmail.com> added the comment:

I have a tree:

   A
  / \
 B   C
/ \
D E

which is implemented as a dict

tree = {
  'A': set(['B', 'C']),
  'B': set(['D', 'E']), 
  'C': set(),
  'D': set(),
  'E': set(),
}

I want to sort the nodes.

and I don't know how to write a key function for sort() in this situation

so I write a cmp function:

sorted(tree, cmp=lambda x, y: 1 if x in tree[y] else -1 if y in tree[x] else 0)

and it gets ['A', 'C', 'B', 'E', 'D'].

how to convert cmp to key really confused me and it surely need more typing time.

so I disagree the removal

----------
nosy: +metal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________

From report at bugs.python.org  Wed Mar 31 18:52:06 2010
From: report at bugs.python.org (Valerio)
Date: Wed, 31 Mar 2010 16:52:06 +0000
Subject: [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1270054326.56.0.169510225762.issue8193@psf.upfronthosting.co.za>


Valerio <turturici.valerio at gmail.com> added the comment:

@pitrou: because the op have the problem with 1.2.4 version of zlib. By the way i had just always test against -1 in my first patch. Make i a new patch with a simple correction with -1 in place of 0?

@david: i know, but i'm learning now the TDD, so excuse me if i make mistakes. How i check that a function don't raise an error? About the string comparison you right, this is the first thing that i thought, but when i looked the type of release number, in that moment i thought that the string comparison was ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8193>
_______________________________________

From report at bugs.python.org  Wed Mar 31 19:23:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 17:23:58 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1270056238.41.0.627248751206.issue8225@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Good catch. That was intended to be a single tuple because the other check above is a tuple, but because this really only checks one thing it could be a != until its necessary to be a tuple. I'll fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 19:40:06 2010
From: report at bugs.python.org (David Albert Torpey)
Date: Wed, 31 Mar 2010 17:40:06 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1270057206.47.0.221084976966.issue1771@psf.upfronthosting.co.za>


David Albert Torpey <dtorp at users.sourceforge.net> added the comment:

> sorted(tree, cmp=lambda x, y: 1 if x in tree[y] else -1 if y in tree[x] else 0)
>
> and it gets ['A', 'C', 'B', 'E', 'D'].

That cmp function is nonsense and isn't even close to being correct:

>>> from random import shuffle
>>> for i in range(10):
... 	t = list(tree)
... 	shuffle(t)
... 	print sorted(t, cmp=lambda x, y: 1 if x in tree[y] else -1 if y in tree[x] else 0)
	
['E', 'C', 'B', 'D', 'A']
['A', 'D', 'C', 'B', 'E']
['C', 'B', 'E', 'D', 'A']
['E', 'D', 'A', 'C', 'B']
['A', 'B', 'D', 'E', 'C']
['D', 'A', 'E', 'C', 'B']
['C', 'D', 'A', 'B', 'E']
['A', 'C', 'B', 'D', 'E']
['A', 'C', 'B', 'E', 'D']
['A', 'C', 'B', 'D', 'E']

> how to convert cmp to key really confused
> me and it surely need more typing time.

Just cut and paste the recipe.  Simple.

----------
nosy: +dtorp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________

From report at bugs.python.org  Wed Mar 31 19:50:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 17:50:35 +0000
Subject: [issue8225] Wrong link in xml.etree documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1270057835.6.0.31332468851.issue8225@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Made the change in r79529 through 79532.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8225>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:07:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 31 Mar 2010 18:07:45 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270058865.03.0.672346954204.issue8271@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I guess the term "failing" byte somewhat underdefined.

Page 95 of the standard PDF (http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf) suggests to "Replace each maximal subpart of an ill-formed subsequence by a single U+FFFD".

Fortunately, they explain what they are after: if a subsequent byte in the sequence does not have the high bit set, it's not to be considered part of the UTF-8 sequence of the code point.

Implementing that should be fairly straight-forward by adjusting the endinpos variable accordingly.

Any takers ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:14:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 31 Mar 2010 18:14:40 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1270019845.33.0.228796593189.issue8269@psf.upfronthosting.co.za>
Message-ID: <4BB3910D.8060001@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Arnaud Fontaine wrote:
> 
> Arnaud Fontaine <arnau at debian.org> added the comment:
> 
> I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is not specified for most functions in Unicode Object (at least).

Patches are welcome !

FWIW: Unless otherwise noted, all Unicode APIs that return a PyObject*
give you a new reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:22:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 31 Mar 2010 18:22:59 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270059779.8.0.817870431095.issue8273@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I take the blame on documenting the handful of things in test.support; I thought it was a good idea to expose the handful of things that had an actual design to them. =)

But yes, we should probably shift to test.support to being private and simply exposing the stuff that we want to support to another module, although this stuff is not unittest-specific; its just testing utility functions. testlib or testutils would be a better place.

And we should make sure we are *very* comfortable supporting whatever we move over and that it has a good API as test.support has been a dumping ground for so long that most of that stuff should not get exposed (and honestly should get ripped out or cleaned up; TESTFN is just bad for instance).

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:47:30 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Mar 2010 18:47:30 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1270061250.38.0.891443592629.issue1771@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:53:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 31 Mar 2010 18:53:36 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270061616.94.0.901928649473.issue8273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I think namespacing utility functions / classes inside unittest is fine (even good), but agree that there needs to be careful thinking about APIs that are made public in this way. To a certain extent this code has already proved its utility, but up until now it hasn't needed to be *generally* useful (and as brett says - some of the code in test_support would be better off dead).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 20:53:45 2010
From: report at bugs.python.org (Jasmit)
Date: Wed, 31 Mar 2010 18:53:45 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	leak?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>


New submission from Jasmit <jsingh at roguewave.com>:

I am testing a wrapper on Windows 64 and it seems to result in an null pointer access error ONLY when I insert a print statement in the C code.  I have tested the wrapper with Python 2.6 and Python 2.7a4.  In addition, I have compiled Python 2.6.5 source code and ONLY the release version results in an error.  I think the issue is with memcpy(obj->b_ptr, *pArgs, dict->size) (callbacks.c).  pArgs seem to be  corrupted.  However, I am only looking at the code for the first time and I might be off base.

The following is Python and C code to reproduce the bug.  To resolve, please comment printf statement in jfunc (C function).

Python Code:
from ctypes import *
def fcn(m,n,x,f):
    print "IN Python function fcn ................"
    print f[0]
    
m=3
n=1
pydlltest=cdll.pydlltest
pydlltest.jfunc.restype = POINTER(c_double)
evalstring = 'pydlltest.jfunc('
TMP_FCN=CFUNCTYPE(None,c_int,c_int,POINTER(c_double),POINTER(c_double))
tmp_fcn=TMP_FCN(fcn)
state=[TMP_FCN,tmp_fcn]
evalstring += 'tmp_fcn'
evalstring +=','
evalstring +='c_int(m)'
evalstring +=','
evalstring +='c_int(n)'
evalstring += ')'
print "evalstring=",evalstring
result = eval(evalstring)

C code:
#include <stdio.h>
__declspec(dllexport) double *jfunc(void (*fcn) (int,int,double [],double[]),int m,int n);

double *jfunc(void (*fcn) (int,int,double [],double []),int m,int n)
{
	double *fvec=NULL;
	double *xguess = NULL;
	int i = 0;
	int j = 0;
	/* comment the line below to fix the resulting null pointer access error */
	printf("In j func .................\n");
	fvec = (double *) malloc (m * sizeof (double));
	xguess = (double *) malloc (n * sizeof (double));
	for (i = 0; i < n; i++){
	   xguess[i] = 0.123;
	}
	(*fcn) (m, n, xguess, fvec);
	return fvec;
}

----------
assignee: theller
components: ctypes
files: ctype_win64.txt
messages: 102028
nosy: ocrush, theller
severity: normal
status: open
title: callback function on win64 results in bad behavior. mem leak?
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16708/ctype_win64.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Mar 31 21:03:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 31 Mar 2010 19:03:20 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1270062200.14.0.801450129409.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Gabriel, besides the *Ex naming, do you see anything wrong with the rest of the patch? I'd like to try and get this into 2.7 before the upcoming beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Wed Mar 31 21:14:29 2010
From: report at bugs.python.org (METAL XXX)
Date: Wed, 31 Mar 2010 19:14:29 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1270062869.6.0.708972006076.issue1771@psf.upfronthosting.co.za>


METAL XXX <metal29a at gmail.com> added the comment:

Sorry I ripped the code from a mess and I forget the tree is "leaflized" as

tree = {
  'A': set(['B', 'C', 'D', 'E']),
  'B': set(['D', 'E']), 
  'C': set(),
  'D': set(),
  'E': set(),
}

I don't want to talk about the actual problem. I think sometime 
it's hard to give an "absolute" weight value as key, for this example,
is the relationship in graph. Then user have to "Copy and paste the recipe" to get a cmp function which should be already there. We are
all adults here, why don't SIMPLELY tell the newbie don't use cmp() use key() unless you know what you are doing.


Thanks for reply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:18:20 2010
From: report at bugs.python.org (Jasmit)
Date: Wed, 31 Mar 2010 20:18:20 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1270066700.15.0.684899127832.issue8275@psf.upfronthosting.co.za>


Changes by Jasmit <jsingh at roguewave.com>:


----------
title: callback function on win64 results in bad behavior. mem leak? -> callback function on win64 results in bad behavior. mem corruption?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Mar 31 22:57:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 31 Mar 2010 20:57:45 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1270069065.03.0.408713514275.issue1771@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

cmp is gone.  It's chances of coming back are close enough to zero that an assertAlmostEqual test will pass :).  The rest of the discussion should move to one of the general python lists.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:07:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 31 Mar 2010 21:07:39 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1270069659.97.0.903136106953.issue8233@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Slightly modified, patch committed to trunk in r79533

----------
keywords: +patch -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:07:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 31 Mar 2010 21:07:55 +0000
Subject: [issue8273] move test_support into the unittest package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270069675.41.0.186118955223.issue8273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree that some things can be moved in unittest, however several of the function in test_support are designed specifically for being used for the python test suite. For example temp_cwd is something that could be really useful in unittest in my opinion, however we designed it looking at our use cases. We limited its utility to what we needed and we didn't document it so that we are free to change it if/when the use cases change.

On a side node, sortdict() is probably useless now that we have assertDictEqual().

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8273>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:36:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 31 Mar 2010 21:36:44 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1270071404.95.0.611235712954.issue8233@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r79536 in py3k

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:38:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 21:38:50 +0000
Subject: [issue8268] Make old-style classes weak referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1270071530.8.0.937903710301.issue8268@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r79535.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8268>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:39:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 31 Mar 2010 21:39:34 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1270071574.05.0.2797792412.issue2521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Make old-style classes weak-referenceable

Now done (r79535).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Wed Mar 31 23:41:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 31 Mar 2010 21:41:46 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1270071706.12.0.952446276317.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Cool!  I will revise the patch based on your comments about my test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________