From report at bugs.python.org  Tue Dec  1 01:23:45 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 00:23:45 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259627025.53.0.683411674003.issue7401@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

The attached C file exhibits the same symptoms, on Mac OS X 10.5 it
eventually hangs in an uninteruptible disk wait.  On Linux it doesn't
hang.  Further support for the idea that this is a Mac OS X problem.

How does one provide this reproducible case to Apple?

----------
Added file: http://bugs.python.org/file15419/os_pipe_write_close_bug.c

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

From report at bugs.python.org  Tue Dec  1 01:26:43 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 00:26:43 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259627203.1.0.325900189.issue7401@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


Removed file: http://bugs.python.org/file15419/os_pipe_write_close_bug.c

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

From report at bugs.python.org  Tue Dec  1 01:27:30 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 00:27:30 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259627250.85.0.432227363277.issue7401@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

Fixed some typos in the C file

----------
Added file: http://bugs.python.org/file15420/os_pipe_write_close_bug.c

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

From report at bugs.python.org  Tue Dec  1 03:03:01 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 01 Dec 2009 02:03:01 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Passing NUL as the separator to isoformat drops the time part of the
result entirely:

>>> import datetime
>>> datetime.datetime.today().isoformat()
'2009-11-30T20:57:37.918750'
>>> datetime.datetime.today().isoformat('x')
'2009-11-30x20:57:39.902573'
>>> datetime.datetime.today().isoformat('\0')
'2009-11-30'
>>>

----------
messages: 95845
nosy: exarkun
severity: normal
status: open
title: datetime.datetime.isoformat truncation problem

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

From report at bugs.python.org  Tue Dec  1 06:08:36 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 01 Dec 2009 05:08:36 +0000
Subject: [issue7414] Format code "C" is missing from skipitem() in getargs.c
In-Reply-To: <1259644116.32.0.35772934709.issue7414@psf.upfronthosting.co.za>
Message-ID: <1259644116.32.0.35772934709.issue7414@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

An error was reported on c.l.py. The following code in a Python 3
extension module generated an error:

=====================================
If I use the following C code

static PyObject* foo(PyObject *self, PyObject *args, PyObject *kwrds)
{
  char a, b;
  char *kwlist[] = {"a", "b", NULL};
  if (!PyArg_ParseTupleAndKeywords(args, kwrds, "|CC", kwlist, &a,
&b))
    return NULL;
  ...

then the following works:

>>> foo('a')
>>> foo('a','b')
>>> foo(a='a',b='b')

but the following fails:
>>> foo(b='b')

RuntimeError: impossible<bad format char>: 'CC'

======================================

I traced it down to missing case statement for "C" in skipitem() in
getargs.c. The attached patch seems to fix the issue.

----------
components: Extension Modules
files: getargs.patch
keywords: patch
messages: 95846
nosy: casevh
severity: normal
status: open
title: Format code "C" is missing from skipitem() in getargs.c
versions: Python 3.1
Added file: http://bugs.python.org/file15421/getargs.patch

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

From report at bugs.python.org  Tue Dec  1 07:19:14 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 01 Dec 2009 06:19:14 +0000
Subject: [issue7415] PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()
In-Reply-To: <1259648354.78.0.66746814248.issue7415@psf.upfronthosting.co.za>
Message-ID: <1259648354.78.0.66746814248.issue7415@psf.upfronthosting.co.za>


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

PyUnicode_FromEncodedObject() currently calls PyObject_AsCharBuffer() to
get the buffer pointer and length of a buffer supporting object. It
should be changed to support the buffer protocol correctly instead.

I filed this as a crash bug as the buffer protocol allows a buffer
supporting object to discard its buffer when the release function is
called. The decode function uses the buffer only *after* releasing it,
thus provoking a crash for objects that implement the buffer protocol
correctly in that they do not allow access to the buffer after the release.

----------
components: Interpreter Core
messages: 95847
nosy: scoder
severity: normal
status: open
title: PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()
type: crash
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  1 08:16:17 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2009 07:16:17 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259651777.8.0.481006664442.issue7401@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Hugh: Do you have an ADC account (either free or payed)? If you do you can 
file bugs at http://bugreport.apple.com/. If you don't I can file the bug 
for you.

----------

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

From report at bugs.python.org  Tue Dec  1 09:00:32 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 08:00:32 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1259654432.06.0.121672301171.issue691291@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Proposed patch following suggestion of And Clover.

Compliant with documentation:
?Files are always opened in binary mode, even if no binary mode was
specified. This is done to avoid data loss due to encodings using 8-bit
values. This means that no automatic conversion of '\n' is done on
reading and writing.?

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file15422/issue691291.diff

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

From report at bugs.python.org  Tue Dec  1 09:01:49 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 08:01:49 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1259654509.74.0.1998085774.issue691291@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15423/issue691291_py3k.diff

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

From report at bugs.python.org  Tue Dec  1 09:31:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 08:31:28 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259656288.92.0.202599442299.issue7413@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a test + fix.

----------
assignee:  -> amaury.forgeotdarc
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file15424/isoformat.patch

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

From report at bugs.python.org  Tue Dec  1 10:03:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Dec 2009 09:03:10 +0000
Subject: [issue7416] select module compile errors breaks OS X
	multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>


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

Release blocker

The changes for Issue7211 to support 64-bit kevent ident fields
in 64-bit builds cause compile errors on those OS X multi-arch
builds which include both 32-bit and 64-bit variants.

Problem is reproducible by this simplified build config:

   configure --with-universal-archs=intel --enable-universalsdk=/
   make

To support C data types which vary between 32-bit and 64-bit builds,
Include/pymacconfig.h does some magic conditional type definitions
overriding the standard values derived from autoconf configure
processing.  Previously, SIZEOF_UINTPTR_T was not referenced in
the Python source; now that selectmodule.c uses it, it needs
to be added to pymacconfig.h.  The attached patch does that.

Although the select changes were only added to trunk (r76108)
and py3k (r76111), it would be better to apply this patch to the
maintenance branches as well in the event something else gets
added or backported to them.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: issue-select-kevent-osx.txt
messages: 95851
nosy: ned.deily, pitrou, ronaldoussoren
severity: normal
status: open
title: select module compile errors breaks OS X multi-architecture builds
type: compile error
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15425/issue-select-kevent-osx.txt

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

From report at bugs.python.org  Tue Dec  1 10:05:49 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 09:05:49 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1259658349.84.0.908866646472.issue7380@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15426/issue7380_py3k.diff

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

From report at bugs.python.org  Tue Dec  1 10:05:56 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 09:05:56 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1259658356.75.0.0689897679473.issue7380@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15388/issue7380.diff

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

From report at bugs.python.org  Tue Dec  1 10:08:57 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Dec 2009 09:08:57 +0000
Subject: [issue7211] select module - kevent ident field 64 bit issue
In-Reply-To: <1256586883.91.0.341415015996.issue7211@psf.upfronthosting.co.za>
Message-ID: <1259658537.09.0.350661531186.issue7211@psf.upfronthosting.co.za>


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

This patch causes build errors on 32-bit/64-bit multi-architecture builds 
on OS X.  See Issue7416 for more info and a patch.

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

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

From report at bugs.python.org  Tue Dec  1 11:54:04 2009
From: report at bugs.python.org (egaudry)
Date: Tue, 01 Dec 2009 10:54:04 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1259664844.68.0.308300503824.issue4120@psf.upfronthosting.co.za>


egaudry <eg at fft.be> added the comment:

I came across this (very) interesting thread after experiencing some
redistribution issue with a python(2.6)-based package built with msvc9
compiler.

I used to struggled with the SxS Microsoft policy in the past. After I
finally went for the private assembly/crt runtime redistribution
solution, I always succeeded to deliver a stand-alone package to any
windows host around (I got full control on what's actually build and
distribute). 

Having now (using the disutils module) the manifest file embedded in the
python extension actually forbids this redistribution solution, for the
reasons that have been posted here (SxS policy), unless a private
assembly/crt runtime is provided next to each built extension. IMHO,
this is not a convenient (and common) way to redistribute a software.

This is why I fully agree with the propositions that were made here,
i.e. not embedding manifest into a python extension built with the
distutils module and msvc.

Could anyone tell us if a decision has been made about such a change ?

Thanks,
Eloi

----------
nosy: +egaudry

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

From report at bugs.python.org  Tue Dec  1 11:55:02 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Dec 2009 10:55:02 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259664902.19.0.816425633343.issue7413@psf.upfronthosting.co.za>


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

The patch looks okay to me, and works on 2.7. Although it's slightly out
of date with respect to line numbers, it still applies cleanly.

My trivial suggestions are that I'd replace:
x += PyOS_snprintf(buffer + 8, bufflen - 8, ".%06d", us);
with
x += PyOS_snprintf(buffer + x, bufflen - x, ".%06d", us);
in the extremely unlikely event that the time format string ever
changes. I'd probably also throw in an assert(bufflen >= x).

But these 2 points are nits.

----------
assignee: amaury.forgeotdarc -> 
components: +Extension Modules
nosy: +eric.smith
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Dec  1 14:39:59 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 13:39:59 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259674799.12.0.122080890195.issue7401@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

I have an ADC account that I only ever use to get XCode.  I'll file a
bug-report with Apple.

----------

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

From report at bugs.python.org  Tue Dec  1 14:41:42 2009
From: report at bugs.python.org (ulrik)
Date: Tue, 01 Dec 2009 13:41:42 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>


New submission from ulrik <ulrik.sverdrup at gmail.com>:

Python 3.1.1's open has no signature in the docstring so the
documentation for this builtin function is unfortunately very confusing
(IMO is missing the most important part).

>>> help(open)

open(...)
    Open file and return a stream.  Raise IOError upon failure.
    
    ...

----

This must be a regression from the C port of the io module.

I'm keeping my eyes open for more issues like this. Python must be more
friendly to newcomers, but I have seen tendencies of confusing
documentation in Python 3.

----------
components: Library (Lib)
messages: 95856
nosy: englabenny
severity: normal
status: open
title: open builtin has no signature in docstring
versions: Python 3.1

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

From report at bugs.python.org  Tue Dec  1 15:04:28 2009
From: report at bugs.python.org (Carl Chenet)
Date: Tue, 01 Dec 2009 14:04:28 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>


New submission from Carl Chenet <chaica at ohmytux.com>:

Hi,

The hashlib module could provide a tuple offering the names of the
different hash algorithms which are guaranteed to be supported.

The expected result: 

>>> import hashlib
>>> hashlib.algorithms
('md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512')

Here is a patch to do so. It also provides an update for the hashlib
documentation and a test case.

Bye,
Carl Chenet

----------
components: Library (Lib)
files: algorithms_constant_attribute_in_hashlib_module.diff
keywords: patch
messages: 95857
nosy: chaica_
severity: normal
status: open
title: hashlib : the names of the different hash algorithms
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file15427/algorithms_constant_attribute_in_hashlib_module.diff

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

From report at bugs.python.org  Tue Dec  1 15:48:45 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 14:48:45 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259678925.7.0.115572227093.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Proposed docstring patch.

----------
keywords: +patch
nosy: +flox
versions: +Python 3.2
Added file: http://bugs.python.org/file15428/issue7417_py3k.diff

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

From report at bugs.python.org  Tue Dec  1 15:52:41 2009
From: report at bugs.python.org (Michael Broghton)
Date: Tue, 01 Dec 2009 14:52:41 +0000
Subject: [issue7416] select module compile errors breaks OS X
	multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259679161.26.0.220111234542.issue7416@psf.upfronthosting.co.za>


Changes by Michael Broghton <mbroughton at advanis.ca>:


----------
nosy: +mbroughton

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

From report at bugs.python.org  Tue Dec  1 16:04:11 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2009 15:04:11 +0000
Subject: [issue7416] select module compile errors breaks OS X
	multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259679851.47.0.486417211528.issue7416@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm currently testing a patch that adds the required SIZEOF_ macros to 
pymacconfig.h, simular to how SIZEOF_LONG and SIZEOF_VOIDP are handled.

I expect to commit a fix later today to the 2.7 and 3.2 branches. The new 
SIZEOF_ macros are only needed for new functionality in selectmodule, and 
hence don't need to be backported to 2.6 or 3.1.

----------

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

From report at bugs.python.org  Tue Dec  1 16:20:34 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 15:20:34 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259680834.53.0.81419046657.issue7418@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I guess you missed the quotes.

$ ./python foo.py 
Traceback (most recent call last):
  File "foo.py", line 2, in <module>
    from hashlib import *
TypeError: attribute name must be string, not 'tuple'

----------
nosy: +flox

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

From report at bugs.python.org  Tue Dec  1 16:28:59 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 15:28:59 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259681339.23.0.378441677519.issue7401@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


Removed file: http://bugs.python.org/file15420/os_pipe_write_close_bug.c

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

From report at bugs.python.org  Tue Dec  1 16:31:15 2009
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Dec 2009 15:31:15 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259681475.16.0.604922924463.issue7401@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

Updated the C program to deal with command-line args.  This is the
version submitted to Apple Bug Reporter, issue 7433004.

----------
Added file: http://bugs.python.org/file15429/os_pipe_write_close_bug.c

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

From report at bugs.python.org  Tue Dec  1 16:31:38 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2009 15:31:38 +0000
Subject: [issue7416] select module compile errors breaks OS X
	multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259681498.39.0.46051427818.issue7416@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Hugh: why did you remove the .c file? 

I'd prefer to keep the .c file in the python tracker as, just in case 
someone else runs into the same issue and starts debugging the issue.

----------

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

From report at bugs.python.org  Tue Dec  1 16:36:40 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 15:36:40 +0000
Subject: [issue7419] Crash in _locale.setlocale on windows
In-Reply-To: <1259681799.96.0.766009696643.issue7419@psf.upfronthosting.co.za>
Message-ID: <1259681799.96.0.766009696643.issue7419@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

import _locale
_locale.setlocale(12345)

Crashes on Windows with exit code 0xc0000417, a.k.a
STATUS_INVALID_CRUNTIME_PARAMETER.
2.6 and 3.0 are not affected.

setlocale should check the category before passing it to the C runtime:
   LC_MIN <= category && category <= LC_MAX

----------
components: Windows
messages: 95863
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Crash in _locale.setlocale on windows
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Dec  1 16:44:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 01 Dec 2009 15:44:04 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259682244.36.0.34265312676.issue7401@psf.upfronthosting.co.za>


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

Thanks, closing it here as third-party. Feel free to follow up here with
news on Apple's resolution of the issue.

----------
resolution:  -> wont fix
status: open -> closed
versions: +3rd party

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

From report at bugs.python.org  Tue Dec  1 16:47:48 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2009 15:47:48 +0000
Subject: [issue7401] os.write and os.close on pipe from separate threads hangs
	on Mac OS X
In-Reply-To: <1259277745.82.0.939130045667.issue7401@psf.upfronthosting.co.za>
Message-ID: <1259682468.55.0.428251191293.issue7401@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Hugh: never mind ....


There is a workaround for this issue: use socketpair(2) instead of 
pipe(2). I haven't thought enough about the consequences yet to have an 
firm opinion on implementing os.pipe using socketpair(2) on OSX. My gut 
feeling is that we shouldn't because pipes and sockets can have slightly 
different behavior, especially w.r.t. buffering.

As a workaround for this issue you can at least use socket.socketpair 
instead of os.pipe.

----------

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

From report at bugs.python.org  Tue Dec  1 16:57:05 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2009 15:57:05 +0000
Subject: [issue7416] select module compile errors breaks OS X
	multi-architecture builds
In-Reply-To: <1259658190.83.0.917094385944.issue7416@psf.upfronthosting.co.za>
Message-ID: <1259683025.79.0.417557948169.issue7416@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r76623 (trunk) and r76624 (3.2).

(The commit message mentions another issue, that's a copy-paste error on 
my end)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 17:59:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 16:59:44 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1259686784.62.0.556695652783.issue7317@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Seconded. 
But such messages are also printed when the interpreter exits, when
poorly written __del__ methods access already disposed modules. Raising
a full traceback could cause users to think that the error is more
severe than it is.

Is there an already existing flag that could control this behaviour?
Otherwise, well, just ignore my remark.

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

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

From report at bugs.python.org  Tue Dec  1 18:24:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 01 Dec 2009 17:24:29 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259688269.62.0.572206091214.issue7418@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Dec  1 18:52:14 2009
From: report at bugs.python.org ("Dragon" Dave McKee)
Date: Tue, 01 Dec 2009 17:52:14 +0000
Subject: [issue7420] turtle - turtle.update() doesn't override turtle.tracer()
In-Reply-To: <1259689934.3.0.386654946546.issue7420@psf.upfronthosting.co.za>
Message-ID: <1259689934.3.0.386654946546.issue7420@psf.upfronthosting.co.za>


New submission from "Dragon" Dave McKee <dave.mckee at gmail.com>:

Problem:
Using the following code gives different behaviour on versions 2.6.4 and
3.0.1: nothing will be drawn under 3.0.1, but turtle.update() will force
the line to be drawn under 2.6.4. 2.6.4's behaviour is compatible with
the documentation: "turtle.update() - Perform a TurtleScreen update. To
be used when tracer is turned off."

import turtle
from time import sleep
turtle.tracer(100,0) # update screen after 100 drawings
turtle.fd(100)
turtle.update() # force update
sleep(100) # so you can see what's on the screen.

workaround:
use turtle.tracer(1) after drawing instead of turtle.update()

----------
components: Extension Modules
messages: 95868
nosy: dragon
severity: normal
status: open
title: turtle - turtle.update() doesn't override turtle.tracer()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Dec  1 20:20:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2009 19:20:09 +0000
Subject: [issue6974] test_posix getcwd test leaves tmp  dir
In-Reply-To: <1253684827.18.0.268921836633.issue6974@psf.upfronthosting.co.za>
Message-ID: <1259695209.26.0.356031376772.issue6974@psf.upfronthosting.co.za>


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

This was fixed in response to another bug report a few months ago.

----------
nosy: +r.david.murray
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 20:27:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2009 19:27:32 +0000
Subject: [issue4057] Popen(..., cwd=...) does not set PWD environment variable
In-Reply-To: <1223321283.05.0.79921922605.issue4057@psf.upfronthosting.co.za>
Message-ID: <1259695652.46.0.108450932046.issue4057@psf.upfronthosting.co.za>


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

I agree that this is not something that Popen should be doing.  If you
need the environment variable set, the correct thing to do is what you
did: set it in the environment you pass to Popen.

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

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

From report at bugs.python.org  Tue Dec  1 21:38:20 2009
From: report at bugs.python.org (Angel)
Date: Tue, 01 Dec 2009 20:38:20 +0000
Subject: [issue7421] Given
In-Reply-To: <1259699900.65.0.917773052949.issue7421@psf.upfronthosting.co.za>
Message-ID: <1259699900.65.0.917773052949.issue7421@psf.upfronthosting.co.za>


New submission from Angel <AngelAssasin187 at hotmail.com>:

# Area calculation program

print  "Show Area"
print  "----------------------"
print

# Print out the menu:
print  "Please select a shape:"
print  "1  Rectangle"
print  "2  Circle"

# Get the user&apos;s choice:
shape = input (">  ")

# Calculate the area:
if shape  == 1:
	height  = input ("Please enter the height:  ")
	width  = input ("Please enter the width:  ")
	area = height*width
	print "The area is", area
else:
	radius = input ("Please enter the radius:  ")
	area = 3.14* (radius**2)
	print "The area is", area

----------
components: Windows
messages: 95871
nosy: Fallen
severity: normal
status: open
title: Given
versions: 3rd party

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

From report at bugs.python.org  Tue Dec  1 21:47:37 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Dec 2009 20:47:37 +0000
Subject: [issue7421] Given
In-Reply-To: <1259699900.65.0.917773052949.issue7421@psf.upfronthosting.co.za>
Message-ID: <1259700457.03.0.3001016599.issue7421@psf.upfronthosting.co.za>


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

If you have a question to ask, this is not the proper forum. Please see
python-list http://mail.python.org/mailman/listinfo/python-list

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

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

From report at bugs.python.org  Tue Dec  1 21:50:32 2009
From: report at bugs.python.org (Troy J. Farrell)
Date: Tue, 01 Dec 2009 20:50:32 +0000
Subject: [issue5027] xml namespace not understood by
	xml.sax.saxutils.XMLGenerator
In-Reply-To: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>
Message-ID: <1259700632.38.0.627284490819.issue5027@psf.upfronthosting.co.za>


Troy J. Farrell <troy at entheossoft.com> added the comment:

I've duplicated the issue and the fix using Python 2.6.2.  I'm attaching 
Soren Roug's fix in patch form.  (I created the patch against r53754 of 
saxutils.py.)

----------
keywords: +patch
nosy: +troy
versions: +Python 2.6
Added file: http://bugs.python.org/file15430/saxutils.issue5027.patch

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

From report at bugs.python.org  Tue Dec  1 21:59:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Dec 2009 20:59:00 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1259701140.72.0.317406096845.issue4482@psf.upfronthosting.co.za>


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

This patch has tests that currently pass on trunk. I think this is the
desired behavior. I need to augment the tests for format() testing.

----------
Added file: http://bugs.python.org/file15431/issue4482_tests-1.patch

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

From report at bugs.python.org  Tue Dec  1 22:18:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Dec 2009 21:18:48 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1259702328.21.0.299188675907.issue4482@psf.upfronthosting.co.za>


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

Looks good to me, except that the second comment in the patch doesn't make 
a lot of sense any more.

----------

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

From report at bugs.python.org  Tue Dec  1 22:33:59 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Dec 2009 21:33:59 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1259703239.4.0.807062402018.issue4482@psf.upfronthosting.co.za>


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

This version adds format() testing and fixes the comments (I hope).

----------
Added file: http://bugs.python.org/file15432/issue4482_tests-2.patch

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

From report at bugs.python.org  Tue Dec  1 22:35:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Dec 2009 21:35:23 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259703323.72.0.0343025201114.issue7417@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good to me (module indentation).

----------
assignee:  -> pitrou
nosy: +georg.brandl, pitrou

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

From report at bugs.python.org  Tue Dec  1 22:35:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Dec 2009 21:35:33 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259703333.05.0.108240775863.issue7417@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Make that "modulo."

----------

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

From report at bugs.python.org  Tue Dec  1 22:38:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Dec 2009 21:38:14 +0000
Subject: [issue7422] Document inspect.get(full)argspec limitation to Python
	function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"inspect.getargspec(func) 
Get the names and default values of a function?s arguments. "
"inspect.getfullargspec(func) 
Get the names and default values of a function?s arguments."

'Function' must be a Python function (or a bound method wrapper
thereof). (Some posted this 'discovery' on python-list today, so it is
not obvious to everyone.)

Suggestion: insert 'Python' before "function's"
or rewrite as
"Get the names and default values of the arguments of a Python function
or bound method."

This is a different request from #1748064, which requested that the
limitation be removed.

----------
assignee: georg.brandl
components: Documentation
messages: 95879
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document inspect.get(full)argspec limitation to Python function
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  1 22:53:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Dec 2009 21:53:20 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1259704400.21.0.196430886553.issue4482@psf.upfronthosting.co.za>


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

LGTM.

----------

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

From report at bugs.python.org  Tue Dec  1 23:04:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 22:04:06 +0000
Subject: [issue7419] Crash in _locale.setlocale on windows
In-Reply-To: <1259681799.96.0.766009696643.issue7419@psf.upfronthosting.co.za>
Message-ID: <1259705046.37.0.946108905005.issue7419@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r76625 (trunk), r76626 (py3k) and r76627 (relase31-maint)

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

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

From report at bugs.python.org  Tue Dec  1 23:18:21 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Dec 2009 22:18:21 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259705901.43.0.657306538051.issue7413@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a new patch against a fresh trunk, and with the suggested changes: 
they indeed make the code more consistent with other parts.

----------
keywords: +needs review
Added file: http://bugs.python.org/file15433/isoformat-2.patch

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

From report at bugs.python.org  Tue Dec  1 23:43:56 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 01 Dec 2009 22:43:56 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1259707436.8.0.327981816934.issue7413@psf.upfronthosting.co.za>


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

I think you need to put an assert before the line with bufflen-x, since
that's the calculation you're trying to ensure doesn't underflow. And I
guess that technically you should inspect the result of PyOS_snprintf
for an error, but given that we know the buffer sizes it's not so important.

Other than that, looks good. Sorry for the piecemeal patch review.

----------

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

From report at bugs.python.org  Wed Dec  2 00:19:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2009 23:19:40 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259709580.69.0.608469169698.issue7327@psf.upfronthosting.co.za>


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

In python3:

>>> locale.setlocale(locale.LC_NUMERIC, "cs_CZ.UTF-8")
'cs_CZ.UTF-8'
>>> s = format(Decimal("-1.5"),  ' 019.18n')
>>> len(s)
20
>>> print(s)
-0?000?000?000?001,5

Python3 uses unicode for strings.  Python2 uses bytes.  To format
unicode in python2, you do:

>>> s2 = locale.format("% 019.18g", Decimal("-1.5"))
>>> len(s2)
19
>>> print s2
-0000000000000001,5

Not quite the same thing, clearly.  So, is there a way to access the
python3 unicode format semantics in python2?  Just passing format a
unicode format string results in a UnicodeDecodeError.

----------
nosy: +r.david.murray
priority:  -> normal
type:  -> behavior
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Dec  2 00:20:33 2009
From: report at bugs.python.org (flox)
Date: Tue, 01 Dec 2009 23:20:33 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259709633.0.0.563158118786.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Indentation is not easy on this part.
The list of arguments overflow the 79 chars limit.
With the proposed patch, the generated output is something like:


open(file, mode='r', buffering=None, encoding=None,
           errors=None, newline=None, closefd=True) -> file object

Open file and return a stream.  Raise IOError upon failure.

...


Is it wrong?

----------

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

From report at bugs.python.org  Wed Dec  2 00:38:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2009 23:38:23 +0000
Subject: [issue7420] turtle - turtle.update() doesn't override turtle.tracer()
In-Reply-To: <1259689934.3.0.386654946546.issue7420@psf.upfronthosting.co.za>
Message-ID: <1259710703.02.0.118003383129.issue7420@psf.upfronthosting.co.za>


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

I see a line when I try this on 3.1 and trunk.  There were some updates,
so I suppose this has been fixed.  3.0 has been replaced by 3.1 and is
no longer maintained.

----------
nosy: +gregorlingl, r.david.murray
priority:  -> normal
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Dec  2 01:05:58 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 00:05:58 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259712358.42.0.0697426569335.issue7327@psf.upfronthosting.co.za>


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

In 2.7, I get:

$ ./python.exe 
Python 2.7a0 (trunk:76501, Nov 24 2009, 14:57:21) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, "cs_CZ.UTF-8")
'cs_CZ.UTF-8'
>>> from decimal import Decimal
>>> s = format(Decimal("-1.5"),  ' 019.18n')
>>> s
'-0 000 000 000 001,5'
>>> len(s)
20
>>> s = format(Decimal("-1.5"),  u' 019.18n')                           
>>> s
u'-0 000 000 000 001,5'
>>> len(s)
20
>>> 

Could you give more details on the UnicodeDecodeError you get? Any
traceback?

----------

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

From report at bugs.python.org  Wed Dec  2 01:29:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Dec 2009 00:29:05 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259713745.75.0.958341564699.issue7327@psf.upfronthosting.co.za>


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

Interesting.  My regular locale is LC_CTYPE=en_US.UTF-8, and here is
what I get:

Python 2.7a0 (trunk:76501, Nov 24 2009, 13:59:01) 
[GCC 4.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import local
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, "cs_CZ.UTF-8")
'cs_CZ.UTF-8'
>>> from decimal import Decimal
>>> s = format(Decimal("-1.5"),  ' 019.18n')
>>> s
'-0\xc2\xa0000\xc2\xa0000\xc2\xa0001,5'
>>> len(s)
19
>>> print s
-0?000?000?001,5

sys.stdout.encoding gives 'UTF-8'.

And here's the traceback from trying to use unicode:

>>> s = format(Decimal("-1.5"),  u' 019.18n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/trunk/Lib/decimal.py", line 3609, in
__format__
    return _format_number(self._sign, intpart, fracpart, exp, spec)
  File "/home/rdmurray/python/trunk/Lib/decimal.py", line 5704, in
_format_number
    return _format_align(sign, intpart+fracpart, spec)
  File "/home/rdmurray/python/trunk/Lib/decimal.py", line 5595, in
_format_align
    result = unicode(result)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 2:
ordinal not in range(128)

----------

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

From report at bugs.python.org  Wed Dec  2 01:57:29 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Dec 2009 00:57:29 +0000
Subject: [issue7422] Document inspect.get(full)argspec limitation to Python
	function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1259715449.4.0.379400011094.issue7422@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just in case anyone else gets confused, Terry's desire for the 
clarification is that getargspec() won't work with functions originating 
from an extension module.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Wed Dec  2 02:34:25 2009
From: report at bugs.python.org (bogklug)
Date: Wed, 02 Dec 2009 01:34:25 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>


New submission from bogklug <bogklug at gmail.com>:

The first of the two maps below gives strange result due to the nested
generator expression (I guess it should give the same result as the
second map).

In [1]: map(list, [(x+y for y in 'c') for x in 'ab'])
Out[1]: [['bc'], ['bc']]

In [2]: map(list, [[x+y for y in 'c'] for x in 'ab'])
Out[2]: [['ac'], ['bc']]

----------
components: Interpreter Core
messages: 95890
nosy: bogklug
severity: normal
status: open
title: nested generator expression produces strange results
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Dec  2 02:55:49 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Dec 2009 01:55:49 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1259718949.09.0.962538369968.issue7423@psf.upfronthosting.co.za>


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

By using a generator expression, you are deferring evaluation of the
expression until map() is actually invoked. By that time, the closure
over 'x' has been changed to 'b', so when the genexp is forced, 'x'
yields 'b' each time.

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

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

From report at bugs.python.org  Wed Dec  2 03:04:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Dec 2009 02:04:02 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1259719442.35.0.719048596446.issue7423@psf.upfronthosting.co.za>


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

I'd already written then when Benjamin posted his answer, but rather
than waste having written it I'm going to post it anyway :)

You must remember that the purpose of a generator is to evaluate lazily.
 Your expression involving the generator would unwrap this way:

def g1():
    for y in 'c':
        yield x+y
l = []
for x in 'ab':
    l.append(g1())
print l
print map(list, l)

If you run this you will note that 'l' is a pair of generator instances.
 These are not run until the 'map' is executed. By that point the for
loop has completed, and x has its final value, 'b'.  g1 is evaluated
twice, and both times x is 'b', so you get ['bc', 'bc']

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Dec  2 03:16:53 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Dec 2009 02:16:53 +0000
Subject: [issue7422] Document inspect.get(full)argspec limitation to Python
	function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1259720213.47.0.917953675397.issue7422@psf.upfronthosting.co.za>


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

Sorry, you confuse me a bit. get(full)argspec also does not work with
builtins. I am asking that the doc be clarified to match behavior so
that people are not surprised by
TypeError: arg is not a Python function
as in written in Python versus C.

----------

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

From report at bugs.python.org  Wed Dec  2 04:00:21 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 03:00:21 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259722821.32.0.771579528098.issue7327@psf.upfronthosting.co.za>


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

I can duplicate this on Linux. The difference is the values in the
locale for the separators, specifically,
locale.localeconv()['thousands_sep'].

>>> locale.localeconv()['thousands_sep']
'\xc2\xa0'

The question is: since a struct lconv contains char*s, how to interpret
them? The code in decimal interprets them as ascii, apparently. floats
do the same thing, so this isn't strictly a decimal problem. I'll have
to give it some thought.

----------

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

From report at bugs.python.org  Wed Dec  2 05:57:18 2009
From: report at bugs.python.org (Jon Buller)
Date: Wed, 02 Dec 2009 04:57:18 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>


New submission from Jon Buller <jon at bullers.net>:

On a NetBSD/sparc-current system building from the 2.6.4.tgz file...

Compiling /usr/pkg/lib/python2.6/test/test_bool.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb185.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bsddb3.py ...
Compiling /usr/pkg/lib/python2.6/test/test_buffer.py ...
Compiling /usr/pkg/lib/python2.6/test/test_bufio.py ...
Compiling /usr/pkg/lib/python2.6/test/test_builtin.py ...
[1]   Segmentation fault (core dumped) PYTHONPATH=/usr/...
*** Error code 139

Stop.


and GDB says...

Reading symbols from /usr/lib/libc.so.12...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.15-sparc-2.6/unicodedata.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.15-sparc-2.6/unicodedata.so
Reading symbols from /usr/libexec/ld.elf_so...(no debugging symbols
found)...done.
Loaded symbols for /usr/libexec/ld.elf_so

Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0  0x200b7bac in listextend ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
(gdb) where
#0  0x200b7bac in listextend ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#1  0x20087b00 in PySequence_List ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#2  0x20129760 in assemble ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6..so.1.0
#3  0x2012e12c in compiler_function ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#4  0x2012e288 in compiler_body ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#5  0x2012e498 in compiler_class ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#6  0x2012e288 in compiler_body ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#7  0x2012e958 in PyAST_Compile ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0
#8  0x20142a48 in Py_CompileStringFlags ()
   from /usr/pkgsrc/lang/python26/work/Python-2.6.4/libpython2.6.so.1.0

...

----------
components: Installation
messages: 95895
nosy: jon at bullers.net
severity: normal
status: open
title: segmentation fault in listextend during install
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec  2 08:33:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Dec 2009 07:33:02 +0000
Subject: [issue7422] Document inspect.get(full)argspec limitation to Python
	function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1259739182.4.0.818581242638.issue7422@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's basically what I said.

----------

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

From report at bugs.python.org  Wed Dec  2 08:59:41 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 07:59:41 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259740781.57.0.690281037671.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

According to PEP257:
?Multi-line docstrings consist of a summary line just like a one-line
docstring, followed by a blank line, followed by a more elaborate
description.?

Maybe this second patch is more conventional?

----------
Added file: http://bugs.python.org/file15434/issue7417_py3k_pep257.diff

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

From report at bugs.python.org  Wed Dec  2 09:14:04 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 08:14:04 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1259741644.06.0.941166256485.issue691291@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15435/issue691291.diff

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

From report at bugs.python.org  Wed Dec  2 09:14:22 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 08:14:22 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1259741662.4.0.253956017876.issue691291@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15422/issue691291.diff

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

From report at bugs.python.org  Wed Dec  2 09:21:14 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 08:21:14 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259742074.82.0.757969846951.issue7417@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15434/issue7417_py3k_pep257.diff

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

From report at bugs.python.org  Wed Dec  2 09:21:18 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 08:21:18 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259742078.65.0.867611542671.issue7417@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15428/issue7417_py3k.diff

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

From report at bugs.python.org  Wed Dec  2 09:22:43 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 08:22:43 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259742163.31.0.298884178545.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Actually the docstring of _pyio.open Python function should not change.

The patch is smaller.

----------
Added file: http://bugs.python.org/file15436/issue7417_py3k.diff

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

From report at bugs.python.org  Wed Dec  2 09:58:46 2009
From: report at bugs.python.org (Carl Chenet)
Date: Wed, 02 Dec 2009 08:58:46 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259744326.85.0.702125852963.issue7418@psf.upfronthosting.co.za>


Carl Chenet <chaica at ohmytux.com> added the comment:

flox : You're right, sorry about that.

Here is a fixed patch.

----------
Added file: http://bugs.python.org/file15437/algorithms_constant_value_in_hashlib_module.diff

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

From report at bugs.python.org  Wed Dec  2 10:01:52 2009
From: report at bugs.python.org (Carl Chenet)
Date: Wed, 02 Dec 2009 09:01:52 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259744512.61.0.676556792018.issue7418@psf.upfronthosting.co.za>


Changes by Carl Chenet <chaica at ohmytux.com>:


Removed file: http://bugs.python.org/file15437/algorithms_constant_value_in_hashlib_module.diff

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

From report at bugs.python.org  Wed Dec  2 10:05:54 2009
From: report at bugs.python.org (Carl Chenet)
Date: Wed, 02 Dec 2009 09:05:54 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1259744754.8.0.280798182724.issue7418@psf.upfronthosting.co.za>


Carl Chenet <chaica at ohmytux.com> added the comment:

The fixed file :
algorithms_constant_attribute_in_hashlib_module_update1.diff

----------
Added file: http://bugs.python.org/file15438/algorithms_constant_attribute_in_hashlib_module_update1.diff

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

From report at bugs.python.org  Wed Dec  2 11:42:07 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 02 Dec 2009 10:42:07 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259750527.03.0.634679225214.issue7327@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

In python3.2, the output of decimal looks good. With float, the
separator is printed as two spaces on my Unicode terminal (export
LC_ALL=cs_CZ.UTF-8).

So decimal (3.2) interprets the separator string as a single UTF-8 char
and the final output is a UTF-8 string. I'd say that in C, this is the
intended way of using struct lconv.

If there is an agreement that the final output should be a UTF-8 string,
this looks correct to me.



Python 3.2a0 (py3k:76081M, Nov  6 2009, 15:23:48) 
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale, decimal
>>> locale.setlocale(locale.LC_NUMERIC, 'cs_CZ.UTF-8')
'cs_CZ.UTF-8'
>>> x = format(decimal.Decimal("-1.5"),  '019.18n')
>>> y = format(float("-1.5"),  '019.18n')
>>> x
'-0\xa0000\xa0000\xa0000\xa0001,5'
>>> y
'-0??000??000??001,5'
>>> print(x)
-0?000?000?000?001,5
>>> print(y)
-0??000??000??001,5
>>>

----------

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

From report at bugs.python.org  Wed Dec  2 12:53:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Dec 2009 11:53:51 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259754831.15.0.746871821635.issue7327@psf.upfronthosting.co.za>


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

So when the format string has type 'str' (as in Stefan's original example) 
rather than type 'unicode', I'd say Python is doing the right thing 
already:  everything in sight, including the separators coming from 
localeconv(), has type 'str', so trying to interpret things as unicode 
seems a bit of a stretch.

If the '\xc2\xa0' from localeconv()['thousands_sep'] is to be interpreted 
as a single unicode character, shouldn't it be a unicode
string already?

However, if localeconv()['thousands_sep'] *were* to give a unicode string, 
then I suppose Decimal.__format__ should be returning a unicode result;  I 
don't think it currently does this.  (Should this be true even if the 
number being formatted is so short that no thousands separators actually 
appear in it?)

----------

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

From report at bugs.python.org  Wed Dec  2 14:12:12 2009
From: report at bugs.python.org (Ulrik Sverdrup)
Date: Wed, 02 Dec 2009 13:12:12 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259759532.86.0.372650893421.issue7417@psf.upfronthosting.co.za>


Ulrik Sverdrup <ulrik.sverdrup at gmail.com> added the comment:

import builtins; help(builtins)

Looking around, the new suggestion is absolutely unconventional. The
signature must be on the first line. One builtin function even uses two
lines; min:

        min(iterable[, key=func]) -> value
        min(a, b, c, ...[, key=func]) -> value
        
        With a single iterable argument, return its smallest item.
        With two or more arguments, return the smallest argument.

I would ack a two-line signature at the start of the docstring, however
I will also suggest an alternative:

Aligning open's signature description with the builtins module, this is
the style that is most common:

open(file[, mode[, buffering[, encoding[, errors[, newline[,
closefd]]]]]]) -> file object

perhaps even an abbreviation is allowed at the end?

open(file[, mode[, buffering[, encoding[, errors[, newline[,
closefd]..]) -> file object

However that open has so many kwargs should almost be a bug in itself.

----------

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

From report at bugs.python.org  Wed Dec  2 14:15:12 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 13:15:12 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259759712.36.0.151983769546.issue7327@psf.upfronthosting.co.za>


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

I don't see any documentation that a struct lconv should be interpreted
as UTF-8. In fact Googling "struct lconv utf-8" gives this bug report as
the first hit.

lconv.thousands_sep is char*. It's never been clear to me if this means
"pointer to a single char", or "pointer to a null terminated string of
char". In Objects/stringlib/localeutil.h I treat it as a string of char.

----------

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

From report at bugs.python.org  Wed Dec  2 14:21:19 2009
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 02 Dec 2009 13:21:19 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1259760079.78.0.50857751002.issue1100942@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


----------
nosy: +guettli

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

From report at bugs.python.org  Wed Dec  2 14:54:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Dec 2009 13:54:51 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1259762091.2.0.528890791751.issue7333@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The documentation is os.rst is too laconic (coming from the Windows
world, I could not understand what the function is about).
The docstring is much better (at least I understand it's related to the
Unix security model), I suggest to use it for the documentation.

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

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

From report at bugs.python.org  Wed Dec  2 14:58:17 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 13:58:17 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259762297.54.0.254313437211.issue7327@psf.upfronthosting.co.za>


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

In trunk, Modules/_localemodule.c also treats these as "string of char",
so at least we're consistent.

In py3k, mbstowcs is used and the result passed to PyUnicode_FromWideChar.

I'm not sure how you'd address this in locale in trunk, or if we want to
do something similar in localeutil.h in trunk (for the Unicode case).

----------

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

From report at bugs.python.org  Wed Dec  2 15:10:40 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 02 Dec 2009 14:10:40 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259763040.36.0.785194835539.issue7327@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Googling "multi-byte thousands separator" gives better results. From
those results, it is clear to me that decimal_point and thousands_sep
are strings that may be interpreted as multi-byte characters. The Czech
separator appears to be a no-break space multi-byte character.


http://sourceware.org/ml/libc-hacker/2007-01/msg00005.html
http://drupal.org/node/353897


My point is that if a multi-byte character appears, it should be
counted as a single character for the purposes of calculating
min-width. Otherwise, the printed representation is too short.

----------

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

From report at bugs.python.org  Wed Dec  2 15:37:33 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 14:37:33 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259764653.34.0.568646344512.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Ulrik,

I agree that most builtins have the signature on first lines.
I will not apply this part of the PEP257.

But it seems that the "[...]" syntax is not enforced for all builtins.
See "help(print)", "help(sorted)" and "help(__import__)" examples:

>>> print(print.__doc__)
print(value, ..., sep=' ', end='\n', file=sys.stdout)

Prints the values to a stream, or to sys.stdout by default.
Optional keyword arguments:
file: a file-like object (stream); defaults to the current sys.stdout.
sep:  string inserted between values, default a space.
end:  string appended after the last value, default a newline.

>>> print(sorted.__doc__)
sorted(iterable, key=None, reverse=False) --> new sorted list

>>> print(__import__.__doc__)
__import__(name, globals={}, locals={}, fromlist=[], level=-1) -> module

Import a module.  The globals are only used to determine the context;
they are not modified...



Patch is updated.

----------
Added file: http://bugs.python.org/file15439/issue7417_py3k.diff

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

From report at bugs.python.org  Wed Dec  2 15:37:47 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 14:37:47 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259764667.35.0.986363336855.issue7417@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15436/issue7417_py3k.diff

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

From report at bugs.python.org  Wed Dec  2 16:34:55 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 02 Dec 2009 15:34:55 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1259768095.93.0.921742810026.issue7333@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

New version attached which makes the os.rst docs the same as the
docstring.  Also fixes a conflict since introduced in trunk in configure.in.

----------
Added file: http://bugs.python.org/file15440/initgroups-5.patch

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

From report at bugs.python.org  Wed Dec  2 16:35:30 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 15:35:30 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259768130.67.0.0426534583372.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Or I suggest something more verbose...


>>> print(open.__doc__)
open(filename) -> file object for reading in text mode

open(filename, mode=binary[, buffering]) -> file object in binary mode
open(filename[, mode=text][, buffering][,encoding][,errors][,newline])
                                         -> file object in text mode

open(file_descriptor[, ...][, closefd]) -> file object

Open file and return a stream.  Raise IOError upon failure.

filename is either a text or byte string giving the name (and the path
if the file isn't in the current working directory) of the file to
be opened.

file_descriptor is an integer file descriptor of the file to be
wrapped. The file descriptor is closed when the returned I/O object is
closed, unless closefd is set to False.)

mode is an optional string that specifies the mode in which the file
is opened...

----------

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

From report at bugs.python.org  Wed Dec  2 17:06:30 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 16:06:30 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259769990.39.0.639942602631.issue7417@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

(patch attached: explicit signature)

I vote +1 for something more explicit.
? Explicit is better than implicit. ?

>>> help(open)
Help on built-in function open in module io:

open(...)
    open(file_name_or_path) -> file object for reading in text mode
    open(file_name_or_path, mode=binary_mode[, buffering]) -> file objec
    open(file_name_or_path[, mode=text_mode[, buffering[, encoding
                          [, errors[, newline]]]]]) -> file object
    open(file_descriptor[, ...[, closefd]]) -> file object
    
    Open file and return a stream.  Raise IOError upon failure.
    
    file_name_or_path is either a text or byte string giving the name
    (and the path if the file isn't in the current working directory)
    of the file to be opened.
    
    file_descriptor is an integer file descriptor of the file to be
    wrapped. The file descriptor is closed when the returned I/O object
    is closed, unless closefd is set to False.)
    
    mode is an optional string that specifies the mode in which the file
    is opened...

----------
Added file: http://bugs.python.org/file15441/issue7417_py3k_explicit.diff

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

From report at bugs.python.org  Wed Dec  2 17:11:22 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 16:11:22 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259770282.9.0.506957915889.issue7417@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15442/issue7417_py3k_explicit.diff

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

From report at bugs.python.org  Wed Dec  2 17:11:28 2009
From: report at bugs.python.org (flox)
Date: Wed, 02 Dec 2009 16:11:28 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1259770288.18.0.0851983507495.issue7417@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15441/issue7417_py3k_explicit.diff

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

From report at bugs.python.org  Wed Dec  2 18:44:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Dec 2009 17:44:22 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259775862.69.0.0576053784244.issue7406@psf.upfronthosting.co.za>


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

Fixed int_sub, int_add, int_mul, and the fast paths for BINARY_ADD and 
BINARY_SUB in ceval.c, in r76629 (trunk) and r76630 (release26-maint).

----------

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

From report at bugs.python.org  Wed Dec  2 18:44:40 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 17:44:40 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1259775880.67.0.133592991382.issue7094@psf.upfronthosting.co.za>


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

When and if this is implemented, there's a test in test_float.py that
needs to be deleted. Search on "if not '#' in fmt:", added in r76632.

----------

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

From report at bugs.python.org  Wed Dec  2 19:03:16 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Dec 2009 18:03:16 +0000
Subject: [issue4482] 10e667.__format__('+') should return 'inf'
In-Reply-To: <1228153945.74.0.126553636811.issue4482@psf.upfronthosting.co.za>
Message-ID: <1259776996.33.0.21567093679.issue4482@psf.upfronthosting.co.za>


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

Added tests to trunk in r76632 and py3k in r76634.

Note that the only thing that was changed are the tests. The actual
functionality was fixed earlier when the float formatting was reworked
as part of the short float repr changes.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  2 19:47:08 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Wed, 02 Dec 2009 18:47:08 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259779628.08.0.457204452131.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

Hi,
I'm sorry for delay, I was busy. Here is a test data file:
http://www.lns.cornell.edu/~vk/files/mangled.json

Its size is 150 MB, 50MB less of original, due to scrambled values I was 
forced to do.

The tests with stock json module in python 2.6.2 is 2GB
source = open('mangled.json', 'r')
data = json.load(source)

Using simplejson 2.0.9 from PyPi I saw the same performance, please note 
_speedups.so C module was compiled.

Using cjson module, I observed 180MB of RAM utilization
source = open('mangled.json', 'r')
data = cjson.encode(source.read())

cjson is about 10 times faster!

I re-factor code which deals with XML version of the same data and I was 
able to process it using cElementTree only using 20MB (!) of RAM.

----------

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

From report at bugs.python.org  Wed Dec  2 20:03:19 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 02 Dec 2009 19:03:19 +0000
Subject: [issue1448060] gettext.py breaks on plural-forms header (PATCH)
Message-ID: <1259780599.14.0.450187945214.issue1448060@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/issue1448060>
_______________________________________

From report at bugs.python.org  Wed Dec  2 21:17:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Dec 2009 20:17:28 +0000
Subject: [issue1747858] chown broken on 64bit
Message-ID: <1259785048.81.0.771770414248.issue1747858@psf.upfronthosting.co.za>


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

Looking at posixmodule.c, perhaps other instances of parsing an uid_t or
a gid_t should have been fixed too (lchown, fchown for example)?

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Dec  2 21:47:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Dec 2009 20:47:26 +0000
Subject: [issue7333] Add initgroups to the posix/os modules
In-Reply-To: <1258383460.23.0.536261315778.issue7333@psf.upfronthosting.co.za>
Message-ID: <1259786846.55.0.433270622241.issue7333@psf.upfronthosting.co.za>


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

Slightly modified and committed in r76636 (trunk) and r76637 (py3k).
Thank you.

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

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

From report at bugs.python.org  Wed Dec  2 21:49:32 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 02 Dec 2009 20:49:32 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>


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

I see occasional failures where a broken module prevents "pydoc -k" ("apropos") from working.

Examples of failures (from our downstream bug tracker) are:
https://bugzilla.redhat.com/show_bug.cgi?id=461419 : "pydoc -k" yields "NameError: name 'wglUseFontBitmapsW' is not 
defined"
(a broken OpenGL/WGL/__init__.py module)

https://bugzilla.redhat.com/show_bug.cgi?id=447779 : "pydoc turbogears" doesn't work
(broken TurboGears module)

https://bugzilla.redhat.com/show_bug.cgi?id=246212 : "pydoc -k searchterm" MemoryError. permission denied.
(module only intended to be importable as "root" user)

In each case one or more of the many modules on the system are broken, and importing them leads to an exception being 
raised that isn't ImportError.

In each case, the exception bubbles up through the pydoc call ands leads to it exiting.

Obviously the broken modules should be fixed, but it seems to me that pydoc could be more robust against this situation.

I'm attaching a simple patch which makes "pydoc -k" more robust against this situation, by silently discarding all 
exceptions raised by imported modules.

How does this look?

One downstream bug report requested taking it further:
> Running "pydoc -k" should catch all exceptions while importing modules, and
> display failed modules _after_ all positive keyword matches (not in between).
> It also should redirect stdout/stderr while importing so error message e.a.
> don't clutter up the list of hits.  
to deal with broken modules that spew error messages (this was in https://bugzilla.redhat.com/show_bug.cgi?id=461419#c3 
); I've seen some do it to stdout and some to stderr.

How does this sound?  I can try to update the patch for this too, if this sounds sane to you.

----------
components: Demos and Tools
files: make-pydoc-more-robust-001.patch
keywords: patch
messages: 95918
nosy: dmalcolm
severity: normal
status: open
title: [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules
versions: Python 2.6
Added file: http://bugs.python.org/file15443/make-pydoc-more-robust-001.patch

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

From report at bugs.python.org  Wed Dec  2 22:29:04 2009
From: report at bugs.python.org (Wil Clouser)
Date: Wed, 02 Dec 2009 21:29:04 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1259789344.73.0.787900582707.issue2504@psf.upfronthosting.co.za>


Changes by Wil Clouser <clouserw at gmail.com>:


----------
nosy: +clouserw

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

From report at bugs.python.org  Wed Dec  2 23:19:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Dec 2009 22:19:17 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1259779628.08.0.457204452131.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259792382.3319.8.camel@localhost>


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

> Using cjson module, I observed 180MB of RAM utilization
> source = open('mangled.json', 'r')
> data = cjson.encode(source.read())
> 
> cjson is about 10 times faster!

This is simply wrong. You should be using cjson.decode(), not
cjson.encode().
If you do so, you will see that cjson tajes as much as memory as
simplejson and is actually a bit slower.

Looking at your json file, I would have a couple of suggestions:
- don't quote integers and floats, so that they are decoded as Python
ints and floats rather than strings
- if the same structure is used a large number of times, don't use
objects, use lists instead

----------

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

From report at bugs.python.org  Wed Dec  2 23:32:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Dec 2009 22:32:22 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259793142.93.0.258059718155.issue6594@psf.upfronthosting.co.za>


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

That said, it is possible to further improve json by reducing the number
of memory allocations and temporary copies. Here is an experimental
(meaning: not polished) patch which gains 40% in decoding speed in your
example (9 seconds versus 15).

We could also add an option to intern object keys when decoding (which
wins 400MB in your example); or, alternatively, have an internal "memo"
remembering already seen keys and avoiding duplicates.

----------
keywords: +patch
Added file: http://bugs.python.org/file15444/json-opts.patch

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

From report at bugs.python.org  Wed Dec  2 23:53:19 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Wed, 02 Dec 2009 22:53:19 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259794399.1.0.592102419809.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

Oops, that's explain why I saw such small memory usage with cjson. I 
constructed tests on a fly.

Regarding the data structure. Unfortunately it's out of my hands. The 
data comes from data-service. So, I can't do much and can only report to 
developers. 

I'll try your patch tomorrow. Obviously it's a huge gain, both in memory 
footprint and CPU usage.

Thanks.
Valentin.

----------

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

From report at bugs.python.org  Thu Dec  3 03:42:16 2009
From: report at bugs.python.org (Robert Collins)
Date: Thu, 03 Dec 2009 02:42:16 +0000
Subject: [issue2422] Automatically disable pymalloc when running under valgrind
In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
Message-ID: <1259808136.53.0.417581391143.issue2422@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Thu Dec  3 03:42:49 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Thu, 03 Dec 2009 02:42:49 +0000
Subject: [issue7177] Unclear warning for subprocess.call
In-Reply-To: <1256070005.74.0.0266256477403.issue7177@psf.upfronthosting.co.za>
Message-ID: <1259808169.78.0.373686390327.issue7177@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Improved in r76640 / r76641 to explicitly mention this applies to 
stdout/err=PIPE

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

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

From report at bugs.python.org  Thu Dec  3 03:58:01 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Dec 2009 02:58:01 +0000
Subject: [issue2422] Automatically disable pymalloc when running under valgrind
In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
Message-ID: <1259809081.49.0.481810488844.issue2422@psf.upfronthosting.co.za>


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

Thank you. Applied in r76644.

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

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

From report at bugs.python.org  Thu Dec  3 11:12:53 2009
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Thu, 03 Dec 2009 10:12:53 +0000
Subject: [issue7426] StringIO and with statement
In-Reply-To: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
Message-ID: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

When toying with the "with" statement, I fell on this:

Python 2.6.4

>>> with open('abc.txt', 'r') as f:
        for line in f:
            print line.rstrip()
            
abc
def
>>> 
>>> import StringIO
>>> fo = StringIO.StringIO('abc\ndef\n')
>>> fo.seek(0)
>>> with fo as f2:
        for line in f2:
            print line.rstrip()
            
Traceback (most recent call last):
  File "<psi last command>", line 2, in <module>
AttributeError: StringIO instance has no attribute '__exit__'
>>> 
>>> 

Same result with cStringIO

-----

Python 3.1.1

>>> fo = io.StringIO('abc\ndef\n')
>>> fo.seek(0)
0
>>> with fo as f:
	for line in f:
	    print(line.rstrip())

	    
abc
def
>>>

----------
components: None
messages: 95924
nosy: jmfauth
severity: normal
status: open
title: StringIO and with statement
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  3 11:57:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Dec 2009 10:57:47 +0000
Subject: [issue7426] StringIO and with statement
In-Reply-To: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
Message-ID: <1259837868.0.0.12412808545.issue7426@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Thu Dec  3 12:02:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Dec 2009 11:02:29 +0000
Subject: [issue7414] Format code "C" is missing from skipitem() in getargs.c
In-Reply-To: <1259644116.32.0.35772934709.issue7414@psf.upfronthosting.co.za>
Message-ID: <1259838149.29.0.953146833049.issue7414@psf.upfronthosting.co.za>


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

Thanks!  Fixed in r76646 (py3k) and r76647 (release31-maint).

----------
nosy: +mark.dickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Thu Dec  3 12:19:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Dec 2009 11:19:15 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259839155.61.0.0640610240602.issue7327@psf.upfronthosting.co.za>


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

Reassigning to Eric.

----------
assignee: mark.dickinson -> eric.smith

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

From report at bugs.python.org  Thu Dec  3 12:21:27 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 03 Dec 2009 11:21:27 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259839287.12.0.756940753832.issue7327@psf.upfronthosting.co.za>


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

I've raised the issue with unicode and locale on python-dev:
http://mail.python.org/pipermail/python-dev/2009-December/094408.html

Pending the outcome of that decision, I'll move forward on this issue.

----------

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

From report at bugs.python.org  Thu Dec  3 13:17:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Dec 2009 12:17:38 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1259842658.52.0.569689440596.issue6985@psf.upfronthosting.co.za>


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

I suspect the ints in builtin_range should have been changed to Py_ssize_t 
when PEP 353 was implemented.  I've fixed them in trunk in r76625;  it 
doesn't seem worth changing this in the 2.6 branch.

So on an LP64 machine with sufficient memory, range(2**31) should now 
work.

----------

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

From report at bugs.python.org  Thu Dec  3 13:21:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Dec 2009 12:21:15 +0000
Subject: [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1259842875.76.0.669496539825.issue6985@psf.upfronthosting.co.za>


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

Whoops. That revision number should have been r76648.

----------

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

From report at bugs.python.org  Thu Dec  3 14:17:45 2009
From: report at bugs.python.org (David Narayan)
Date: Thu, 03 Dec 2009 13:17:45 +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: <1259846265.89.0.0139725488342.issue6645@psf.upfronthosting.co.za>


David Narayan <david.narayan at gmail.com> added the comment:

This is a patch that I have used on AIX. The idea for this patch came
from uuid.py. This patch was created against Python 2.6.4.

----------
keywords: +patch
nosy: +davidnarayan
Added file: http://bugs.python.org/file15445/multiprocessing-urandom-fallback.patch

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

From report at bugs.python.org  Thu Dec  3 14:24:26 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 03 Dec 2009 13:24:26 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1259846666.03.0.791565314544.issue6895@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Dec  3 14:31:31 2009
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 03 Dec 2009 13:31:31 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1259847091.4.0.486181214993.issue5985@psf.upfronthosting.co.za>


Erik Carstensen <sandberg at virtutech.com> added the comment:

> Once I considered this approach, but problems was that
> nFileIndexLow/High can change every time file handle is opened, so it's
> not unique. See remarks in following page.
> http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx

Actually, that page only says that file identities may vary over time,
and that it may happen during operations such as defragmentation.
However, I have been in contact with a customer who observed a file
system where the file index actually changed every time a file was
closed and re-opened, given that nobody else kept the file open
inbetween. This was on some kind of network mount, I wasn't told which
kind (and I couldn't reproduce it with samba).

This means that it's actually essential that you don't close the file
between the CreateFile calls (and yes, your patch does this correctly).

----------

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

From report at bugs.python.org  Thu Dec  3 14:56:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Dec 2009 13:56:30 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1259848590.3.0.242235015829.issue6895@psf.upfronthosting.co.za>


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

Assigning to MAL, as this is his code.

----------
assignee: loewis -> lemburg
nosy: +lemburg

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

From report at bugs.python.org  Thu Dec  3 16:00:39 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Dec 2009 15:00:39 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1259852439.4.0.0369581874992.issue5985@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -tjreedy

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

From report at bugs.python.org  Thu Dec  3 16:05:58 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2009 15:05:58 +0000
Subject: [issue2441] Mac build_install.py script fetches unavailable SQLite
	version
In-Reply-To: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za>
Message-ID: <1259852758.37.0.895693738137.issue2441@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: glyph -> ronaldoussoren
nosy: +ronaldoussoren

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

From report at bugs.python.org  Thu Dec  3 16:12:57 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 03 Dec 2009 15:12:57 +0000
Subject: [issue2441] Mac build_install.py script fetches unavailable SQLite
	version
In-Reply-To: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za>
Message-ID: <1259853177.67.0.0664207980614.issue2441@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

This has long been fixed. Even for 2.6maint the SQLite version currently
being fetched is 3.6.11.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Thu Dec  3 16:52:44 2009
From: report at bugs.python.org (djc)
Date: Thu, 03 Dec 2009 15:52:44 +0000
Subject: [issue7427] BadStatusLine is hell to debug
In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
Message-ID: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

For whatever reason, BadStatusLine tracebacks often don't show the line
passed into them. Given the errr, heavy architecture of httplib, this
makes it pretty bad to debug. It's not clear to me why this is:

Traceback (most recent call last):
  File "/home/djc/src/couchdb-python/couchdb/tests/client.py", line 138,
in test_attachment_crud_with_files
    doc = self.db['foo']
  File "/home/djc/src/couchdb-python/couchdb/client.py", line 293, in
__getitem__
    _, _, data = self.resource.get(id)
  File "/home/djc/src/couchdb-python/couchdb/http.py", line 333, in get
    return self._request('GET', path, headers=headers, **params)
  File "/home/djc/src/couchdb-python/couchdb/http.py", line 350, in _request
    credentials=self.credentials)
  File "/home/djc/src/couchdb-python/couchdb/http.py", line 179, in request
    resp = _try_request()
  File "/home/djc/src/couchdb-python/couchdb/http.py", line 167, in
_try_request
    return conn.getresponse()
  File "/usr/lib/python2.6/httplib.py", line 950, in getresponse
  File "/usr/lib/python2.6/httplib.py", line 390, in begin
  File "/usr/lib/python2.6/httplib.py", line 354, in _read_status
BadStatusLine

However, some interactive testing shows that this should work:

djc at enrai couchdb-python $ python
Python 2.6.2 (r262:71600, Oct  5 2009, 12:18:48)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class CrapShoot(Exception):
...     def __init__(self, a):
...             self.args = a,
...
>>> raise CrapShoot('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
__main__.CrapShoot: a
>>> class ParentExc(Exception):
...     pass
...
>>> class CrapShoot(ParentExc):
...     def __init__(self, a):
...             self.args = a,
...
>>> raise CrapShoot('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
__main__.CrapShoot: a
>>>

Definition of BadStatusLine:

class BadStatusLine(HTTPException):
    def __init__(self, line):
        self.args = line,
        self.line = line

class HTTPException(Exception):
    # Subclasses that define an __init__ must call Exception.__init__
    # or define self.args.  Otherwise, str() will fail.
    pass

The note here seems like a cautionary but insufficient tale...

----------
components: Library (Lib)
messages: 95934
nosy: djc
severity: normal
status: open
title: BadStatusLine is hell to debug
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  3 16:59:21 2009
From: report at bugs.python.org (djc)
Date: Thu, 03 Dec 2009 15:59:21 +0000
Subject: [issue7427] BadStatusLine is hell to debug
In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
Message-ID: <1259855961.9.0.844511639461.issue7427@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Also, it might be useful here if it showed repr(line) instead of just
line, but that'd just be icing on the cake.

----------

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

From report at bugs.python.org  Thu Dec  3 17:47:28 2009
From: report at bugs.python.org (Bill Spotz)
Date: Thu, 03 Dec 2009 16:47:28 +0000
Subject: [issue7428] Possible memory issue with optparse
In-Reply-To: <1259858848.42.0.339728371454.issue7428@psf.upfronthosting.co.za>
Message-ID: <1259858848.42.0.339728371454.issue7428@psf.upfronthosting.co.za>


New submission from Bill Spotz <wfspotz at sandia.gov>:

I develop python extension modules for Trilinos, a large scientific 
computing project:

    http://trilinos.sandia.gov

Unit testing my extension modules under Mac OS X, I came across the 
following error messages after upgrading from gcc 4.0 to basically any 
higher version:

  python(65587) malloc: *** error for object 0x1715674: Non-aligned 
pointer being freed

Debugging the problem (which occurs for me in several places in several 
test scripts), the error was always being raised in the built-in C++ 
method

  ostream::operator<<(int)

which indicated to me that the problem was really probably somewhere 
else, and just being triggered in the ostream operator.

Trying to isolate the problem in a smaller script, I was unable to 
reproduce the error until I added

  import optparse

By the same token, I was able to eliminate the problem in my test 
scripts by getting rid of "import optparse".  I have changed these 
scripts now to use getopt, and they are running without error, but I 
thought I would report this strange behavior.

I realize after all of this that the problem might not actually be with 
optparse, but it sure seems like a likely culprit.  I would be happy to 
work with someone to try to reproduce the error, and then hopefully 
such a python expert would be able to find the actual issue.

----------
components: Extension Modules
messages: 95936
nosy: wfspotz
severity: normal
status: open
title: Possible memory issue with optparse
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  3 18:27:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 03 Dec 2009 17:27:11 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1259861231.77.0.428017802889.issue6895@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The reason this call fails is that there's no locale alias defined for
"ml_IN" in the local_alias dictionary.

While the patch is probably a good idea, it also hides the missing mapping.

I think a better approach would be to check the locale name for
standards compliance (ie. xx_YY format) and only then use it as fallback
solution.

I'll update the locale_alias dictionary to the X.org version 2009-12-08
(unless you know an even more recent version). This includes the missing
'ml_IN' mapping (among a few other additions and updates).

----------

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

From report at bugs.python.org  Thu Dec  3 19:24:11 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 18:24:11 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1259864651.54.0.177371780429.issue7381@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15386/issue7381_first.diff

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

From report at bugs.python.org  Thu Dec  3 19:28:06 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 18:28:06 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1259864886.44.0.478995436739.issue7381@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch against the trunk, and against the Py3k branch.

It fixes:
 * docstring and documentation formatting
 * and examples

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15446/issue7381.diff

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

From report at bugs.python.org  Thu Dec  3 19:28:22 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 18:28:22 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1259864902.34.0.0943925247474.issue7381@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15447/issue7381_py3k.diff

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

From report at bugs.python.org  Thu Dec  3 19:30:48 2009
From: report at bugs.python.org (Martin Altmayer)
Date: Thu, 03 Dec 2009 18:30:48 +0000
Subject: [issue7429] PrettyPrinter cannot print dicts with unsortable keys
In-Reply-To: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>
Message-ID: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>


New submission from Martin Altmayer <martin.altmayer at web.de>:

In the following code I use a class for dictionary-keys that has a
__hash__-function but cannot be ordered and try to print that dictionary
with a PrettyPrinter.

import pprint
pp = pprint.PrettyPrinter()

# A class that supports hashing and comparison for equality but cannot
be ordered
class KeyClass:
    def __init__(self,id):
        self.id = id
        
    def __eq__(self,other):
        return self.id == other.id
        
    def __ne__(self,other):
        return self.id != other.id
        
    def __hash__(self):
        return self.id
    

dictionary = dict.fromkeys([KeyClass(i) for i in range(10)])
pp.pprint(dictionary)

The script crashes with the following errors:

Traceback (most recent call last):
  File "/usr/local/lib/python3.1/pprint.py", line 272, in _safe_repr
    items = sorted(items)
TypeError: unorderable types: KeyClass() < KeyClass()

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "bug.py", line 20, in <module>
    pp.pprint(dictionary)
  File "/usr/local/lib/python3.1/pprint.py", line 106, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/usr/local/lib/python3.1/pprint.py", line 129, in _format
    rep = self._repr(object, context, level - 1)
  File "/usr/local/lib/python3.1/pprint.py", line 216, in _repr
    self._depth, level)
  File "/usr/local/lib/python3.1/pprint.py", line 228, in format
    return _safe_repr(object, context, maxlevels, level)
  File "/usr/local/lib/python3.1/pprint.py", line 277, in _safe_repr
    items = sorted(items, key=sortkey)
TypeError: unorderable types: KeyClass() < KeyClass()

----------
components: None
messages: 95939
nosy: maranos
severity: normal
status: open
title: PrettyPrinter cannot print dicts with unsortable keys
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec  3 20:23:05 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 19:23:05 +0000
Subject: [issue1398] Can't pickle partial functions
In-Reply-To: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
Message-ID: <1259868185.49.0.744065840121.issue1398@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

It seems fixed on trunk.
It is fixed on Python 3.1 and 3.2, too.


With Python 2.6 I see the error:
>>> ./python partial_bug.py
TypeError: can't pickle partial objects


Documentation for "trunk" and "py3k" is OK?

----------
nosy: +flox

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

From report at bugs.python.org  Thu Dec  3 20:37:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Dec 2009 19:37:42 +0000
Subject: [issue7428] Possible memory issue with optparse
In-Reply-To: <1259858848.42.0.339728371454.issue7428@psf.upfronthosting.co.za>
Message-ID: <1259869062.05.0.423226294601.issue7428@psf.upfronthosting.co.za>


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

optparse itself is a pure-python library, so it can't possibly cause
memory errors. 

Thanks for the report, but there isn't any realistic chance that we can
do anything with it. So closing it as won't fix.

If you want to debug it further, I would run a debug version of malloc.
Not sure whether OSX comes with one (apart from Python's own memory
debugging), if not, I'd use a memory debugger on a different platform.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Dec  3 20:49:45 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 03 Dec 2009 19:49:45 +0000
Subject: [issue7429] PrettyPrinter cannot print dicts with unsortable keys
In-Reply-To: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>
Message-ID: <1259869785.79.0.851855625121.issue7429@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

I believe this issue was resolved---expect it in a future release.

----------
nosy: +LambertDW

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

From report at bugs.python.org  Thu Dec  3 20:58:46 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 03 Dec 2009 19:58:46 +0000
Subject: [issue7430] "cmp" still sends messages
In-Reply-To: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>
Message-ID: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

'''
    RuntimeError: maximum recursion depth exceeded in cmp

    Python 3.1.1 (r311:74480, Oct  2 2009, 12:29:57) 
    [GCC 4.3.3] on linux2
'''

import itertools,pprint

combos = itertools.combinations

def connect(nodes,a,b):
    nodes[a].append(b)
    nodes[b].append(a)

def insert(nodes,components):
    if components == 0:
        pprint.pprint(nodes)
    for (i,node,) in enumerate(nodes):
        if not node:
            break
    i += 2
    for joints in combos(range(i),2):
        connect(nodes,*joints)
        nest = [node[:]for node in nodes]
        insert(nest,components-1)

def e155(components):
    if components < 1:
        return 0
    network = [[]for i in range((components+1)*2)]
    insert(network,components)
    return network

e155(2)

----------
messages: 95943
nosy: LambertDW
severity: normal
status: open
title: "cmp" still sends messages
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec  3 21:34:59 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 20:34:59 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1259872499.84.0.494840844509.issue4380@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Already fixed on Python trunk (2.7).
Fixed on branches 3.1 and 3.2, too.

----------

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

From report at bugs.python.org  Thu Dec  3 21:41:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Dec 2009 20:41:49 +0000
Subject: [issue7430] "cmp" still sends messages
In-Reply-To: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>
Message-ID: <1259872909.55.0.311416060522.issue7430@psf.upfronthosting.co.za>


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

How about "maximum recursion depth exceeded in comparison" instead?

(It's coming from PyObject_RichCompare in Objects/object.c, by the way.)

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Dec  3 22:03:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Dec 2009 21:03:32 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1259874212.95.0.0342366586489.issue4120@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r76651, r76652, r76653, r76654,
r76655 and r76656.

----------

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

From report at bugs.python.org  Thu Dec  3 22:03:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Dec 2009 21:03:47 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1259874227.17.0.305420093859.issue4120@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Thu Dec  3 22:07:55 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2009 21:07:55 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1259874475.72.0.749574487468.issue6834@psf.upfronthosting.co.za>


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

Another reminder: when implementing, make sure platform.architecture() 
always returns the correct results for bits.  It seems the Apple patches 
in 10.6 don't handle that (it seems to always report 64-bit), probably 
because the code in platform.architecture() doesn't look quite robust 
enough.  (I'll open a bug with Apple.)

----------

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

From report at bugs.python.org  Thu Dec  3 23:12:25 2009
From: report at bugs.python.org (ivank)
Date: Thu, 03 Dec 2009 22:12:25 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

Python 2.7, svn r76655.
I ran the tests with
python2.7 Lib/test/testall.py > test-results.txt

test_linecache
test_checkcache (test.test_linecache.LineCacheTests) ... ERROR
test_clearcache (test.test_linecache.LineCacheTests) ... ok
test_getline (test.test_linecache.LineCacheTests) ... ok

======================================================================
ERROR: test_checkcache (test.test_linecache.LineCacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/Python-latest/lib/python2.7/test/test_linecache.py", line
121, in test_checkcache
    source.close()
UnboundLocalError: local variable 'source' referenced before assignment

----------------------------------------------------------------------
Ran 3 tests in 0.022s

FAILED (errors=1)
test test_linecache failed -- Traceback (most recent call last):
  File "/opt/Python-latest/lib/python2.7/test/test_linecache.py", line
121, in test_checkcache
    source.close()
UnboundLocalError: local variable 'source' referenced before assignment

----------
components: Library (Lib)
messages: 95948
nosy: ivank
severity: normal
status: open
title: UnboundLocalError during test.test_linecache.LineCacheTests
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  3 23:18:05 2009
From: report at bugs.python.org (ivank)
Date: Thu, 03 Dec 2009 22:18:05 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259878685.9.0.0871497158719.issue7431@psf.upfronthosting.co.za>


ivank <ivan at ludios.org> added the comment:

This error is just masking a Permission denied error during
source = open(source_name, 'w')

so I guess it's not very important, just annoying.

----------

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

From report at bugs.python.org  Thu Dec  3 23:30:33 2009
From: report at bugs.python.org (Jared Grubb)
Date: Thu, 03 Dec 2009 22:30:33 +0000
Subject: [issue7432] Py3k doc: "from __future__ import division" not necessary
In-Reply-To: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
Message-ID: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>


New submission from Jared Grubb <python at jaredgrubb.com>:

In the Python 3.1 docs for the 'dis' module, the following appears:
( http://docs.python.org/3.1/library/dis.html )

BINARY_TRUE_DIVIDE()?
    Implements TOS = TOS1 / TOS when from __future__ import division is
in effect.

There is always true in 3k, correct? The "when" clause should be removed.

----------
assignee: georg.brandl
components: Documentation
messages: 95950
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: Py3k doc: "from __future__ import division" not necessary
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec  3 23:32:45 2009
From: report at bugs.python.org (Jared Grubb)
Date: Thu, 03 Dec 2009 22:32:45 +0000
Subject: [issue7432] Py3k doc: "from __future__ import division" not necessary
In-Reply-To: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
Message-ID: <1259879565.15.0.703571146286.issue7432@psf.upfronthosting.co.za>


Jared Grubb <python at jaredgrubb.com> added the comment:

Ditto on a few dozen lines later:

INPLACE_TRUE_DIVIDE()?
    Implements in-place TOS = TOS1 / TOS when from __future__ import
division is in effect.

----------

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

From report at bugs.python.org  Thu Dec  3 23:40:29 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 03 Dec 2009 22:40:29 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

The following code causes a segmentation fault (or glibc error, or other
problems):

>>> x = someobject()
>>> y = memoryview(x)
>>> z = memoryview(y)

The problem is that someobject.bf_releasebuffer will be called two times
with an identical Py_buffer structure. 

This can be seen in memoryobject.c:

static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
    int res = 0;
    /* XXX for whatever reason fixing the flags seems necessary */
    if (self->view.readonly)
        flags &= ~PyBUF_WRITABLE;
    if (self->view.obj != NULL)
        res = PyObject_GetBuffer(self->view.obj, view, flags);
    if (view)
        dup_buffer(view, &self->view);
    return res;
}

At the end of the call, view and self->view contain identical data
because of the call to dup_buffer.

static void
memory_releasebuf(PyMemoryViewObject *self, Py_buffer *view)
{
    PyBuffer_Release(view);
}

But when the outer memoryview is destroyed, memory_releasebuf calls
PyBuffer_Release for the original object once.

And when the inner memoryview is destroyed, PyBuffer_Release is called
by memory_dealloc the second time. Both calls supply an identical
Py_buffer structure.

Now, if the original object's bf_getbuffer and bf_releasebuffer allocate
some memory dynamically, this will likely cause a double-free of memory,
usually leading to a segmentation fault.

There is no feasible way the bf_releasebuffer can keep track of how many
calls to it have been made. So probably the code in memory_getbuf is
wrong -- at least the dup_buffer function looks wrong.

----------
components: Interpreter Core
messages: 95952
nosy: pv
severity: normal
status: open
title: MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec  3 23:40:42 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 03 Dec 2009 22:40:42 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259880042.62.0.148516363935.issue7433@psf.upfronthosting.co.za>


Changes by Pauli Virtanen <pav at iki.fi>:


----------
type:  -> crash

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

From report at bugs.python.org  Thu Dec  3 23:43:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Dec 2009 22:43:06 +0000
Subject: [issue7429] PrettyPrinter cannot print dicts with unsortable keys
In-Reply-To: <1259865048.21.0.71561189105.issue7429@psf.upfronthosting.co.za>
Message-ID: <1259880186.47.0.824607673589.issue7429@psf.upfronthosting.co.za>


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

Confirmed, it is fixed on all maintained branches.  So the fix will be
in 3.1.2, which should be in a month or so.

----------
components: +Library (Lib) -None
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Dec  3 23:51:19 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 03 Dec 2009 22:51:19 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1259880679.25.0.0402059769332.issue7385@psf.upfronthosting.co.za>


Changes by Pauli Virtanen <pav at iki.fi>:


----------
type:  -> crash

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

From report at bugs.python.org  Thu Dec  3 23:54:41 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 22:54:41 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259880881.34.0.0202385242241.issue7431@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Actually it should use the TESTFN filename which is always writable.

Patch attached.

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file15448/issue7431.diff

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

From report at bugs.python.org  Thu Dec  3 23:57:13 2009
From: report at bugs.python.org (flox)
Date: Thu, 03 Dec 2009 22:57:13 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259881033.18.0.325293238967.issue7431@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
versions: +Python 3.2

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

From report at bugs.python.org  Fri Dec  4 01:05:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Dec 2009 00:05:30 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259885130.48.0.883592708992.issue7431@psf.upfronthosting.co.za>


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


----------
assignee:  -> r.david.murray
components: +Tests -Library (Lib)
nosy: +r.david.murray
priority:  -> low
versions: +Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Dec  4 01:25:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Dec 2009 00:25:42 +0000
Subject: [issue7431] UnboundLocalError during
	test.test_linecache.LineCacheTests
In-Reply-To: <1259878345.7.0.0592735556458.issue7431@psf.upfronthosting.co.za>
Message-ID: <1259886342.6.0.116192852823.issue7431@psf.upfronthosting.co.za>


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

Fixed in r76659, r76660, r76661, and r76662.  I also changed the open to
use 'with' so that errors raised by the open will not be masked.

Flox, given how active you are being, you might enjoy joining us in
#python-dev on freenode.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 06:22:04 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 04 Dec 2009 05:22:04 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259904124.88.0.924866320967.issue7406@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here is a way to test for overflow which is correct for any C implementation:

static PyObject *
int_add(PyIntObject *v, PyIntObject *w)
{
	register long a, b;
	CONVERT_TO_LONG(v, a);
	CONVERT_TO_LONG(w, b);
	if (((a>0)&&(b>0)&&((LONG_MAX-a)<b))
		||((a<0)&&(b<0)&&((LONG_MIN-a)>b))) {
		/* would overflow the long type */
	    return PyLong_Type.tp_as_number->nb_add((PyObject *)v, (PyObject *)w);
	}
	
	return PyInt_FromLong(a+b);
}

----------
nosy: +zooko

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

From report at bugs.python.org  Fri Dec  4 06:51:00 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 04 Dec 2009 05:51:00 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259905860.81.0.577729672629.issue7406@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here is a set of macros that I use to test for overflow:

http://allmydata.org/trac/libzutil/browser/libzutil/zutilimp.h

----------

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

From report at bugs.python.org  Fri Dec  4 11:07:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Dec 2009 10:07:46 +0000
Subject: [issue7430] "cmp" still sends messages
In-Reply-To: <1259870325.93.0.208726118911.issue7430@psf.upfronthosting.co.za>
Message-ID: <1259921266.28.0.909494026187.issue7430@psf.upfronthosting.co.za>


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

Fixed in r76663, r76664.  Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Fri Dec  4 11:58:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Dec 2009 10:58:51 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259924331.36.0.881580871602.issue7406@psf.upfronthosting.co.za>


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

Zooko:  Yes; that's the sort of solution that's needed if we're not 
allowed to assume two's complement with the extraordinary value (-
sys.maxint - 1) not a trap representation.  If we are allowed to
assume this, then more efficient solutions are available.

Also, if we're not allowed to assume two's complement + no trap 
representation, then int_and, int_xor, int_or are plain wrong:

For ones' complement or sign-and-magnitude, the result of these
logical operations won't match the result of the corresponding
operations on longs, for negative operands.

For two's complement with (-sys.maxint-1) a trap representation,
int_and and int_xor should be producing a Python long instead
of a Python int in some cases: -sys.maxint ^ 1 should be -sys.maxint - 1, 
which wouldn't be representable as a Python int.

That's why I want to make these extra assumptions beyond what's
guaranteed by the C standards; working around them introduces 
inefficiencies for all implementations, for the benefit
of implementations that (probably) don't even exist.

----------

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

From report at bugs.python.org  Fri Dec  4 12:10:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Dec 2009 11:10:37 +0000
Subject: [issue7048] decimal.py: logb: round the result if it is greater than
	prec
In-Reply-To: <1254577997.92.0.263128195563.issue7048@psf.upfronthosting.co.za>
Message-ID: <1259925037.36.0.0746316293484.issue7048@psf.upfronthosting.co.za>


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

Mike Cowlishaw has confirmed that the tests scbx164, scbx165 (in version 
2.59 of the tests) are implementation-specific, so test_decimal is doing 
the right thing in skipping them.  So I think this issue can be closed.

I don't think it's worth removing the restriction on the 2nd scaleb 
argument:  while I still think it's arbitrary and unnecessary, keeping it 
allows us to say that we're in full compliance with the specification.

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

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

From report at bugs.python.org  Fri Dec  4 14:26:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Dec 2009 13:26:24 +0000
Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1259933184.76.0.74867377981.issue1923@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
nosy: +tarek

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

From report at bugs.python.org  Fri Dec  4 14:29:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Dec 2009 13:29:36 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259933376.33.0.609252546796.issue7433@psf.upfronthosting.co.za>


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

Why do you say that:

> There is no feasible way the bf_releasebuffer can keep track of how many
> calls to it have been made.

Because that's exactly what e.g. bytearray objects do (see the
ob_exports field in Objects/bytearrayobject.c).

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Dec  4 14:31:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Dec 2009 13:31:51 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1259933511.43.0.236191342174.issue7385@psf.upfronthosting.co.za>


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

Nice catch. I wonder whether there's a simple way of cooking up an unit
test for this (short of creating a new extension type).

----------
assignee:  -> pitrou
nosy: +pitrou
priority:  -> high
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Dec  4 14:56:42 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Fri, 04 Dec 2009 13:56:42 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

> Why do you say that:
> 
> > There is no feasible way the bf_releasebuffer can keep track of how 
> > many calls to it have been made.

I was probably thinking about allocating new temporary arrays for
strides etc. on each *_getbuffer -- if that's done, then manually
keeping track of all the allocated memory seems like a waste of effort
(ie. not feasible).

But yes, if memory allocated for entries in Py_buffer is shared between
all exported buffer views, that sounds better -- for some reason I
didn't think about that... So we'll do it like this in Numpy then.

But still, I take it that the way it currently works is not the intended
behavior? The segmentation faults caused by this came as a bit of a
surprise to me, as the assumption about paired *_getbuffer and
*_releasebuffer calls is very natural.

----------

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

From report at bugs.python.org  Fri Dec  4 15:05:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Dec 2009 14:05:04 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259935002.25.0.606018544398.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259935530.3383.13.camel@localhost>


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

> I was probably thinking about allocating new temporary arrays for
> strides etc. on each *_getbuffer -- if that's done, then manually
> keeping track of all the allocated memory seems like a waste of effort
> (ie. not feasible).

Yes, I know it looks very painful to do so. I am not responsible for the
Py_buffer / memorview design, however. Travis Oliphant is, and I hear
he's a member of the Numpy community: you might want to ask him for
advice.

(the general problem is that managing Py_buffers can entail memory
allocations, but Py_buffer is not a PyObject and therefore you can't
take advantage of Python's general object management facilities)

> But still, I take it that the way it currently works is not the intended
> behavior? The segmentation faults caused by this came as a bit of a
> surprise to me, as the assumption about paired *_getbuffer and
> *_releasebuffer calls is very natural.

Well, those calls still /are/ paired, aren't they?
There is one odd thing which you must be careful about, it is that
*_getbuffer can be called with a NULL Py_buffer pointer.

----------

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

From report at bugs.python.org  Fri Dec  4 15:24:51 2009
From: report at bugs.python.org (Pauli Virtanen)
Date: Fri, 04 Dec 2009 14:24:51 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259936691.96.0.0163827438802.issue7433@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

I think this is an implementation issue in MemoryView rather than an
issue with the buffer interface. PEP 3118 states, "This same bufferinfo
structure must be passed to bf_releasebuffer (if available) when the
consumer is done with the memory." -- this is not guaranteed by the
current MemoryView implementation.

The calls are not paired: the *_getbuf calls fill in structures with
data "view1", and "view2". The *_releasebuf calls receive structures
with data "view1", and "view1". The data filled in the second getbuf
call ("view2") is never passed back to *_releasebuf, as it is
overwritten with "view1" data by dup_buffer.

To work around this, *_releasebuf must be written so that it does not
use the "view" pointer passed to it -- the data structure may have been
shallow copied and any memory pointers in it may have already been freed.

I can try to cook up a patch fixing this.

----------

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

From report at bugs.python.org  Fri Dec  4 15:25:43 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 04 Dec 2009 14:25:43 +0000
Subject: [issue7327] format: minimum width: UTF-8 separators and decimal points
In-Reply-To: <1258280971.1.0.983226181609.issue7327@psf.upfronthosting.co.za>
Message-ID: <1259936743.28.0.542130917003.issue7327@psf.upfronthosting.co.za>


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

See the discussion on python-dev, in particular Martin's comment at
http://mail.python.org/pipermail/python-dev/2009-December/094412.html

The solutions to this seem too complex for 2.x. It is not a problem in 3.x.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 15:39:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Dec 2009 14:39:27 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259936691.96.0.0163827438802.issue7433@psf.upfronthosting.co.za>
Message-ID: <1259937595.3383.21.camel@localhost>


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

> To work around this, *_releasebuf must be written so that it does not
> use the "view" pointer passed to it -- the data structure may have been
> shallow copied and any memory pointers in it may have already been freed.
> 
> I can try to cook up a patch fixing this.

If you can do it without breaking the current unit tests
(Lib/test/test_memoryview.py) this would be nice indeed.

----------

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

From report at bugs.python.org  Fri Dec  4 17:32:43 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Fri, 04 Dec 2009 16:32:43 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

It would be nice if pprint could format namedtuples wrapping lines as it
does with tuples.

Looking at the code, this does not look like an easy task.  Completely
rewriting pprint to allow it to be extensible to user-created classes
would be best, but involve a ton of work.  Simple making all named
tuples derive from a named tuple base class (itself derived from tuple)
would be simpler, albeit more of a hack.

----------
components: Library (Lib)
messages: 95968
nosy: afoglia
severity: normal
status: open
title: pprint doesn't know how to print a namedtuple
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec  4 17:37:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 04 Dec 2009 16:37:59 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1259944679.0.0.160954859751.issue7434@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Fri Dec  4 19:34:24 2009
From: report at bugs.python.org (Jake McGuire)
Date: Fri, 04 Dec 2009 18:34:24 +0000
Subject: [issue7427] BadStatusLine is hell to debug
In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
Message-ID: <1259951664.07.0.049172125342.issue7427@psf.upfronthosting.co.za>


Jake McGuire <jake at youtube.com> added the comment:

I think what's happening is that your connection is being closed due to 
inactivity, so the status line that comes back is empty.  Printing 
repr(line) would probably make the emptiness clear, but maybe the httplib 
code should put in a more specific message in this case...

----------
nosy: +jakemcguire

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

From report at bugs.python.org  Fri Dec  4 19:43:55 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 04 Dec 2009 18:43:55 +0000
Subject: [issue7426] StringIO and with statement
In-Reply-To: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
Message-ID: <1259952235.71.0.462900567048.issue7426@psf.upfronthosting.co.za>


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

#1286 looks related

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

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

From report at bugs.python.org  Fri Dec  4 20:45:14 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 04 Dec 2009 19:45:14 +0000
Subject: [issue7426] StringIO and with statement
In-Reply-To: <1259835173.72.0.00703663082921.issue7426@psf.upfronthosting.co.za>
Message-ID: <1259955914.78.0.185755943083.issue7426@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> fileinput, StringIO, and cStringIO do not support the with protocol

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

From report at bugs.python.org  Fri Dec  4 21:55:19 2009
From: report at bugs.python.org (flox)
Date: Fri, 04 Dec 2009 20:55:19 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

In python 3.x there's a single type for integer: int.
The automatic conversion of the test suite has created many tests which
are duplicate of each other.

The attached patch removes duplication of tests, and fix the strings for
these modules:

  Lib/random.py
  Lib/test/mapping_tests.py
  Lib/test/pickletester.py
  Lib/test/string_tests.py
  Lib/test/test_binop.py
  Lib/test/test_builtin.py
  Lib/test/test_datetime.py
  Lib/test/test_decimal.py
  Lib/test/test_descr.py
  Lib/test/test_dict.py
  Lib/test/test_getargs2.py
  Lib/test/test_int.py
  Lib/test/test_long.py
  Lib/test/test_types.py

----------
components: Tests
messages: 95971
nosy: flox
severity: normal
status: open
title: Int/Long: some tests are duplicate and error messages refer to "long"
versions: Python 3.2

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

From report at bugs.python.org  Fri Dec  4 21:56:34 2009
From: report at bugs.python.org (flox)
Date: Fri, 04 Dec 2009 20:56:34 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1259960194.83.0.943843362901.issue7435@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15449/issue7435_py3k.diff

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

From report at bugs.python.org  Fri Dec  4 22:23:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Dec 2009 21:23:01 +0000
Subject: [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

On Python list, someone asked what guarantees that functions have and
will continue to have assignable attributes. I started to say 'the docs'
but failed to find anything specific in 7.6. Function definitions or
LibRef 5.12.3. Functions (all references to 3.1/2a docs).

5.3.1 Attribute references says "The primary must evaluate to an object
of a type that supports attribute references, which most objects do."
That is true for reading/getting but not for writing/setting.

6.2. Assignment statements says "If the target is an attribute
reference: The primary expression in the reference is evaluated. It
should yield an object with assignable attributes;" But which are those?

I propose to add a sentence like "Objects with assignable attributes
include modules, user-defined (Python-coded) functions and classes, and
instances of such classes."

If this leaves anything out, it can be expanded.

I tested and was somewhat surprised to modules based on C code (_socket,
_tkinter) allowed attribute setting. I use 'user'defined' because the
docs do in several places. I added 'Python-coded' because that is the
real relevant characteristic. C-coded user-defined functions in
user-written extension modules do not have settable attributes (I
presume), whereas imported Python-coded functions, in stdlib or 3-rd
party modules do. LibRef 5.12.3 "There are really two flavors of
function objects: built-in functions and user-defined functions." could
leave a reader wondering about imported functions.

A sentence could also be added there "User-defined (Python-coded)
functions have assignable attributes."

----------
assignee: georg.brandl
components: Documentation
messages: 95972
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Define 'object with assignable attributes'

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

From report at bugs.python.org  Fri Dec  4 23:26:57 2009
From: report at bugs.python.org (Tom Switzer)
Date: Fri, 04 Dec 2009 22:26:57 +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: <1259965617.88.0.0338574092292.issue1771@psf.upfronthosting.co.za>


Tom Switzer <thomas.switzer at gmail.com> added the comment:

I am not sure I understand the reasoning behind removing the cmp
parameter (and agree with Lea Wiemann). Trying to wedge a proper
comparison into the key parameter is clumsy and unreadable (as can be
seen in the 2to3 example above). The intrinsic ordering on objects does
not necessarily match up with the way you want to sort them. For
example, a natural intrinsic order on 2 points in 2d is lexicographical,
however you often want to sort by angular order relative to some other
point instead. Clearly this can never be put in __cmp__ or __lt__,
because the sorted order is relative to some other unknown point. Trying
to do this with the key function doesn't make sense; it would not be
clear you are sorting by angular order and you'd have to instantiate a
bunch of wrapper objects just to do basic sorting. Another quick example
would be sorting hyperplanes by intersection on a ray. Sorting points
along a direction given by a vector.

I understand removing redundant features from a language, but I just
can't see how key replaces this functionality in a readable or efficient
way. This highlights an important class of cases (since it was mentioned
that none could be thought of) in which we wish to make comparisons
between values where a comparison (<, > or ==) is more numerically
sound, more efficient, or the only option (perhaps the ordering is
defined explicitly) then computing the exact values (eg. angle). As far
as it seems, the only way to do this with key is by following the
example given and creating a class solely to wrap each object that
overrides __cmp__, which is certainly non-obvious (ie. there is no one,
obvious way to do it).

----------
nosy: +tixxit

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

From report at bugs.python.org  Fri Dec  4 23:32:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Dec 2009 22:32:14 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259965934.46.0.882491497225.issue7406@psf.upfronthosting.co.za>


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

I consider the binary bitwise operations, for negative ints, to be
either undefined or wrongly implemented. Consider the following (3.1)
>>> 3^2
1
>>> -3^2
-1
>>> 3^-2
-3
>>> -3^-2
3
>>> 2^3
1
>>> -2^3
-3

Something change sign just flips the sign of the result, sometimes it
also changes the magnitude. From the viewpoint of arithmetic, and signed
base-two representations, the latter seems senseless.

The doc says only "The ^ operator yields the bitwise XOR (exclusive OR)
of its arguments, which must be integers." But it does not define what
bitwise XOR means for signed ints, as opposed to unsigned bit strings,
possible interpreted as (unsigned) counts, which is the traditional
domain of bit-operation definition. So there is no way to predict the
result for negative ints. Or rather, the sensible prediction does not
match the observed behavior.

My impression is that Python longs are signed magnitudes. If so, the
bitwise ops should arguably be the signed result of the op on the
magnitudes.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri Dec  4 23:49:40 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Dec 2009 22:49:40 +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: <1259966980.63.0.923180045214.issue1771@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Can someone provide a code sample to make this argument more 
understandable for those of us who don't compare points by angular order 
for a living... :-)

I'm not sure what the 2to3 example (I presume you mean msg59937) shows 
except that conversion from a cmp function to a key function may require 
you to actually think...

Also, for all of you asking for cmp back, I hope you realize that 
sorting N values using a custom cmp function makes about N log N calls 
calls to cmp, whereas using a custom key calls the key function only N 
times.  This means that even if your cmp function is faster than the 
best key function you can write, the advantage is lost as N increases 
(which is just where you'd like it to matter most :-).

----------

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

From report at bugs.python.org  Sat Dec  5 00:23:06 2009
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Dec 2009 23:23:06 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1259968986.46.0.829447349056.issue7406@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Terry, the language reference also says:

"""
For the purpose of shift and mask operations, a binary representation is
assumed, and negative numbers are represented in a variant of 2's
complement which gives the illusion of an infinite string of sign bits
extending to the left.
"""

That explains every result you saw:

 3 = ...000011
 2 = ...000010
 1 = ...000001

-3 = ...111101
 2 = ...000010
-1 = ...111111

 3 = ...000011
-2 = ...111110
-3 = ...111101

-3 = ...111101
-2 = ...111110
 3 = ...000011

 2 = ...000010
 3 = ...000011
 1 = ...000001

-2 = ...111110
 3 = ...000011
-3 = ...111101

In every case, the result is simply the xor of the inputs viewed as
infinite bitstrings.  And it works exactly the same way if you use |, &,
<<, >>, or unary ~.

It's true that CPython's longs are /implemented/ via sign-magnitude, but
that should never be visible in the result of any operation.

----------
nosy: +tim_one

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

From report at bugs.python.org  Sat Dec  5 02:00:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Dec 2009 01:00:51 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259974851.69.0.348602425496.issue6594@psf.upfronthosting.co.za>


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

Here is a new patch with an internal memo dict to reuse equal keys, and
some tests.

----------
stage:  -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file15450/json-opts2.patch

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

From report at bugs.python.org  Sat Dec  5 02:03:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Dec 2009 01:03:30 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1259975010.47.0.438394952326.issue6594@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15444/json-opts.patch

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

From report at bugs.python.org  Sat Dec  5 02:17:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Dec 2009 01:17:33 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1259975853.8.0.484192196348.issue7435@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.smith, mark.dickinson

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

From report at bugs.python.org  Sat Dec  5 02:40:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Dec 2009 01:40:22 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted
	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>


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

See the thread starting at http://mail.python.org/pipermail/pythonmac-
sig/2009-December/021907.html for full details.

It appears two vestigial gif files included in the 2.6.4 OS installer 
are being installed under corrupted file names by the OS X Installer.app 
under 10.3 and 10.4.  While the error is silently ignored on 10.4, it 
apparently causes the whole install to fail on 10.3.  The problem does 
not seem to occur when installing on 10.5 or 10.6.  It is also not 
limited to that installer image: I was able to reproduce the problem 
with an installer I built on 10.5.  However, an installer built on 10.4 
from the same source snapshot seems to have the correct file names.

Without knowing exactly why those two file names, and only those two, 
are corrupted, it seems risky to let this seemingly minor problem go 
unresolved.  And it apparently prevents 2.6.4 from being installed on 
10.3, a more serious problem.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 95978
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X 2.6.4 installer fails on 10.3 with two corrupted file names, ignored on 10.4
versions: Python 2.6

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

From report at bugs.python.org  Sat Dec  5 03:22:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 05 Dec 2009 02:22:11 +0000
Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1259979731.89.0.472083002092.issue1923@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Notice that we are also losing something else that can mean a lot
in reST : empty lines. They also need to be escaped.

But we can't do it properly unless we encode empty lines with something
else than a 8 space line because when rfc822.Message reads it, it
removes it.

----------

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

From report at bugs.python.org  Sat Dec  5 05:34:44 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 05 Dec 2009 04:34:44 +0000
Subject: [issue7438] Allow to use a part of subprocess module during building
	Python
In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
Message-ID: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

It is sometimes useful to call subprocess.Popen() in setup.py of
Python. Currently it would fail, because subprocess module tries to
import some modules, which not always are used. I suggest to delay some
imports.

----------
components: Library (Lib)
files: subprocess.py-2.7.patch
keywords: patch
messages: 95980
nosy: Arfrever
severity: normal
status: open
title: Allow to use a part of subprocess module during building Python
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15451/subprocess.py-2.7.patch

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

From report at bugs.python.org  Sat Dec  5 05:35:48 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 05 Dec 2009 04:35:48 +0000
Subject: [issue7438] Allow to use a part of subprocess module during building
	Python
In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
Message-ID: <1259987748.89.0.0455237584785.issue7438@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file15452/subprocess.py-3.2.patch

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

From report at bugs.python.org  Sat Dec  5 07:08:23 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 05 Dec 2009 06:08:23 +0000
Subject: [issue7439] Bug or expected behavior?  I cannot tell.
In-Reply-To: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>
Message-ID: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

Raymond Hettinger posted clever Hamming number generator,
http://code.activestate.com/recipes/576961/
which I tried to modify.  The function gives incorrect output when
called as hamming_numbers(shorthand = True).  It seemed reasonable to
expect the two arrangements of statements controlled by the shorthand
boolean to be functionally equivalent. 
http://docs.python.org/3.1/reference/executionmodel.html is relevant,
and makes me think this is not a bug, but I wish it were.  I'd
appreciate your determination.  Thanks, Dave.



from itertools import tee, chain, islice, groupby
from heapq import merge

def hamming_numbers(shorthand = False):

    def deferred_output():
        for i in output:
            yield i

    result, p2, p3, p5 = tee(deferred_output(), 4)

    if shorthand:                   # Lambert modification
        m = [(a*x for x in p) for (a,p,) in ((2,p2),(3,p3),(5,p5))]
        assert m[0] is not m[2]
        merged = merge(*m)
    else:                           # original
        m2 = (2*x for x in p2)
        m3 = (3*x for x in p3)
        m5 = (5*x for x in p5)
        merged = merge(m2, m3, m5)

    combined = chain([1], merged)
    output = (k for k, v in groupby(combined))

    return result


if __name__ == '__main__':
    print(list(islice(hamming_numbers(), 10)))
    print(list(islice(hamming_numbers(True), 10)))

----------
components: Interpreter Core
messages: 95981
nosy: LambertDW
severity: normal
status: open
title: Bug or expected behavior?  I cannot tell.
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Dec  5 08:04:49 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2009 07:04:49 +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: <1259996689.47.0.040805574901.issue1771@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, we had a long discussion on comp.lang.python and the net result
was that no use cases were found that required a cmp function.  One
complex case (sorting recursive tree structures) at first appeared to
need a cmp-function but was found to be simpler and faster using a
key-function.  The net result of the conversation was the feeling that
people who have grown-up using cmp-functions in either Python, C or some
other language feel like they've lost something but really haven't.  In
contrast, people who use SQL or spreadsheet database tools find that key
functions come naturally since neither supports cmp-functions, instead
preferring the user to specify primary and secondary key functions.   

Also, it was pointed-out the removal of cmp-functions in sorted() and
list.sort() was part of a larger effort to remove all forms of cmp from
the whole language (i.e. the builtin cmp function is gone and so it the
__cmp__ magic method).  Rich comparisons have completely supplanted all
uses of cmp-functions in the language as a whole -- having multiple ways
to do it was confusing.

In converting code from 2-to-3, we have found two sticky cases.

The first occurs when an API had exposed cmp functions to the end-user
(for example, unittest.getTestCaseNames() and unittest.makeSuite() have
an optional sortUsing parameter that allows the user to specify a
cmp-function).  To support that use case (so that end-user API's would
not have to be changed), we added a CmpToKey() tool which automatically
converts cmp-functions to key functions.  This tool is referenced in the
docs and it could be added to the 2-to-3 converter.

The second case occurs when a primary key is sorted ascending and a
secondary key is sorted descending.  The technique for that is to take
advantage of sort stability and do two sorts:

   s.sort(key=secondary, reverse=True)
   s.sort(key=primary)   
   # now sorted by primary ascending, secondary descending

That technique is going to be documented in an update of the sorting
how-to.  It doesn't seem to arise much in practice and the cmp function
equivalent seems to be harder for beginners to write (though at least it
can be done with a single cmp-function and a single sort).

----------

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

From report at bugs.python.org  Sat Dec  5 08:41:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2009 07:41:20 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1259998880.57.0.741341349908.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree with you that pprint needs to be rewritten to make it more
extensible.

I do not see a straight-forward way of handling your feature request.

First, namedtuple() is a factory function and is not itself a class, so
there is no standard way to recognize one.  Essentially, a named tuple
is concept (any class that supported both sequence behavior and
attribute access is a named tuple, for example the time structure is a
named tuple but not created by the collections.namedtuple() factory
function, instead is a C structseq which has substantially similar
characteristics).  This means that pprint has no reliable way to tell if
one of its arguments is a named tuple.

Second, collections.namedtuple() is intentionally designed to let the
user override the default __repr__() method (see an example in the
namedtuple docs).  That means that pprint cannot know in advance how a
named tuple is supposed to display.

At best, I can imagine that pprint() grows the ability to print a
multi-line repr (as specified by the object itself) but indented to a
level controlled by pprint().  The pprint() function would scan the repr
for newlines and replace them with a newline followed by the appropriate
number of spaces.

For example:

>>> class Point(namedtuple('Point', 'x y z')):
...     'Point with a multi-line repr'
...     def __repr__(self):
...         return 'Point(\n      x=%r,\n      y=%r,\n      z=%r\n    
)' % self

>>> Point(3,4,5)
Point(
      x=3,
      y=4,
      z=5
     )

>>> pprint([Point(3,4,5), Point(6,7,8)])
[Point(
       x=3,
       y=4,
       z=5
      ),
 Point(
       x=6,
       y=7,
       z=8
      )
]

Alternatively, the pprint module could introduce a new magic method to
support multi-line reprs when the repr itself it too long fit in a
single line:

class MyList(list):
...     def  __multirepr__(self):
...         'Return a list of strings to pprint'
...         return Multi(head = 'Mylist([',
...                      body = [str(x).upper() for x in self],
...                      tail = '])

>>> pprint(MyList(['now', 'is', 'the', 'time', 'for']), width=15)
MyList(['NOW',
        'IS',
        'THE',
        'TIME',
        'FOR',
])

In summary, there are several ways to approach this problem but they are
centered on building-out pprint(), not on changing collections.namedtuple().

----------
assignee: rhettinger -> 

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

From report at bugs.python.org  Sat Dec  5 08:49:24 2009
From: report at bugs.python.org (Mario Vilas)
Date: Sat, 05 Dec 2009 07:49:24 +0000
Subject: [issue7440] distutils shows incorrect Python version in MSI installers
In-Reply-To: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>
Message-ID: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>


New submission from Mario Vilas <mvilas at gmail.com>:

I just hit this silly bug in distutils, should be quite easy to fix.
When building MSI installers for a target_version other than the current
Python version, the target directory selection dialog shows a wrong message.

For example, here is a screen capture of an installer built using Python
2.6, but setting the target as Python 2.5. The message says:

    "The destination directory should contain a Python 2.6 installation"

when it should be:

    "The destination directory should contain a Python 2.5 installation".

----------
assignee: tarek
components: Distutils
files: msi_installer_wrong_message.png
messages: 95984
nosy: MarioVilas, tarek
severity: normal
status: open
title: distutils shows incorrect Python version in MSI installers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15453/msi_installer_wrong_message.png

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

From report at bugs.python.org  Sat Dec  5 08:51:19 2009
From: report at bugs.python.org (Mario Vilas)
Date: Sat, 05 Dec 2009 07:51:19 +0000
Subject: [issue7440] distutils shows incorrect Python version in MSI installers
In-Reply-To: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>
Message-ID: <1259999479.58.0.291439353492.issue7440@psf.upfronthosting.co.za>


Mario Vilas <mvilas at gmail.com> added the comment:

My proposed patch is to change line 506 of bdist_msi.py from this:

        version = sys.version[:3]+" "

to this:

        version = self.target_version[:3]+" "

which is what I did to work around the problem.

----------

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

From report at bugs.python.org  Sat Dec  5 09:03:37 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Dec 2009 08:03:37 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1260000217.36.0.677726576106.issue7406@psf.upfronthosting.co.za>


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

Thanks Tim. I see that is back in 3.2 rather than in the shift and mask
sections. At least I know what to refer to now.

----------

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

From report at bugs.python.org  Sat Dec  5 11:40:58 2009
From: report at bugs.python.org (Lie Ryan)
Date: Sat, 05 Dec 2009 10:40:58 +0000
Subject: [issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown
	encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

maybe related to #6501

Vista 32-bit SP1, Python 3.1:
"""
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
D:\>chcp 65001
Active code page: 65001

D:\>python -c 'print("")'
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
D:\>python
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""

Expected, either:
1. print nothing (""), or
2. python exception about unknown encoding, or
3. python exception about cannot encode to the encoding

cp65001 is supposed to be an alias for utf-8. Because of the error,
there is AFAICT no way to set the command prompt to accept utf-8 output
even for pipe redirection.

A workaround is to use sys.stdout.buffer.write() to write raw byte
strings, encoding manually. But this takes us back to python 2.

----------
components: IO, Interpreter Core, Unicode, Windows
messages: 95987
nosy: lieryan
severity: normal
status: open
title: Py3.1: Fatal Python Error: Py_Initialize...unknown encoding: chcp 65001.
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Dec  5 11:44:19 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Dec 2009 10:44:19 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi, the following works in 2.7 but not in 3.x:

>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> format(Decimal('1000'), 'n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/decimal.py", line 3632, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.2/decimal.py", line 5628, in
_parse_format_specifier
    _localeconv = _locale.localeconv()
  File "/usr/lib/python3.2/locale.py", line 111, in localeconv
    d = _localeconv()
ValueError: Cannot convert byte to string

----------
messages: 95988
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: format failure with locale specifier
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Dec  5 12:24:48 2009
From: report at bugs.python.org (flox)
Date: Sat, 05 Dec 2009 11:24:48 +0000
Subject: [issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown
	encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1260012288.88.0.621891976807.issue7441@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

there's a patch proposed to add cp65001 alias: issue6058

----------
nosy: +flox

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

From report at bugs.python.org  Sat Dec  5 12:25:45 2009
From: report at bugs.python.org (flox)
Date: Sat, 05 Dec 2009 11:25:45 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1260012345.3.0.532232829163.issue6058@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Dec  5 14:19:12 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 05 Dec 2009 13:19:12 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260019152.96.0.545653706639.issue6472@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

This isn't just a documentation issue. A function named getiterator(),
for which the docs say that it returns an iterator, should return an
iterator, not just an iterable. They have different semantics and can't
be used interchangeably, so the behaviour of getiterator() in
ElementTree is wrong. I was using this in my program:

iterator = element.getiterator()
next(iterator)
subelement = next(iterator)

Which broke when I tried switching to ElementTree from cElementTree,
even though the docs tell me that I'll get an iterator there.

Also, for findall() and friends, is there any reason why we can't stick
to either an iterator or list, and not both? The API will be more clear
if findall() always returned a list, or always an iterator, regardless
of the implementation. It is currently not clear what will happen if I do:

for x in tree.findall(path):
     mutate_tree(tree, x)

----------
components: +Library (Lib)
nosy: +milko.krachounov
type:  -> behavior
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Dec  5 16:20:04 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Dec 2009 15:20:04 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

On Windows there are tiny delay between call to os.unlink and real file 
removing. Periodically it leads to unittest crashes in cases like this:

test.support.unlink(filename)
f = open(filename, 'wb')

Proposed solution: wait in support.unlink for end of deletion asking 
os.stat for removed file (only if os.name == 'nt', of course).

Also test.test_linecache:LineCacheTests.test_checkcache should be fixed 
- this one miss to close last opened file and Windows cannot remove it.

Both patches for trunk and py3k is attached.

----------
components: Tests, Windows
files: python3.patch
keywords: patch
messages: 95991
nosy: asvetlov
severity: normal
status: open
title: test.support.unlink issue on Windows platform
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15454/python3.patch

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

From report at bugs.python.org  Sat Dec  5 16:21:25 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Dec 2009 15:21:25 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260026485.27.0.845481523565.issue7443@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

patch for python 2 is attached

----------
Added file: http://bugs.python.org/file15455/python2.patch

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

From report at bugs.python.org  Sat Dec  5 16:32:46 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Dec 2009 15:32:46 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260027166.87.0.259184403318.issue7443@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Problem can be reproduced with several run of test_bufio in both python 
versions. trunk contains more tests (+1 test case) so it's easer to catch 
'access denied' exception on it.

----------

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

From report at bugs.python.org  Sat Dec  5 17:15:10 2009
From: report at bugs.python.org (Daniel Goldman)
Date: Sat, 05 Dec 2009 16:15:10 +0000
Subject: [issue7444] Allow for a default method in the JSON decoder
In-Reply-To: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
Message-ID: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>


New submission from Daniel Goldman <goldman.inbox at gmail.com>:

I encountered JavaScript-style Date objects in a JSON document that I 
wanted to parse, and these objects were causing the Python JSON decoder 
to raise an error with a message that said "Expecting object," followed 
by the line and column numbers. Here is an example of how such an object 
appeared in the document:

"someDate": new Date(1207568200000),

I went looking in the documentation for a way to plug in a "fall-back" 
method, to be used when the module's standard conversion methods fail, 
but none of the supplied hooks seemed appropriate.

It would be enormously helpful to provide a hook for such a method in 
the JSON decoder in a future release of Python. I believe this would 
parallel the JSON encoder's "default" keyword argument. In this way, 
developers could provide their own method of handling non-standard 
values in JSON documents.

Ultimately, to parse the Date objects, I created a function similar to 
those in the json.decoder module, added the function to the 
json.decoder.ANYTHING list, and assigned a new Scanner object with this 
updated list to json.decoder.JSONScanner.

I couldn't find a similar issue in the issues list, but my apologies if 
this has already been suggested.

----------
components: Library (Lib)
messages: 95994
nosy: dhgoldman
severity: normal
status: open
title: Allow for a default method in the JSON decoder
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Dec  5 17:58:46 2009
From: report at bugs.python.org (Chris Lasher)
Date: Sat, 05 Dec 2009 16:58:46 +0000
Subject: [issue7445] urllib2 (and urllib) should raise error for incomplete
	response
In-Reply-To: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>
Message-ID: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>


New submission from Chris Lasher <chris.lasher at gmail.com>:

This question is motivated by a question on Stack Overflow:
http://stackoverflow.com/questions/1824069/urllib2-not-retrieving-entire-http-response

In the event the user receives an incomplete response when using urllib2
(and urllib), the library should raise an error to indicate the response
is incomplete. This is a matter of checking if the Content-Length
defined in the header matches the size of the retrieved response. While
this can be done by the user, an exception will help alert the more
unwitting, such as myself, by failing early.

----------
components: Library (Lib)
messages: 95995
nosy: gotgenes
severity: normal
status: open
title: urllib2 (and urllib) should raise error for incomplete response
type: behavior

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

From report at bugs.python.org  Sat Dec  5 18:11:01 2009
From: report at bugs.python.org (flox)
Date: Sat, 05 Dec 2009 17:11:01 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260033061.03.0.212870922813.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
nosy: +flox

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

From report at bugs.python.org  Sat Dec  5 18:13:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Dec 2009 17:13:33 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1260033213.15.0.889531552683.issue7435@psf.upfronthosting.co.za>


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

Looks fine to me.  I'd probably keep MyInt rather than MyLong in Lib/test/pickletester.py, and Int 
rather than Long in Lib/test/test_getargs2.py, but that's just a matter of renaming.

I note the major deletions in test_long;  maybe the remaining tests in test_long should be moved 
from there to test_int?

With this patch, all tests pass for me on OS X 10.6.

Eric, this patch affects a bunch of formatting tests, particularly in Lib/test/test_types.py;  I 
don't know whether you're trying to keep trunk and py3k formatting tests synchronized for ease of 
maintenance.  Are you?

----------

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

From report at bugs.python.org  Sat Dec  5 19:26:39 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 05 Dec 2009 18:26:39 +0000
Subject: [issue7445] urllib2 (and urllib) should raise error for incomplete
	response
In-Reply-To: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>
Message-ID: <20091205182621.GA7775@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

urllib and urllib2, by definition, returns a file-like object which
provides a variety of facilities, most common one being a reading the
object to get the content.

What you are asking for is, to read the content, verify if it matches
the Content-Length header, and raise an exception, if the there is a
mis-match. This facility may not be good idea to implement in library,
while it can be (and should be) taken care by the client which is
using the obj.

I am -1 on this request and would like to close this as 'wont-fix'.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sat Dec  5 19:51:51 2009
From: report at bugs.python.org (rb)
Date: Sat, 05 Dec 2009 18:51:51 +0000
Subject: [issue5509] cPickle - module object has no attribute
In-Reply-To: <1237396093.07.0.466180023327.issue5509@psf.upfronthosting.co.za>
Message-ID: <1260039111.48.0.694425541549.issue5509@psf.upfronthosting.co.za>


rb <rb-oss-2 at justgohome.co.uk> added the comment:

I've just been stung by this. I've noticed that this seems to apply to
both cPickle and pickle. Even worse, it causes different behaviour when
a program is run under pdb because __main__ is suddenly pdb rather than
the program itself.

So, in summary, neither pickle nor cPickle can pickle a class if it is
not defined in its own module? Surely this is an obvious deficiency of
pickle and if it is not going to be fixed it should at least be
documented as such?

----------
nosy: +rb

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

From report at bugs.python.org  Sat Dec  5 19:56:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Dec 2009 18:56:33 +0000
Subject: [issue7444] Allow for a default method in the JSON decoder
In-Reply-To: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
Message-ID: <1260039393.26.0.419833654387.issue7444@psf.upfronthosting.co.za>


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


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

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

From report at bugs.python.org  Sat Dec  5 20:09:56 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 05 Dec 2009 19:09:56 +0000
Subject: [issue7439] Bug or expected behavior?  I cannot tell.
In-Reply-To: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>
Message-ID: <1260040196.93.0.547837447545.issue7439@psf.upfronthosting.co.za>


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

The problem with the shorthand form is that the generators use the
values that are bound to 'a' and 'p' when they are iterated, not when
they are created. You can test this by inserting:

    a = "X"

just before the assert: you'll get a TypeError later on.

You need something like this:

        m = []
        for (a,p,) in ((2,p2),(3,p3),(5,p5)):
            def gen(a=a, p=p):
                return (a*x for x in p)
            m.append(gen(a, p))

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Dec  5 20:32:50 2009
From: report at bugs.python.org (flox)
Date: Sat, 05 Dec 2009 19:32:50 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260041570.54.0.302825098267.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

There's many differences between both implementations.
I don't know if we can live with them or not.

~ $ ./python 
Python 3.1.1+ (release31-maint:76650, Dec  3 2009, 17:14:50) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree as ET, cElementTree as cET
>>> from io import StringIO
>>> SAMPLE = '<root/>'
>>> IO_SAMPLE = StringIO(SAMPLE)


With ElementTree

>>> elt = ET.XML(SAMPLE)
>>> elt.getiterator()
[<Element root at 15cb920>]
>>> elt.findall('')  # or '.'
[<Element root at 15cb920>]
>>> elt.findall('./')
[<Element root at 15cb920>]
>>> elt.items()
dict_items([])
>>> elt.keys()
dict_keys([])
>>> elt[:]
[]
>>> IO_SAMPLE.seek(0)
>>> next(ET.iterparse(IO_SAMPLE))
('end', <Element root at 15d60d0>)
>>> IO_SAMPLE.seek(0)
>>> list(ET.iterparse(IO_SAMPLE))
[('end', <Element root at 15583e0>)]


With cElementTree

>>> elt_c = cET.XML(SAMPLE)
>>> elt_c.getiterator()
<generator object getiterator at 0x15baae0>
>>> elt_c.findall('')
[]
>>> elt_c.findall('./')
[<Element 'root' at 0x15cf3a0>]
>>> elt_c.items()
[]
>>> elt_c.keys()
[]
>>> elt_c[:]
Traceback (most recent call last):
TypeError: sequence index must be integer, not 'slice'
>>> IO_SAMPLE.seek(0)
>>> next(cET.iterparse(IO_SAMPLE))
Traceback (most recent call last):
TypeError: iterparse object is not an iterator
>>> IO_SAMPLE.seek(0)
>>> list(cET.iterparse(IO_SAMPLE))
[(b'end', <Element 'root' at 0x15cf940>)]

----------

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

From report at bugs.python.org  Sat Dec  5 20:37:58 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Dec 2009 19:37:58 +0000
Subject: [issue7406] int arithmetic relies on C signed overflow behaviour
In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za>
Message-ID: <1260041878.92.0.564408659741.issue7406@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/issue7406>
_______________________________________

From report at bugs.python.org  Sat Dec  5 20:37:59 2009
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 05 Dec 2009 19:37:59 +0000
Subject: [issue7439] Bug or expected behavior?  I cannot tell.
In-Reply-To: <1260040196.93.0.547837447545.issue7439@psf.upfronthosting.co.za>
Message-ID: <1260041875.4897.11.camel@lambertdw>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

Thank you!

A prime sieve variant is a better way to generate the generalized
Hamming numbers I'm after, at least if the maximum is known ahead of
time.

Dave Lambert

----------

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

From report at bugs.python.org  Sat Dec  5 20:43:09 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 05 Dec 2009 19:43:09 +0000
Subject: [issue7444] Allow for a default method in the JSON decoder
In-Reply-To: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
Message-ID: <1260042189.57.0.962573962037.issue7444@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

If it had JavaScript style Date objects in it, it wasn't a JSON document.

While it may be easy enough to do this in the version that happens to be 
included with Python, the optimizations in later versions of simplejson 
make this no longer possible. You'd have to change a bunch of C and Python 
code to parse that. There are fewer function calls and regular expressions 
for efficiency reasons. It's not simplejson's goal to be able to parse 
non-JSON documents.

----------
resolution:  -> wont fix

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

From report at bugs.python.org  Sat Dec  5 20:43:15 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 05 Dec 2009 19:43:15 +0000
Subject: [issue7444] Allow for a default method in the JSON decoder
In-Reply-To: <1260029710.19.0.37768452228.issue7444@psf.upfronthosting.co.za>
Message-ID: <1260042195.67.0.0812213974459.issue7444@psf.upfronthosting.co.za>


Changes by Bob Ippolito <bob at redivi.com>:


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

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

From report at bugs.python.org  Sat Dec  5 20:51:11 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 05 Dec 2009 19:51:11 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1260042671.86.0.777970733717.issue7435@psf.upfronthosting.co.za>


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

> Eric, this patch affects a bunch of formatting tests, particularly
> in Lib/test/test_types.py;  I don't know whether you're trying to
> keep trunk and py3k formatting tests synchronized for ease of
> maintenance.  Are you?

No, I've basically given up on keeping the tests in sync. The
implementations are the same but not the tests.

----------

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

From report at bugs.python.org  Sat Dec  5 20:52:25 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Dec 2009 19:52:25 +0000
Subject: [issue7438] Allow to use a part of subprocess module during building
	Python
In-Reply-To: <1259987684.71.0.162752431193.issue7438@psf.upfronthosting.co.za>
Message-ID: <1260042745.16.0.261364851143.issue7438@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review
priority:  -> low
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sat Dec  5 20:55:56 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Dec 2009 19:55:56 +0000
Subject: [issue7439] Bug or expected behavior?  I cannot tell.
In-Reply-To: <1259993303.11.0.648697393695.issue7439@psf.upfronthosting.co.za>
Message-ID: <1260042956.84.0.0759819305691.issue7439@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Dec  5 20:56:57 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Dec 2009 19:56:57 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260043017.94.0.92739677442.issue7443@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review
priority:  -> low
stage:  -> patch review

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

From report at bugs.python.org  Sat Dec  5 21:13:00 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Dec 2009 20:13:00 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260043980.4.0.236642425858.issue7443@psf.upfronthosting.co.za>


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

I'm fairly skeptical that your analysis is right. Can you prove that a
file still exists after unlink returns?

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

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

From report at bugs.python.org  Sat Dec  5 21:14:14 2009
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sat, 05 Dec 2009 20:14:14 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260044054.57.0.0290102263011.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

I wrote a wrapper around the PostgreSQL implementation of setproctitle 
(probably the most portable around). I've only tested it on Linux: 
probably will require tweaking constants to compile on other platforms 
(something postgres does at configure time) but the core functionality 
is surely well tested.

I've put the module on http://code.google.com/p/py-setproctitle/ : 
testing (yes, there is an unit test) and tweaking setup on other 
platforms is welcome.

----------
nosy: +piro

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

From report at bugs.python.org  Sat Dec  5 21:30:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Dec 2009 20:30:15 +0000
Subject: [issue7435] Int/Long: some tests are duplicate and error messages
	refer to "long"
In-Reply-To: <1259960117.54.0.630253268501.issue7435@psf.upfronthosting.co.za>
Message-ID: <1260045015.97.0.19159340734.issue7435@psf.upfronthosting.co.za>


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

Patch applied in r76681 (I took the liberty of doing the MyLong -> MyInt 
and Long -> Int renames).  Many thanks, flox!

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  5 21:36:54 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sat, 05 Dec 2009 20:36:54 +0000
Subject: [issue7446] http.cookies.BaseCookie (and SimpleCookie) can't be load
	from dict
In-Reply-To: <1260045414.09.0.536880658138.issue7446@psf.upfronthosting.co.za>
Message-ID: <1260045414.09.0.536880658138.issue7446@psf.upfronthosting.co.za>


New submission from Thomas Courbon <harthie at yahoo.fr>:

Hi there !

According the documentation [1], the following code should work :
>>> from http.cookies import SimpleCookie
>>> c = SimpleCookie({'field1': 'value1', 'field2': 'value2'})
>>> print(c)
'Set-Cookie: field1=value1\r\nSet-Cookie: field2=value2'

But an exception is raised : 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python31\lib\http\cookies.py", line 507, in output
    result.append( V.output(attrs, header) )
AttributeError: 'str' object has no attribute 'output'

in BaseCookie.load(...) the call to BaseCookie.update(rawdata) seem to
use dict.__setitem__ instead of BaseCookie.__setitem__.

Despite it's weird (I believe that the __setitem__ of the child class
should be used) I don't know why.

I don't have a solution to this underlying issue so I propose to define
an update method for BaseCookie:
def update(self, other=None, **kwargs):
    if other is None:
        other = kwargs
    elif not hasattr(other, 'items'):
        other = dict(other)
    for k, v in other.items():
        self[k] = v

This method behave like the dict one.

Hope it help and it's not a duplicate.

Regards,
Thomas


[1] :
http://docs.python.org/3.1/library/http.cookies.html#http.cookies.BaseCookie.load

----------
components: Library (Lib)
messages: 96007
nosy: tcourbon
severity: normal
status: open
title: http.cookies.BaseCookie (and SimpleCookie) can't be load from dict
versions: Python 3.1

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

From report at bugs.python.org  Sat Dec  5 22:03:38 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Dec 2009 21:03:38 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1260047018.79.0.239850875457.issue7442@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This fails in _localemodule.c: str2uni(). mbstowcs(NULL, s, 0) is
LC_CTYPE sensitive, but LC_CTYPE is UTF-8 in my terminal.

If I set LC_CTYPE and LC_NUMERIC together, things work.

This raises the question: If LC_CTYPE and LC_NUMERIC differ (and
since they are separate entities I assume they may differ), what
is the correct way to convert the separator and the decimal point?


a) call setlocale(LC_CTYPE, setlocale(LC_NUMERIC, NULL)) before
   mbstowcs. This is not really an option.


b) use some kind of _mbstowcs_l
(http://msdn.microsoft.com/en-us/library/k1f9b8cy(VS.80).aspx), which
takes a locale parameter. But I don't
find such a thing on Linux.

----------

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

From report at bugs.python.org  Sat Dec  5 22:12:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Dec 2009 21:12:53 +0000
Subject: [issue7446] http.cookies.BaseCookie (and SimpleCookie) can't be load
	from dict
In-Reply-To: <1260045414.09.0.536880658138.issue7446@psf.upfronthosting.co.za>
Message-ID: <1260047573.2.0.422353936718.issue7446@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was already corrected with issue5275. Thanks however for the report.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> BaseCookie.load doesn't create Morsel objects for mappings

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

From report at bugs.python.org  Sat Dec  5 23:01:32 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Dec 2009 22:01:32 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260050492.28.0.109261227931.issue5949@psf.upfronthosting.co.za>


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

.endswith() is a good alternative to [-2:] ==

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sat Dec  5 23:12:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Dec 2009 22:12:00 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1260051120.39.0.38491237215.issue7434@psf.upfronthosting.co.za>


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

You could make all namedtuples inherit from a common base class, e.g.
`BaseNamedTuple`.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Dec  6 00:09:05 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Dec 2009 23:09:05 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1260054545.67.0.113514795538.issue7443@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

You right, problem is not in os.unlink (Windows call DeleteFile) itself.

I have TortoiseSVN (very popular Explorer extension to work with 
Subversion) installed. 
This tool run TSVNCache.exe process to update own data in background.
TSVNCache.exe receive NotifyChangeDirectory events for svn checkout 
folders. 
support.TESTFN is tempfile name in current working directory. If I try 
to run unittests from some folder from python checkout TSVNCache.exe get 
change notify and analyze it.

So, sometimes I can see race condition:
- python: os.unlink(file)
- TSVNCache.exe: get change event
- TSVNCache.exe: query changes
- python: open(file) - oops, TSVNCache.exe still processing notification 
and lock deleted file by holding opened handles to it.
According to MSDN for DeleteFile function:
The DeleteFile function marks a file for deletion on close. Therefore, 
the file deletion does not occur until the last handle to the file is 
closed. Subsequent calls to CreateFile to open the file fail with 
ERROR_ACCESS_DENIED.
We get exactly same.
- TSVNCache.exe finish of change update and release handle. File is 
actually deleted.

I see this situation in sysinternals Process Monitor tool.
Probability of race condition is tiny but non-zero. Intensive 
create/drop/create again sequences can catch this one.

----------

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

From report at bugs.python.org  Sun Dec  6 01:50:42 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Dec 2009 00:50:42 +0000
Subject: [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"sum(iterable[, start]) 
Sums start and the items of an iterable from left to right and returns
the total. start defaults to 0. The iterable?s items are normally
numbers, and are not allowed to be strings."

The last sentence is not currently true (3.1, assume also others).
It is the start value that cannot be a string.

>>> sum([1,2],'')
TypeError: sum() can't sum strings [use ''.join(seq) instead]

>>>sum(['xyz', 'pdq'], Zero()) # R Hettinger's universal zero class
'xyzpdq'
works because start is not a string

>>> sum(['a','b'])
TypeError: unsupported operand type(s) for +: 'int' and 'str'
passes type(start) != str and only fails because + fails.

I am filing this as a doc issue as the easiest fix for the discrepancy
between doc and behavior. But the fix could be a behavior change, though
certain to be controversial. Given that, my  suggested revision is:
"The iterable?s items are normally numbers. The start value is not
allowed to be a string."

I think this fits the followup sentence: "The fast, correct way to
concatenate a sequence of strings..."

----------
assignee: georg.brandl
components: Documentation
messages: 96013
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Sum() doc and behavior mismatch
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Dec  6 02:15:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Dec 2009 01:15:45 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1260062145.24.0.341181789585.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We need a more generic solution that allows multi-line reprs for a
variety of types.  Here is an example that doesn't involve named tuples:

>>> pprint(s, width=15)
[OrderedDict([('x', 30000000000), ('y', 4000000000), ('z', 5000000000)]),
 OrderedDict([('x', 6000000000), ('y', 70000000), ('z', 8000000000)])]

What we want is to have it print like regular dictionaries do:

>>> pprint([dict(p) for p in s], width=15)
[{'x': 30000000000,
  'y': 4000000000,
  'z': 5000000000},
 {'x': 6000000000,
  'y': 70000000,
  'z': 8000000000}]

It would also be nice if pprint could accept arguments telling it how to
format various types:

>>> pprint(s, width=15, format={int: '15,'})
[{'x': ' 30,000,000,000',
  'y': '  4,000,000,000',
  'z': '  5,000,000,000'},
 {'x': '  6,000,000,000',
  'y': '     70,000,000',
  'z': '  8,000,000,000'}]

----------

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

From report at bugs.python.org  Sun Dec  6 02:34:47 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 06 Dec 2009 01:34:47 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1260063287.1.0.681291338858.issue1578269@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Jason, as I see you implemented os.samefile (actually ntpath.samefile) 
but  os.sameopenfile is still not implemented.

Looks like it's easy to do: while GetFinalPathNameByHandle already 
accept file handle you can use CRT function _get_osfhandle(fd) to 
convert file descriptors (arguments for sameopenfile) to file handles 
and pass it to GetFinalPathNameByHandle.

For me samefile and sameopenfile has very close semantic and I like to 
see both if it's possible.

Thanks.

----------
nosy: +asvetlov

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

From report at bugs.python.org  Sun Dec  6 02:38:57 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 06 Dec 2009 01:38:57 +0000
Subject: [issue5985] Implement os.path.samefile and os.path.sameopenfile on
	Windows
In-Reply-To: <1241949768.79.0.988490949056.issue5985@psf.upfronthosting.co.za>
Message-ID: <1260063537.01.0.943182162269.issue5985@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Please note: patch for http://bugs.python.org/issue1578269 is already has 
implementation for samefile. It's easer to add sameopenfile is same way 
than maintain two different approaches.

Unfortunately solution will work only starting from Windows Vista and 
Windows Server 2008.

----------
nosy: +asvetlov

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

From report at bugs.python.org  Sun Dec  6 02:42:30 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 06 Dec 2009 01:42:30 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1260063750.34.0.56303917977.issue6727@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/issue6727>
_______________________________________

From report at bugs.python.org  Sun Dec  6 03:59:23 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 02:59:23 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260068363.82.0.821964743001.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Alright, I am attaching a new patch to correct the brain-fart
inefficiency of slicing versus endswith().

I don't understand why this is so difficult to review. I don't think
Janssen is the right person to have been assigned to this. While it is
related to SSL, I don't think the IMAP module is even on his radar.
Whereas, I use this module everyday, every 10 minutes every day to fetch
my email (via getmail), and can assure you that the 110 character change
is correct.

----------
Added file: http://bugs.python.org/file15456/imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 03:59:31 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 02:59:31 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260068371.59.0.631132365487.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15013/imaplib-r75166.patch

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

From report at bugs.python.org  Sun Dec  6 04:26:57 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Dec 2009 03:26:57 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260070017.33.0.186027829971.issue5949@psf.upfronthosting.co.za>


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

Rest assured it has little to do with the difficultly of reviewing it.
Rather we are all volunteers. Do you think a test would be easy to write
for this?

----------
assignee: janssen -> 

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

From report at bugs.python.org  Sun Dec  6 05:19:46 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 04:19:46 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260073186.89.0.499130820491.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Ben, I understand that we are all volunteers here. My frustration in the
lack of a de facto owner of the imaplib module and not with you
personally or any other committer for that matter.

As it is, there is no unittests for the imaplib module, and I am not in
a position to provide a complete implementation of an IMAP server.
However, I have attached a simple script demonstrating the issue. An
unpatched trunk will infinite loop, consuming memory, and a patched
version will throw a Traceback immediately.

----------
Added file: http://bugs.python.org/file15457/imaplib-eof-test.py

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

From report at bugs.python.org  Sun Dec  6 05:25:43 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 06 Dec 2009 04:25:43 +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: <1260073543.38.0.484339330655.issue7316@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/issue7316>
_______________________________________

From report at bugs.python.org  Sun Dec  6 05:29:02 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Dec 2009 04:29:02 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1260073186.89.0.499130820491.issue5949@psf.upfronthosting.co.za>
Message-ID: <1afaf6160912052028s637c82e1j7eda52cf085a8c96@mail.gmail.com>


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

2009/12/5 Scott Dial <report at bugs.python.org>:
>
> Scott Dial <scott at scottdial.com> added the comment:
>
> Ben, I understand that we are all volunteers here. My frustration in the
> lack of a de facto owner of the imaplib module and not with you
> personally or any other committer for that matter.\

Unfortunately imaplib predates the focus for stability in Python.

>
> As it is, there is no unittests for the imaplib module, and I am not in
> a position to provide a complete implementation of an IMAP server.

There is a stub in test_imaplib.py. I wouldn't expect a complete test
suite, but merely a test exposing the bug you are fixing. Every step
counts.

> However, I have attached a simple script demonstrating the issue. An
> unpatched trunk will infinite loop, consuming memory, and a patched
> version will throw a Traceback immediately.

----------

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

From report at bugs.python.org  Sun Dec  6 05:42:51 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 06 Dec 2009 04:42:51 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260074571.74.0.612533074704.issue5596@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/issue5596>
_______________________________________

From report at bugs.python.org  Sun Dec  6 08:22:07 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 07:22:07 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260084127.92.0.368838102982.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I found myself in the mood to code, so in the spirit of "every step
counts", I have attached a patch that updates test_imaplib accordingly.
The construction of the test framework is based loosely on test_ssl and
test_socketserver. If someone felt so moved to add more test cases, then
one would could simply extend SimpleIMAPHandler to handle more IMAP
commands.

FYI, as previously noted, on an unpatch trunk test_issue5949() is an
infinite loop.

----------
Added file: http://bugs.python.org/file15458/test_imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 08:23:53 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 07:23:53 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260084233.95.0.695804857807.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15459/test_imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 08:23:59 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 07:23:59 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260084239.39.0.389976823841.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15458/test_imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 08:25:34 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 07:25:34 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260084334.46.0.596883068886.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15460/test_imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 08:25:39 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 07:25:39 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260084339.48.0.622379477887.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15459/test_imaplib-r76683.patch

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

From report at bugs.python.org  Sun Dec  6 09:47:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Dec 2009 08:47:37 +0000
Subject: [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1260089257.19.0.02810372046.issue7447@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Sun Dec  6 10:31:43 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Dec 2009 09:31:43 +0000
Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1260091903.24.0.819401060255.issue1923@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I will treat the empty line problem in another issue because I won't
apply it in 2.6/3.1.

This one is fixed in r76684, r76685, r76686, r76687.

Thanks !

----------
status: open -> closed
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/issue1923>
_______________________________________

From report at bugs.python.org  Sun Dec  6 12:51:23 2009
From: report at bugs.python.org (flox)
Date: Sun, 06 Dec 2009 11:51:23 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260100283.23.0.901369545368.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Proposed patch fixes most of the discrepancies between both implementations.

It restores some features that were lost with Python 3:
 * cElement slicing and extended slicing
 * iterparse, cET.getiterator and cET.findall return an iterator
   (as documented)

Some tests were added to check these issues.

----------
keywords: +patch
Added file: http://bugs.python.org/file15461/issue6472.diff

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

From report at bugs.python.org  Sun Dec  6 12:51:56 2009
From: report at bugs.python.org (flox)
Date: Sun, 06 Dec 2009 11:51:56 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260100316.96.0.550618473756.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15462/issue6472_py3k.diff

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

From report at bugs.python.org  Sun Dec  6 12:57:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Dec 2009 11:57:31 +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: <1260100651.05.0.868730760351.issue1771@psf.upfronthosting.co.za>


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

Tom, I think I'm missing your point:  all three of the examples you give 
seem like perfect candidates for a key-based sort rather than a 
comparison-based one.  For the first example, couldn't you do something 
like:

def direction(pt1, pt2):
    """angle of line segment from point 1 to point 2"""
    return atan2(pt2.y - pt1.y, pt2.x - pt1.x)

my_points.sort(key=lambda pt: direction(reference_pt, pt))

? How would having a cmp keyword argument make this any easier or 
simpler?


Here's the best example I can think of for which key-based sorting is 
problematic:  imagine that the Decimal type doesn't exist, and that you 
have triples (sign, coefficient_string, exponent) representing 
arbitrary-precision base 10 floating-point numbers.  It's fairly tricky 
to come up with a key function that maps these triples to some existing 
ordered type, so that they can be sorted in natural numerical order.  
The problem lies in the way that the sort order for the coefficient 
string and exponent depends on the value of the sign (one way for 
positive numbers, reversed for negative numbers). But it's not a big 
deal to define a wrapper for cases like this.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun Dec  6 17:23:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 16:23:14 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260116594.7.0.912886376916.issue5949@psf.upfronthosting.co.za>


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

With just the test patch applied, test_imaplib passes for me on trunk
r76687.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Dec  6 17:24:43 2009
From: report at bugs.python.org (Tom Switzer)
Date: Sun, 06 Dec 2009 16:24:43 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1260100651.05.0.868730760351.issue1771@psf.upfronthosting.co.za>
Message-ID: <853aa53f0912060824j12451935ob500deffe5824bc1@mail.gmail.com>


Tom Switzer <thomas.switzer at gmail.com> added the comment:

Mark: I think your example actually helps illustrate my point. My point was
that computing the angle directly is less efficient or not as nice
numerically. For instance, if you are sorting points by angle relative to an
extreme point you could do something like this (a first step in the Graham
Scan) - be prepared for non-Python 3.0 code ;)

from functools import partial
from random import random

def turn(p, q, r):
    """Return -1, 0, or 1 if p,q,r forms a right, straight, or left turn
respectively."""
    return cmp((q[0] - p[0])*(r[1] - p[1]) - (r[0] - p[0])*(q[1] - p[1]), 0)

pts = [(random(), random()) for i in xrange(10)]
i = min(xrange(len(pts)), key=lambda i: pts[i])
p = pts.pop(i)
pts.sort(cmp=partial(turn, p))

Here our comparison function requires only 2 multiplications and 5
additions/subtractions. This function is nice especially if you are using
arbitrary precision or rational numbers as it is exact.

On Sun, Dec 6, 2009 at 6:57 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Tom, I think I'm missing your point:  all three of the examples you give
> seem like perfect candidates for a key-based sort rather than a
> comparison-based one.  For the first example, couldn't you do something
> like:
>
> def direction(pt1, pt2):
>    """angle of line segment from point 1 to point 2"""
>    return atan2(pt2.y - pt1.y, pt2.x - pt1.x)
>
> my_points.sort(key=lambda pt: direction(reference_pt, pt))
>
> ? How would having a cmp keyword argument make this any easier or
> simpler?
>
>
> Here's the best example I can think of for which key-based sorting is
> problematic:  imagine that the Decimal type doesn't exist, and that you
> have triples (sign, coefficient_string, exponent) representing
> arbitrary-precision base 10 floating-point numbers.  It's fairly tricky
> to come up with a key function that maps these triples to some existing
> ordered type, so that they can be sorted in natural numerical order.
> The problem lies in the way that the sort order for the coefficient
> string and exponent depends on the value of the sign (one way for
> positive numbers, reversed for negative numbers). But it's not a big
> deal to define a wrapper for cases like this.
>
> ----------
> nosy: +mark.dickinson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1771>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15463/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________
-------------- next part --------------
Mark: I think your example actually helps illustrate my point. My point was that computing the angle directly is less efficient or not as nice numerically. For instance, if you are sorting points by angle relative to an extreme point you could do something like this (a first step in the Graham Scan) - be prepared for non-Python 3.0 code ;)<br>
<br>from functools import partial<br>from random import random<br><br>def turn(p, q, r):<br>?????? &quot;&quot;&quot;Return -1, 0, or 1 if p,q,r forms a right, straight, or left turn respectively.&quot;&quot;&quot;<br>?????? return cmp((q[0] - p[0])*(r[1] - p[1]) - (r[0] - p[0])*(q[1] - p[1]), 0)<br>
<br>pts = [(random(), random()) for i in xrange(10)]<br>i = min(xrange(len(pts)), key=lambda i: pts[i])<br>p = pts.pop(i)<br>pts.sort(cmp=partial(turn, p))<br><br>Here our comparison function requires only 2 multiplications and 5 additions/subtractions. This function is nice especially if you are using arbitrary precision or rational numbers as it is exact.<br>
<br><br><div class="gmail_quote">On Sun, Dec 6, 2009 at 6:57 AM, Mark Dickinson <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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
Tom, I think I&#39;m missing your point: ??all three of the examples you give<br>
seem like perfect candidates for a key-based sort rather than a<br>
comparison-based one. ??For the first example, couldn&#39;t you do something<br>
like:<br>
<br>
def direction(pt1, pt2):<br>
 ?? ??&quot;&quot;&quot;angle of line segment from point 1 to point 2&quot;&quot;&quot;<br>
 ?? ??return atan2(pt2.y - pt1.y, pt2.x - pt1.x)<br>
<br>
my_points.sort(key=lambda pt: direction(reference_pt, pt))<br>
<br>
? How would having a cmp keyword argument make this any easier or<br>
simpler?<br>
<br>
<br>
Here&#39;s the best example I can think of for which key-based sorting is<br>
problematic: ??imagine that the Decimal type doesn&#39;t exist, and that you<br>
have triples (sign, coefficient_string, exponent) representing<br>
arbitrary-precision base 10 floating-point numbers. ??It&#39;s fairly tricky<br>
to come up with a key function that maps these triples to some existing<br>
ordered type, so that they can be sorted in natural numerical order.<br>
The problem lies in the way that the sort order for the coefficient<br>
string and exponent depends on the value of the sign (one way for<br>
positive numbers, reversed for negative numbers). But it&#39;s not a big<br>
deal to define a wrapper for cases like this.<br>
<br>
----------<br>
nosy: +mark.dickinson<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/issue1771" target="_blank">http://bugs.python.org/issue1771</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sun Dec  6 17:25:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 16:25:21 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260116721.68.0.339321062838.issue5949@psf.upfronthosting.co.za>


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

Ah, your new test isn't being run, that's why test_impalib passes.  Let
me figure out why your test isn't run.

----------

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

From report at bugs.python.org  Sun Dec  6 17:31:19 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 16:31:19 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260117079.74.0.359694884736.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

The test requires regrtest.py be run with network support and the python
instance be built with threads.

$ ./python Lib/test/regrtest.py -u network test_imaplib

Without network support, it just skips those test (which is the same way
test_ssl). That seemed a bit fishy to me, but I was just emulating what
I saw.

----------

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

From report at bugs.python.org  Sun Dec  6 17:32:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 16:32:10 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260117130.58.0.143695009863.issue5949@psf.upfronthosting.co.za>


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

OK, after adding ThreadedNetworkedTests to the 'tests' list in
test_main, the new tests ran and did hang.  After applying the imaplib
patch, the new tests completed.  However, afterward I got the following
traceback:

Exception in thread Thread-6 (most likely raised during interpreter
shutdown):
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 526, in
__bootstrap_inner
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 479, in run
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 583, in
process_request_thread
  File "/home/rdmurray/python/trunk/Lib/test/test_imaplib.py", line 82,
in handle_error
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 434, in
server_close
  File "/home/rdmurray/python/trunk/Lib/socket.py", line 192, in close
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

----------

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

From report at bugs.python.org  Sun Dec  6 17:33:43 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 16:33:43 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260117223.08.0.792814247618.issue5949@psf.upfronthosting.co.za>


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

Ah, my mistake, I misread the code, sorry.

Yes, if I supply -uall to regrtest the tests run correctly.

----------

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

From report at bugs.python.org  Sun Dec  6 17:37:44 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 06 Dec 2009 16:37:44 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1260117464.23.0.880223052288.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15464/python-trunk-20091206-CROSS.patch

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

From report at bugs.python.org  Sun Dec  6 17:38:41 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 06 Dec 2009 16:38:41 +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: <1260117521.87.0.142054883717.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15465/python-trunk-20091206-MINGW.patch

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

From report at bugs.python.org  Sun Dec  6 18:05:11 2009
From: report at bugs.python.org (Scott Dial)
Date: Sun, 06 Dec 2009 17:05:11 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260119111.62.0.866774365544.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Thanks for giving it a try. I believe the issue is that I am raising an
exception in the middle of run_server, which was not a pattern tested in
the other modules I looked at. Thus, the threads for those do not get
reaped correctly.

I have rewrote the test to ensure all of the spawned threads and servers
are shutdown correctly.

----------
Added file: http://bugs.python.org/file15466/test_imaplib-r76683-2.patch

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

From report at bugs.python.org  Sun Dec  6 18:07:47 2009
From: report at bugs.python.org (Clovis Fabricio)
Date: Sun, 06 Dec 2009 17:07:47 +0000
Subject: [issue7448] when piping output between subprocesses some fd is left
	open blocking forever
In-Reply-To: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>
Message-ID: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>


New submission from Clovis Fabricio <nosklo+python at gmail.com>:

Suppose I want to simulate the following shell pipe using the subprocess
module:

`grep -v not | cut -c 1-10`

The documentation example here
http://docs.python.org/library/subprocess.html#replacing-shell-pipeline
Implies that I want to run this:

grep_process = Popen(["grep", "-v", "not"], stdin=PIPE, stdout=PIPE)
cut_process = Popen(["cut", "-c", "1-10"], stdin=p1.stdout, stdout=PIPE)
grep_process.stdin.write('Hello World\n')
grep_process.stdin.close()
result = cut_process.stdout.read() # blocks forever here
assert result == "Hello Worl\n"

When grep_prcoess starts, two file descriptors are created, one 
for each end of the pipe. Lets call those `grep-stdin-w` and
`grep-stdout-r`.
When I run cut_process, `grep-stdout-r` gets passed as cut_process sdtin. 
Since `close_fds=False` by default, The effect of that is that
cut_process also 
inherits `grep-stdin-w`. So `grep` can't die even if I explicty run
`grep_process.stdin.close()`
because `grep-stdin-w` stdin is still inside cut_process (`cut` ignores
the extra open fd).

Passing `close_fds=True` to the second Popen call makes the code work
perfectly.
`close_fds=True` should be the default on unix systems, because it
closes files descriptors that have nothing to do with the process, leaving
stdin, stdout and stderr working, which is the intended behaviour of
most code.

----------
components: Library (Lib)
messages: 96032
nosy: nosklo
severity: normal
status: open
title: when piping output between subprocesses some fd is left open blocking forever
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Dec  6 18:26:33 2009
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Sun, 06 Dec 2009 17:26:33 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260120393.85.0.372535414759.issue5672@psf.upfronthosting.co.za>


Marcelo Fern?ndez <marcelo.fidel.fernandez at gmail.com> added the comment:

Great, piro!

I'm taking a look at it, and it seems to use setproctitle() in BSD, and 
writes over the argv array "in most Sys-V like systems"; this includes 
Linux?

My question is because I think there's a better and supported method for 
Linux, that is, using prctl [1]. I read somewhere that changing argv 
causes some inconsistencies between programs who read /sys files, /proc 
files... or I don't remember what, but it is, in fact, not the 
*recommended* way. Prctl is. :-)

PR_SET_NAME and PR_GET_NAME parameters in prctl.h:
[1] http://www.kernel.org/doc/man-pages/online/pages/man2/prctl.2.html

Could this module be altered to use a prctl call in Linux (>2.6.9)?

Thanks a lot.

----------

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

From report at bugs.python.org  Sun Dec  6 18:27:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Dec 2009 17:27:32 +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: <1260120452.15.0.355798430029.issue1771@psf.upfronthosting.co.za>


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

Ah.  Thanks for the explanation;  I see your point.  I guess you do just 
have to use a CmpToKey-type wrapper for this sort of comparison.

Though for this *particular* example, it seems to me that you could still use a key function

lambda q: (q[0] - p[0])/(q[1]-p[1]),

which would be even more efficient.  This is assuming that your extreme 
point p has minimal second coordinate amongst points being sorted, which 
as I understand it is how the Graham Scan typically starts.  There's the 
minor difficulty of dealing with points with the *same* second coordinate 
as p, where I guess the key value should be some form of +Infinity.  I can 
also see that this might be problematic if you're working with a type 
that's exact for addition and multiplication but not for division (e.g., 
Decimal with unbounded precision).

It would be interesting to see some relative timings for the sort stage of 
the Graham scan (on a million random points, say): key function versus cmp 
function.

----------

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

From report at bugs.python.org  Sun Dec  6 18:35:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 17:35: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: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In the past (<= 2.6) regrtest skipped a test if any import failure
happened, which masked various real test failures.  This was fixed, and
tests that should be skipped if certain modules are not available were
changed to use (test_)support.import_module, which causes a skip if that
particular module cannot be imported.

If python is compiled --without-threads, then the following tests
currently 'crash' because they cannot import thread and/or threading:

    test_hashlib test_asyncore test_wait3 test_threading test_socket
    test_wait4 test_capi test_xmlrpc test_ctypes
    test_zipimport_support test_threading_local test_multiprocessing
    test_file2k test_smtplib test_threadedtempfile test_threadsignals
    test_thread test_queue test_asynchat test_contextlib
    test_bz2 test_ftplib test_cmd test_pdb test_io test_doctest
    test_sqlite test_logging test_telnetlib test_threaded_import
    test_httpservers test_fork1 test_docxmlrpc test_urllib2_localnet
    test_poplib test_socketserver

All of these tests should either be changed to use import_module when
importing thread/threading, or changed so that the tests requiring
thread support are skipped if thread support is not available.

Note that test_bsddb3 also fails, but it is not an import error crash.

----------
components: Tests
keywords: easy
messages: 96035
nosy: r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: A number tests "crash" if python is compiled --without-threads
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Dec  6 20:11:13 2009
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sun, 06 Dec 2009 19:11:13 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260126673.27.0.867693282427.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

> I'm taking a look at it, and it seems to use setproctitle() in BSD, 
and 
> writes over the argv array "in most Sys-V like systems"; this 
includes 
> Linux?

Yes: Linux uses what in the source is referred as the 
PS_USE_CLOBBER_ARGV strategy: it writes over the area pointed by argv 
and by environ (after checked they are contiguous and moved away). 
Sounds scary, but I've tested that environ keeps working fine (the 
environ can be modified and forked processes receive the correct 
environment).

> My question is because I think there's a better and supported method 
for 
> Linux, that is, using prctl [1]. I read somewhere that changing argv 
> causes some inconsistencies between programs who read /sys files, 
/proc 
> files... or I don't remember what, but it is, in fact, not the 
> *recommended* way. Prctl is. :-)

This is interesting: do you have any reference?

I've tested with the difference between clobbering argv and call 
prctl: two demo programs are in the tools directory of the module 
project [2].

For what I observed, clobbering argv changes what shown in 
``/proc/PID/cmdline``, whereas prctl changes what can be read in 
``/proc/PID/status`` (and ``stat`` too). ``ps`` uses the former, but 
switches to the latter when calling ``ps a`` and ``ps f``. ``top`` 
toggles between the two pressing ``c``.

I don't know which method is better (well, I happen to prefer the 
extended visualization provided by the cmdline, which natively shows 
more detail than just the process name shown in ``status`` but this is 
probably subjective).

> Could this module be altered to use a prctl call in Linux (>2.6.9)?

I think is probably better to have both strings updated: I'd prefer 
this behavior instead of the title being set in different places on 
different Linux versions.

[2] http://code.google.com/p/py-setproctitle/source/browse/tools/

----------

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

From report at bugs.python.org  Sun Dec  6 21:10:34 2009
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Sun, 06 Dec 2009 20:10:34 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1260126673.27.0.867693282427.issue5672@psf.upfronthosting.co.za>
Message-ID: <d2c8b70d0912061210t6786e8d9l8b7d45eee4a0c69e@mail.gmail.com>


Marcelo Fern?ndez <marcelo.fidel.fernandez at gmail.com> added the comment:

2009/12/6 Daniele Varrazzo <report at bugs.python.org>:
>> My question is because I think there's a better and supported method
> for
>> Linux, that is, using prctl [1]. I read somewhere that changing argv
>> causes some inconsistencies between programs who read /sys files,
> /proc
>> files... or I don't remember what, but it is, in fact, not the
>> *recommended* way. Prctl is. :-)
>
> This is interesting: do you have any reference?

For example, take a look at the comments here:
http://abock.org/2006/02/09/changing-process-name-in-mono

It seems that some utilities and programs (killall,
gnome-system-monitor, and so on) looks for the process name in
/proc/PID/status, not in /proc/PID/cmdline, so it should be better (in
Linux), to modify both, /proc/PID/cmdline (changing argv) *and*
/proc/PID/status (calling prctl()).

I installed py-setproctitle, and can't kill it with killall once I set
the name to "hello", for example. :-(

[1]+  Detenido                python
marcelo at marcelo-laptop:~/src/py-setproctitle$ ps a
  PID TTY      STAT   TIME COMMAND
 1030 tty4     Ss+    0:00 /sbin/getty -8 38400 tty4
 1033 tty5     Ss+    0:00 /sbin/getty -8 38400 tty5
 1049 tty2     Ss+    0:00 /sbin/getty -8 38400 tty2
 1050 tty3     Ss+    0:00 /sbin/getty -8 38400 tty3
 1052 tty6     Ss+    0:00 /sbin/getty -8 38400 tty6
 1349 tty7     Ss+   17:14 /usr/bin/X :0 -br -verbose -auth
/var/run/gdm/auth-for-gdm-XhETSO/database -nolisten tcp vt7
 2225 tty1     Ss+    0:00 /sbin/getty -8 38400 tty1
10344 pts/0    Ss+    0:00 /bin/bash -l
11923 pts/1    Ss     0:00 bash
12068 pts/2    Ss+    0:00 bash
12485 pts/1    T      0:00 hello
12496 pts/1    R+     0:00 ps a
marcelo at marcelo-laptop:~/src/py-setproctitle$ killall hello
hello: proceso no encontrado

Another example: The gnome-system-monitor still lists the 'hello'
process (PID 12485) like 'python'. So we should try

> I've tested with the difference between clobbering argv and call
> prctl: two demo programs are in the tools directory of the module
> project [2].
>
> For what I observed, clobbering argv changes what shown in
> ``/proc/PID/cmdline``, whereas prctl changes what can be read in
> ``/proc/PID/status`` (and ``stat`` too). ``ps`` uses the former, but
> switches to the latter when calling ``ps a`` and ``ps f``. ``top``
> toggles between the two pressing ``c``.

Sorry, but here (Ubuntu 9.10) it works the other way around: "ps"
lists the /proc/PID/status -> name field and "ps a" lists the
/proc/PID/cmdline. But I got the explanation. :-)

> I think is probably better to have both strings updated: I'd prefer
> this behavior instead of the title being set in different places on
> different Linux versions.

IMHO, I'd prefer both things: to change the argv array *and* calling
prctl() if possible (Linux >2.6.9). If Linux is lower than 2.6.9,
fallback to change argv only.

Regards
-- 
Marcelo F. Fern?ndez
Buenos Aires, Argentina
Licenciado en Sistemas - CCNA

E-Mail: marcelo.fidel.fernandez at gmail.com
Blog: http://blog.marcelofernandez.info
Twitter: http://twitter.com/fidelfernandez

----------

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

From report at bugs.python.org  Sun Dec  6 21:41:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 20:41:47 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260132107.26.0.582474564237.issue5949@psf.upfronthosting.co.za>


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

The traceback I posted was a spurious result of my misunderstanding your
test code.  With -uall it worked fine.  Sorry that I didn't make that clear.

Thanks for doing the work of putting the extended test framework
together.  Without that, this would probably have remained stuck.

I don't think the test_socketserver code is a particularly good example
of unittest code, though, so I refactored what you did into something I
like better.  I may be wrong, so feedback welcome.

Alternative test_imaplib patch attached.

Note that in looking at this I discovered that the test suite as a whole
does not currently handle --without-threads cleanly.  I've opened issue
7449 for this.  Since test_imaplib currently only has one
non-thread-dependent test, I've written my version of the patch so that
the whole test is skipped if threading is not available (this skip will
come with an appropriate message in the test output).

Note also that my code generates a traceback analogous to the one I
posted but only when run under -R.  I'll have to look in to that.

----------
assignee:  -> r.david.murray

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

From report at bugs.python.org  Sun Dec  6 21:42:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2009 20:42:41 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260132161.77.0.417514813091.issue5949@psf.upfronthosting.co.za>


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

Patch actually attached this time.

----------
Added file: http://bugs.python.org/file15467/test_imaplib_issue5949.patch

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

From report at bugs.python.org  Sun Dec  6 22:16:34 2009
From: report at bugs.python.org (flox)
Date: Sun, 06 Dec 2009 21:16:34 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260134194.45.0.944857218464.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I fixed it differently, using the upstream modules (Thank you Fredrik).
 * ElementTree 1.3a3-20070912
 * cElementTree 1.0.6-20090110

It works.
And it closes issue1143, too.

----------
Added file: http://bugs.python.org/file15468/issue6472_upstream.diff

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

From report at bugs.python.org  Mon Dec  7 02:14:01 2009
From: report at bugs.python.org (Daniele Varrazzo)
Date: Mon, 07 Dec 2009 01:14:01 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260148441.67.0.467818026235.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

> It seems that some utilities and programs (killall,
> gnome-system-monitor, and so on) looks for the process name in
> /proc/PID/status, not in /proc/PID/cmdline, so it should be better
> (in Linux), to modify both, /proc/PID/cmdline (changing argv) *and*
> /proc/PID/status (calling prctl()).

> I installed py-setproctitle, and can't kill it with killall once I 
> set the name to "hello", for example. :-(

Just released setproctitle 0.2 where I also call prctl() if available. 
It is actually the string used by killall.

>> For what I observed, clobbering argv changes what shown in
>> ``/proc/PID/cmdline``, whereas prctl changes what can be read in
>> ``/proc/PID/status`` (and ``stat`` too). ``ps`` uses the former, 
but
>> switches to the latter when calling ``ps a`` and ``ps f``. ``top``
>> toggles between the two pressing ``c``.

> Sorry, but here (Ubuntu 9.10) it works the other way around: "ps"
> lists the /proc/PID/status -> name field and "ps a" lists the
> /proc/PID/cmdline. But I got the explanation. :-)

Yup, sorry: it was the other way round :P

----------

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

From report at bugs.python.org  Mon Dec  7 02:33:50 2009
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Mon, 07 Dec 2009 01:33:50 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1260148441.67.0.467818026235.issue5672@psf.upfronthosting.co.za>
Message-ID: <d2c8b70d0912061733q12f32ab7gcbdfa250a758610b@mail.gmail.com>


Marcelo Fern?ndez <marcelo.fidel.fernandez at gmail.com> added the comment:

2009/12/6 Daniele Varrazzo <report at bugs.python.org>:
>
> Just released setproctitle 0.2 where I also call prctl() if available.
> It is actually the string used by killall.

Great!

I've just tested it and it works fine here... Any possibility this
module can be included in the regular python standard library, in the
future?

Thanks!

----------

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

From report at bugs.python.org  Mon Dec  7 02:41:03 2009
From: report at bugs.python.org (Jerry Seutter)
Date: Mon, 07 Dec 2009 01:41:03 +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: <1260150063.87.0.43718610336.issue7449@psf.upfronthosting.co.za>


Changes by Jerry Seutter <jseutter at gmail.com>:


----------
assignee:  -> jseutter
nosy: +jseutter

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

From report at bugs.python.org  Mon Dec  7 06:35:12 2009
From: report at bugs.python.org (Mark Wielaard)
Date: Mon, 07 Dec 2009 05:35:12 +0000
Subject: [issue4111] Add DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1260164112.6.0.754786570825.issue4111@psf.upfronthosting.co.za>


Changes by Mark Wielaard <mjw at redhat.com>:


----------
nosy: +mjw

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

From report at bugs.python.org  Mon Dec  7 08:17:57 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Dec 2009 07:17:57 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <d2c8b70d0912061733q12f32ab7gcbdfa250a758610b@mail.gmail.com>
Message-ID: <4B1CAC20.901@v.loewis.de>


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

> I've just tested it and it works fine here... Any possibility this
> module can be included in the regular python standard library, in the
> future?

Only in the far future. I don't think the Python standard library should
include a module whose version number is 0.2.

I propose to close this issue as "won't fix", with reference to the
external setproctitle module.

----------

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

From report at bugs.python.org  Mon Dec  7 09:21:36 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 08:21:36 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260174096.55.0.111951215474.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
versions:  -Python 3.0
Added file: http://bugs.python.org/file15469/issue6472_upstream_py3k.diff

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

From report at bugs.python.org  Mon Dec  7 09:22:14 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 08:22:14 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260174134.39.0.356767779053.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15462/issue6472_py3k.diff

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

From report at bugs.python.org  Mon Dec  7 09:22:19 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 08:22:19 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260174139.56.0.987405428034.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15461/issue6472.diff

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

From report at bugs.python.org  Mon Dec  7 09:27:57 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 08:27:57 +0000
Subject: [issue1143] Update to latest ElementTree in Python 2.7
In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
Message-ID: <1260174477.17.0.244791960233.issue1143@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch proposed with latest versions:
 * ElementTree 1.3a3-20070912
 * cElementTree 1.0.6-20090110

Attached to issue6472.

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file15470/issue1143_ET13_cET106.diff

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

From report at bugs.python.org  Mon Dec  7 09:28:13 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 08:28:13 +0000
Subject: [issue1143] Update to latest ElementTree in Python 2.7
In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
Message-ID: <1260174493.84.0.892132521967.issue1143@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15470/issue1143_ET13_cET106.diff

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

From report at bugs.python.org  Mon Dec  7 11:09:38 2009
From: report at bugs.python.org (Daniele Varrazzo)
Date: Mon, 07 Dec 2009 10:09:38 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260180578.68.0.557847373885.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

>> I've just tested it and it works fine here... Any possibility this
>> module can be included in the regular python standard library, in the
>> future?

>Only in the far future. I don't think the Python standard library 
> should include a module whose version number is 0.2.

I agree: I started the project 4-5 days ago and, albeit very limited in
its scope, for portability reasons is way more complex than a simple
syscall and needs to be tested on many other platforms.

----------

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

From report at bugs.python.org  Mon Dec  7 12:01:11 2009
From: report at bugs.python.org (Domen)
Date: Mon, 07 Dec 2009 11:01:11 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1260183671.8.0.954290311952.issue2054@psf.upfronthosting.co.za>


Domen <ielectric at gmail.com> added the comment:

Nice! Any chance of merging with 2.7? Python3.2 is waaay too far in
future for such useful change to be actually useful.

----------

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

From report at bugs.python.org  Mon Dec  7 12:06:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 11:06:48 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1260184008.03.0.319582786174.issue2054@psf.upfronthosting.co.za>


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

It's already in 2.7.

----------

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

From report at bugs.python.org  Mon Dec  7 12:10:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 11:10:43 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260184243.32.0.598531198057.issue6472@psf.upfronthosting.co.za>


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

The patch should have doc updates for new functionality, if any.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Mon Dec  7 12:11:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 11:11:13 +0000
Subject: [issue1143] Update to latest ElementTree in Python 2.7
In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
Message-ID: <1260184273.59.0.592234346201.issue1143@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

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

From report at bugs.python.org  Mon Dec  7 13:39:01 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 12:39:01 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260189541.32.0.450266626765.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I see some new features in the changelog.
I will try to update the documentation during the week.

(patch "py3k" fixed: support assignment of arbitrary sequences)

----------
Added file: http://bugs.python.org/file15471/issue6472_upstream_py3k.diff

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

From report at bugs.python.org  Mon Dec  7 13:39:11 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 12:39:11 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260189551.47.0.412836079376.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15469/issue6472_upstream_py3k.diff

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

From report at bugs.python.org  Mon Dec  7 15:22:20 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 14:22:20 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260195740.82.0.597638359456.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

The design of your patch makes a lot of sense. I found that your patch
uncovered a problem with using the ThreadingMixin (which is ultimately
not necessary as long as the whole SocketServer is in its own thread). I
rewrote the SimpleIMAPHandler to timeout in a timely manner and for the
reap_server() to actually ensure that all threads have been shutdown.

I ended up rewriting my patch in steps towards yours before I uncovered
why I was getting threads alive at shutdown. In that vein, the patch I
am attaching uses the "with reaped_server(hdlr) as server:" technique,
but it could be converted to use an attribute instead. I find using
"with" easier to read and less error prone (failing shutdown the server
and thread because human error or an uncaught exception).

----------
Added file: http://bugs.python.org/file15472/test_imaplib_issue5949-2.patch

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

From report at bugs.python.org  Mon Dec  7 15:31:30 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 14:31:30 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260196290.41.0.243186574849.issue5596@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

test_textwrap seems OK with r76697

I still have leaks on test_pipes and test_urllib:

~ $ ./python Lib/test/regrtest.py -R : test_textwrap \
             test_pipes test_urllib
test_pipes leaked [0, -26, 0, 26] references, sum=0
test_pipes leaked [0, -26, 26, -26] references, sum=-26
test_pipes leaked [-26, 26, 0, 0] references, sum=0
test_pipes leaked [26, -26, 26, 0] references, sum=26
test_urllib leaked [0, 2, 0, 0] references, sum=2
test_urllib leaked [4, 6, 0, 2] references, sum=12
test_urllib leaked [2, 4, 2, 0] references, sum=8
test_urllib leaked [6, 6, 2, 0] references, sum=14

----------
nosy: +flox

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

From report at bugs.python.org  Mon Dec  7 15:48:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Dec 2009 14:48:12 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260197292.71.0.316804870227.issue5949@psf.upfronthosting.co.za>


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

IMO the context manager approach is much better than what I had.  I'm
still not used to using those :)

One request: I imported test_support as support because that's what it
is named in py3k, and doing it that way will make porting the patch to
py3k simpler.  It would also be nice to pep8ify the spacing by putting
two blank lines between classes (yeah, I know, a lot of the test source
is not PEP 8 compliant...but we try to keep any new code compliant, and
fix old code as we touch it).

Oh, and the reason I moved SocketServer below the import_module for
threading is that SocketServer will die on import if threading is not
available, so it seemed better to me to make the explicit check for
threading first.  Probably instead that import_module should be moved to
the top of the import list, since if it fails the module is skipped.

----------

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

From report at bugs.python.org  Mon Dec  7 16:02:52 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Mon, 07 Dec 2009 15:02:52 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260198172.94.0.822664076929.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

Antoine,
indeed, both patches improved time and memory foot print. The latest 
patch shows only 1.1GB RAM usage and is very fast. What's worry me 
though, that memory is not released back to the system. Is this is the 
case? I just added time.sleep after json.load and saw that once decoding 
is done, the resident size still remain the same.

----------

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

From report at bugs.python.org  Mon Dec  7 16:05:16 2009
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Mon, 07 Dec 2009 15:05:16 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1260180578.68.0.557847373885.issue5672@psf.upfronthosting.co.za>
Message-ID: <d2c8b70d0912070704n67c2eb67ya610bb6d2b471ff9@mail.gmail.com>


Marcelo Fern?ndez <marcelo.fidel.fernandez at gmail.com> added the comment:

2009/12/7 Daniele Varrazzo <report at bugs.python.org>:
>
> Daniele Varrazzo <piro at develer.com> added the comment:
>
>>> I've just tested it and it works fine here... Any possibility this
>>> module can be included in the regular python standard library, in the
>>> future?
>
>>Only in the far future. I don't think the Python standard library
>> should include a module whose version number is 0.2.
>
> I agree: I started the project 4-5 days ago and, albeit very limited in
> its scope, for portability reasons is way more complex than a simple
> syscall and needs to be tested on many other platforms.
>

Of course, when I said "future" I meant "when this project is stable
and tested enough"... :-)

Thanks

----------

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

From report at bugs.python.org  Mon Dec  7 16:25:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 15:25:42 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1260198172.94.0.822664076929.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260199573.3381.0.camel@localhost>


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

> Antoine,
> indeed, both patches improved time and memory foot print. The latest 
> patch shows only 1.1GB RAM usage and is very fast. What's worry me 
> though, that memory is not released back to the system. Is this is the 
> case? I just added time.sleep after json.load and saw that once decoding 
> is done, the resident size still remain the same.

Interesting. Does it release memory without the patch?

----------

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

From report at bugs.python.org  Mon Dec  7 16:38:34 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Mon, 07 Dec 2009 15:38:34 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260200314.75.0.0345659493402.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

Nope, all three json's implementation do not release the memory. I used 
your patched one, the one shipped with 2.6 and cjson. The one which comes 
with 2.6, reach 2GB, then release 200MB and stays with 1.8GB during 
sleep. The cjson reaches 1.5GB mark and stays there. But all three 
release another 100-200MB just before the exit (one top cycle before 
process disappear). I used sleep of 20 seconds, so I'm pretty sure memory 
was not released during that time, since I watched the process with idle 
CPU.

----------

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

From report at bugs.python.org  Mon Dec  7 16:43:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 15:43:12 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1260200314.75.0.0345659493402.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260200622.3381.2.camel@localhost>


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

> Nope, all three json's implementation do not release the memory. I used 
> your patched one, the one shipped with 2.6 and cjson. The one which comes 
> with 2.6, reach 2GB, then release 200MB and stays with 1.8GB during 
> sleep. The cjson reaches 1.5GB mark and stays there. But all three 
> release another 100-200MB just before the exit (one top cycle before 
> process disappear). I used sleep of 20 seconds, so I'm pretty sure memory 
> was not released during that time, since I watched the process with idle 
> CPU.

Do you destroy the decoded data, though? If you keep it in memory
there's no chance that a lot of memory will be released.

----------

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

From report at bugs.python.org  Mon Dec  7 16:46:21 2009
From: report at bugs.python.org (Tom Switzer)
Date: Mon, 07 Dec 2009 15:46:21 +0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1260120452.15.0.355798430029.issue1771@psf.upfronthosting.co.za>
Message-ID: <853aa53f0912070746q705d00d3o2743d47f1d0ff93e@mail.gmail.com>


Tom Switzer <thomas.switzer at gmail.com> added the comment:

If the equal min y-coords are handled, I think it'd be quicker too. As Guido
noted, O(n) function calls is better then O(n log n) =] Though the general
case is still unhandled. And, though it doesn't help my case, the Graham
Scan can also be performed on points sorted lexicographically too, by
constructing the upper & lower hull separately, hehe.

Now, I understand cmp on the whole was removed from the language. Using
__lt__, __eq__, etc. really is more natural. However, having an explicit cmp
function for sorting makes sense to me. At the very least, it is more
obvious and natural for some problems - though I respect that using a key
func. is often faster. In some rare (though "rare" is very subjective) cases
it is required; packing a cmp function into __cmp__ in a wrapper object is
really just a hard-to-read cmp function and highlights the need for cmp. I
would actually love to see it added for min/max too actually, since I find I
often use a simple reduce function in place of a min(lst, cmp=...).
Enforcing proper comparisons (<, >, ==, etc) makes sense, but would having
the cmp function live, so to speak, in sorting really be that bad? Just
inform the user in the docs that key is preferred and often faster.

----------
Added file: http://bugs.python.org/file15473/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
_______________________________________
-------------- next part --------------
If the equal min y-coords are handled, I think it&#39;d be quicker too. As Guido noted, O(n) function calls is better then O(n log n) =] Though the general case is still unhandled. And, though it doesn&#39;t help my case, the Graham Scan can also be performed on points sorted lexicographically too, by constructing the upper &amp; lower hull separately, hehe.<br>
<br>Now, I understand cmp on the whole was removed from the language. Using __lt__, __eq__, etc. really is more natural. However, having an explicit cmp function for sorting makes sense to me. At the very least, it is more obvious and natural for some problems - though I respect that using a key func. is often faster. In some rare (though &quot;rare&quot; is very subjective) cases it is required; packing a cmp function into __cmp__ in a wrapper object is really just a hard-to-read cmp function and highlights the need for cmp. I would actually love to see it added for min/max too actually, since I find I often use a simple reduce function in place of a min(lst, cmp=...). Enforcing proper comparisons (&lt;, &gt;, ==, etc) makes sense, but would having the cmp function live, so to speak, in sorting really be that bad? Just inform the user in the docs that key is preferred and often faster.<br>


From report at bugs.python.org  Mon Dec  7 16:51:04 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Mon, 07 Dec 2009 15:51:04 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260201064.32.0.636708275197.issue6594@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

I made data local, but adding del shows the same behavior.
This is the test

def test():
    source = open('mangled.json', 'r')
    data = json.load(source)
    source.close()
    del data
test()
time.sleep(20)

----------

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

From report at bugs.python.org  Mon Dec  7 16:54:20 2009
From: report at bugs.python.org (clutchski)
Date: Mon, 07 Dec 2009 15:54:20 +0000
Subject: [issue7450] document that os.chmod accepts an octal digit mode
In-Reply-To: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
Message-ID: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>


New submission from clutchski <clutchski at gmail.com>:

It would be helpful to explicitly document that os.chmod accepts octal
digit modes e.g. os.chmod(path, 0755). This is much more user friendly
than saying you must OR bit constants kept in a completely different module.

It could be argued that this change would be make the abstraction leaky,
since the values of the stat.S_I* constants could change, but in
practice, this seems unlikely.

----------
assignee: georg.brandl
components: Documentation
messages: 96060
nosy: clutchski, georg.brandl
severity: normal
status: open
title: document that os.chmod accepts an octal digit mode

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

From report at bugs.python.org  Mon Dec  7 17:30:22 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 16:30:22 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260203422.25.0.0270044781768.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I actually thought I was complying with PEP8.. yikes. I guess my
personal rules are slightly different. I think the latest attached patch
is PEP8 compliant now. And, I moved the import_module() to the top as
you suggested.

----------
Added file: http://bugs.python.org/file15474/test_imaplib_issue5949-3.patch

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

From report at bugs.python.org  Mon Dec  7 18:13:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Dec 2009 17:13:06 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260205986.82.0.447218244379.issue5949@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15467/test_imaplib_issue5949.patch

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

From report at bugs.python.org  Mon Dec  7 18:14:44 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 17:14:44 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260206084.58.0.392392838573.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15460/test_imaplib-r76683.patch

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

From report at bugs.python.org  Mon Dec  7 18:14:52 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 17:14:52 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260206092.35.0.753542430217.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15466/test_imaplib-r76683-2.patch

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

From report at bugs.python.org  Mon Dec  7 18:14:56 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 17:14:56 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260206096.71.0.229230278666.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15472/test_imaplib_issue5949-2.patch

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

From report at bugs.python.org  Mon Dec  7 18:15:04 2009
From: report at bugs.python.org (Scott Dial)
Date: Mon, 07 Dec 2009 17:15:04 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260206104.95.0.195608797057.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15457/imaplib-eof-test.py

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

From report at bugs.python.org  Mon Dec  7 19:06:04 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Dec 2009 18:06:04 +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: <1260209164.61.0.218414576265.issue1771@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file15463/unnamed

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

From report at bugs.python.org  Mon Dec  7 19:06:08 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Dec 2009 18:06:08 +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: <1260209168.8.0.298443295646.issue1771@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file15473/unnamed

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

From report at bugs.python.org  Mon Dec  7 19:10:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Dec 2009 18:10: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: <1260209429.67.0.564831989406.issue1771@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Python's sort implementation is carefully written to only use the "<" 
comparison, ever.  So a cmp really isn't the most natural way to specify 
a comparison.  (This should really be documented somewhere -- I know know 
it because Tim Peters & I shared an office while he did most of the work 
on Python's sort.)

----------

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

From report at bugs.python.org  Mon Dec  7 19:22:54 2009
From: report at bugs.python.org (djc)
Date: Mon, 07 Dec 2009 18:22:54 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1260210174.15.0.922995908623.issue1537721@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

I'd like to commit this, but it would be nice to get a review first:

Index: Lib/csv.py
===================================================================
--- Lib/csv.py	(revision 76697)
+++ Lib/csv.py	(working copy)
@@ -132,6 +132,10 @@
         self.extrasaction = extrasaction
         self.writer = writer(f, dialect, *args, **kwds)
 
+    def writeheader(self):
+        header = dict(zip(self.fieldnames, self.fieldnames))
+        self.writerow(header)
+
     def _dict_to_list(self, rowdict):
         if self.extrasaction == "raise":
             wrong_fields = [k for k in rowdict if k not in self.fieldnames]
Index: Lib/test/test_csv.py
===================================================================
--- Lib/test/test_csv.py	(revision 76697)
+++ Lib/test/test_csv.py	(working copy)
@@ -598,8 +598,10 @@
         fileobj = os.fdopen(fd, "w+b")
         try:
             writer = csv.DictWriter(fileobj, fieldnames = ["f1", "f2",
"f3"])
+            writer.writeheader()
             writer.writerow({"f1": 10, "f3": "abc"})
             fileobj.seek(0)
+            self.assertEqual(fileobj.readline(), "f1,f2,f3\r\n")
             self.assertEqual(fileobj.read(), "10,,abc\r\n")
         finally:
             fileobj.close()

(I think I have commit privileges already.)

----------

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

From report at bugs.python.org  Mon Dec  7 19:51:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Dec 2009 18:51:14 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1260211874.99.0.120559499357.issue1859@psf.upfronthosting.co.za>


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

Thanks for the feedback, Greg!

I'm afraid I'm unassigning this;  I don't have time for it right now, and 
I'm not sure I'm the right person to do this anyway.

One problem that I was having when I looked at this:  I don't think I 
understand what the intended use of replace_whitespace=False is in the 
first place.  Given that a typical piece of (English) text only contains 
the ' ', '\t' ad '\n' whitespace characters, if expand_tabs is True (the 
default), then it seems that newline characters are the only ones affected 
by replace_whitespace=False.

How is replace_whitespace=False expected to be used currently?

----------
assignee: mark.dickinson -> 

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

From report at bugs.python.org  Mon Dec  7 19:58:01 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Dec 2009 18:58:01 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1260212281.55.0.0465593784259.issue6058@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Could you provide some official reference defining the alias ?

Thanks.

----------

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

From report at bugs.python.org  Mon Dec  7 20:07:46 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Dec 2009 19:07:46 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1260212866.55.0.166506835118.issue6058@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Nevermind, I found this reference:

http://msdn.microsoft.com/en-us/library/system.text.encoding(VS.80).aspx

Looks like we could add a few more aliases for other encodings as well.

----------

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

From report at bugs.python.org  Mon Dec  7 21:16:13 2009
From: report at bugs.python.org (GD)
Date: Mon, 07 Dec 2009 20:16:13 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted
	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1260216973.48.0.952471864706.issue7437@psf.upfronthosting.co.za>


Changes by GD <downgeoff2 at hotmail.com>:


----------
nosy: +GD

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

From report at bugs.python.org  Mon Dec  7 21:32:35 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Dec 2009 20:32:35 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1260217955.14.0.343595662456.issue6247@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Argparse seems to be overloaded with rarely used features. Instead of providing 
API to add these features and allow users copy examples it tends to be an all-in-
one solution that is hard to use due to abundance of specific parameters.

Look at constructor, for example - 
http://argparse.googlecode.com/svn/tags/r101/doc/ArgumentParser.html#usage
{{{
description - Text to display before the argument help.
epilog - Text to display after the argument help.
version - A version number used to add a -v/?version option to the parser.
add_help - Add a -h/?help option to the parser. (default: True)
argument_default - Set the global default value for arguments. (default: None)
parents - A list of :class:ArgumentParser objects whose arguments should also be 
included.
prefix_chars - The set of characters that prefix optional arguments. (default: ?-
?)
fromfile_prefix_chars - The set of characters that prefix files from which 
additional arguments should be read. (default: None)
formatter_class - A class for customizing the help output.
conflict_handler - Usually unnecessary, defines strategy for resolving conflicting 
optionals.
prog - Usually unnecessary, the name of the program (default: sys.argv[0])
usage - Usually unnecessary, the string describing the program usage (default: 
generated)
}}}

the only useful arguments by default is 'description' and 'add_help' (which is 
better to see as 'no_help' to turn off default behaviour). 'version' is not 
useful, because it adds '-v' shorthand that is often used for verbosity. 
'prefix_chars' is not useful, because the only sense one may need it is to provide 
windows conventions like '/longarg' for '--longarg' and not '//longarg', but it 
doesn't allow to do so.

Everything else is constructor bloat, and even with such abundance of options it 
still unable to generate usage help prefixed by program name and version - the 
sole feature I miss from optparse.

-1 for now

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Dec  7 21:40:48 2009
From: report at bugs.python.org (Shawn)
Date: Mon, 07 Dec 2009 20:40:48 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260218448.14.0.721194772265.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

The attached patch doubles write times for my particular case when
applied to simplejson trunk using python 2.6.2.  Not good.

----------

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

From report at bugs.python.org  Mon Dec  7 21:41:07 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 07 Dec 2009 20:41:07 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1260218467.74.0.0928206000007.issue1537721@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I'm sorry, but I don't have time to look at this right now.  On the one
hand, one person asks for more symmetry.  Someone else wants to add a
writeheader method.  If you want symmetry shouldn't the DictWriter
simply write the header without being asked?  I'm confused by the
various options and feel that someone is going to be disappointed by any
solution.  For the time being at least I would prefer that the status
quo remain in place.

S

----------

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

From report at bugs.python.org  Mon Dec  7 21:43:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 20:43:09 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1260218448.14.0.721194772265.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260218619.3381.19.camel@localhost>


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

> The attached patch doubles write times for my particular case when
> applied to simplejson trunk using python 2.6.2.  Not good.

What do you mean by "write times"? The patch only affects decoding.

----------

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

From report at bugs.python.org  Mon Dec  7 21:55:24 2009
From: report at bugs.python.org (Shawn)
Date: Mon, 07 Dec 2009 20:55:24 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260219324.21.0.192465125046.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

You are right, an environment anomaly let me to falsely believe that
this had somehow affected encoding performance.

I had repeated the test many times with and without the patch using
simplejson trunk and wrongly concluded that the patch was to blame.

After correcting the environment, write performance returned to normal.

This patch seems to perform roughly the same for my decode cases, but
uses about 10-20MB less memory.  My needs are far less than that of the
other poster.

However, this bug is about the serializer (encoder).  So perhaps the
decode performance patch should be a separate bug?

----------

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

From report at bugs.python.org  Mon Dec  7 21:59:38 2009
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 07 Dec 2009 20:59:38 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1260219578.78.0.545250946946.issue6247@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

@techtonik: If you have a specific feature request for argparse, I
recommend that you file an issue on the argparse tracker[1]. I assure
you that despite the fact that you only have need for a couple of the
constructor parameters, the rest exist because people have asked for
them. Fortunately, since they're keyword parameters, you only have to
specify the ones that you care about.

[1]http://code.google.com/p/argparse/issues/list

----------

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

From report at bugs.python.org  Mon Dec  7 22:01:04 2009
From: report at bugs.python.org (Shawn)
Date: Mon, 07 Dec 2009 21:01:04 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260219664.61.0.402353080103.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

I've attached a sample JSON file that is much slower to write out on
some systems as described in the initial comment.

If you were to restructure the contents of this file into more of a tree
structure instead of the flat array structure it uses now, you will
notice that as the depth increases, serializer performance decreases
significantly.

----------
Added file: http://bugs.python.org/file15475/catalog.dependency.C.gz

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

From report at bugs.python.org  Mon Dec  7 22:02:31 2009
From: report at bugs.python.org (djc)
Date: Mon, 07 Dec 2009 21:02:31 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1260219751.8.0.564463666124.issue1537721@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Skip, I agree that it's hard to decide if we should have the class write
the header on __init__(). I figured starting off with a method to make
doing it "manually" is a good start; people can start using that, and if
it's deemed useful we can always add the auto-write later.

----------

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

From report at bugs.python.org  Mon Dec  7 22:11:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Dec 2009 21:11:32 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1260220292.86.0.487354925272.issue5672@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Dec  7 22:13:54 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Dec 2009 21:13:54 +0000
Subject: [issue7450] document that os.chmod accepts an octal digit mode
In-Reply-To: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
Message-ID: <1260220434.04.0.539360259089.issue7450@psf.upfronthosting.co.za>


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

I think you misunderstand what's happening. It's not that os.chmod
accepts octal digits, but Python:

py> 04732
2522

So the support for octal numbers isn't something that chmod deserves
credit for.

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

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

From report at bugs.python.org  Mon Dec  7 22:19:18 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Dec 2009 21:19:18 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1260212866.55.0.166506835118.issue6058@psf.upfronthosting.co.za>
Message-ID: <4B1D7150.5020405@v.loewis.de>


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

> http://msdn.microsoft.com/en-us/library/system.text.encoding(VS.80).aspx
> 
> Looks like we could add a few more aliases for other encodings as well.

I wouldn't trust this table. Microsoft is on record of implementing the
code pages with slight variations compared to other references for some
encodings (in particular the Asian ones). So unless there is an actual
documented need for a certain alias (and preferably a demonstration that
Microsoft's interpretation of the code page is the same as Python's),
I would advise against adding such aliases.

----------

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

From report at bugs.python.org  Mon Dec  7 22:41:51 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Dec 2009 21:41:51 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <4B1D7150.5020405@v.loewis.de>
Message-ID: <4B1D769C.3010605@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> http://msdn.microsoft.com/en-us/library/system.text.encoding(VS.80).aspx
>>
>> Looks like we could add a few more aliases for other encodings as well.
> 
> I wouldn't trust this table. Microsoft is on record of implementing the
> code pages with slight variations compared to other references for some
> encodings (in particular the Asian ones). So unless there is an actual
> documented need for a certain alias (and preferably a demonstration that
> Microsoft's interpretation of the code page is the same as Python's),
> I would advise against adding such aliases.

Fair enough.

Could someone with some IronPython/.NET foo check whether the
code pages are the same as the Python codecs ?

The above page has some sample code to get started and IronPython
provides easy access to both the .NET codecs and the Python ones.

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/issue6058>
_______________________________________

From report at bugs.python.org  Mon Dec  7 22:57:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 21:57:46 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1260223066.28.0.57371773514.issue6058@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +michael.foord

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

From report at bugs.python.org  Mon Dec  7 22:59:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 21:59:04 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1260223144.81.0.540527211376.issue1537721@psf.upfronthosting.co.za>


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

We can't change default behaviour because it will break compatibility,
so an additional method looks ok to me.

----------
nosy: +pitrou
stage: test needed -> patch review
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Mon Dec  7 23:22:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Dec 2009 22:22:13 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1260224533.66.0.815491106512.issue7342@psf.upfronthosting.co.za>


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

Simple patch that fixes the test using a datetime object with a specific
number of microseconds instead of using datetime.now().

The test only checks that _strptime._strptime returns the correct value
for the microseconds, in test_datetime there are already other tests
(e.g. TestTime.test_str) that check that the microseconds are present
only if the value is different from 0.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file15476/issue7342.patch

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

From report at bugs.python.org  Mon Dec  7 23:41:42 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Dec 2009 22:41:42 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1260225702.86.0.813207379272.issue6058@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's a script for IronPython 2.6 that checks a few encoders.

Since IronPython doesn't appear to come with the full set of Python
codecs and it's also not clear whether the implemented codecs actually
match the default Python ones, I'm not sure how reliable this output is.

It's probably better to dump the encoded data to a file and compare
against a CPython run.

Anyway, here's the output:

Code Page 65000 vs. encoding 'utf-7'

0 errors

Code Page 65001 vs. encoding 'utf-8'

0 errors

Code Page 1200 vs. encoding 'utf-16-le'

0 errors

Code Page 1201 vs. encoding 'utf-16-be'

0 errors

Code Page 28591 vs. encoding 'iso-8859-1'

0 errors

----------
Added file: http://bugs.python.org/file15477/testnetcodecs.py

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

From report at bugs.python.org  Mon Dec  7 23:49:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Dec 2009 22:49:02 +0000
Subject: [issue7450] document that os.chmod accepts an octal digit mode
In-Reply-To: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
Message-ID: <1260226142.22.0.325815735687.issue7450@psf.upfronthosting.co.za>


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

If using octal digits instead of the stat.S_I constants is acceptable,
I'd be +1 to add a note to the documentation (something like "mode could
be a number (possibly expressed in octal form, such as 0755), one of the
following values (as defined in the stat module), or a bitwise ORed
combinations of them:").

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 00:08:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:08:23 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch does two things:
- it speeds up decoding of JSON objects by doing fewer temporary allocations
- it reduces memory use of decoded JSON objects by reusing key strings
when they appear several times in a JSON string

----------
components: Library (Lib)
files: json-opts2.patch
keywords: patch
messages: 96082
nosy: bob.ippolito, pitrou, rhettinger, vkuznet
priority: normal
severity: normal
stage: patch review
status: open
title: improve json decoding performance
type: performance
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15478/json-opts2.patch

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

From report at bugs.python.org  Tue Dec  8 00:09:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:09:18 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260227358.28.0.673780486067.issue6594@psf.upfronthosting.co.za>


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

> However, this bug is about the serializer (encoder).  So perhaps the
> decode performance patch should be a separate bug?

You're right, I've filed a separate bug for it: issue7451.

----------
stage: patch review -> needs patch

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

From report at bugs.python.org  Tue Dec  8 00:09:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:09:27 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260227367.24.0.56112032971.issue6594@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15450/json-opts2.patch

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

From report at bugs.python.org  Tue Dec  8 00:23:43 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 23:23:43 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260228223.67.0.805794314743.issue5596@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15479/issue5596_urllib_py3k.diff

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

From report at bugs.python.org  Tue Dec  8 00:24:08 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 23:24:08 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260228248.73.0.973681254114.issue5596@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15480/issue5596_pipes_py3k.diff

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

From report at bugs.python.org  Tue Dec  8 00:26:32 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 23:26:32 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260228392.64.0.0134581837967.issue5596@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch for the test refleaks:
 * test_pipes
 * test_urllib

----------

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

From report at bugs.python.org  Tue Dec  8 00:33:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 07 Dec 2009 23:33:34 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

When trying to build 2.7a1 I ran into the following problem on MacOSX 
10.4 (Tiger):

$ ./configure --enable-framework --enable-universalsdk
[...]
$ make
[...]
gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -
fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -
I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/pymath.o 
Python/pymath.c
/var/tmp//ccGDYNCp.s:36:Invalid mnemonic 'fnstcw'
/var/tmp//ccGDYNCp.s:56:Invalid mnemonic 'fldcw'
lipo: can't open input file: /var/tmp//cc4UBrqs.out (No such file or 
directory)
make: *** [Python/pymath.o] Error 1

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: config.log
messages: 96085
nosy: ronaldoussoren, srid
severity: normal
status: open
title: Invalid mnemonic 'fnstcw'
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file15481/config.log

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

From report at bugs.python.org  Tue Dec  8 00:34:18 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 07 Dec 2009 23:34:18 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260228858.65.0.53479365859.issue7452@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This error only occurs when I specify --enable-framework and --enable-
universalsdk to ./configure.

----------

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

From report at bugs.python.org  Tue Dec  8 00:38:47 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Dec 2009 23:38:47 +0000
Subject: [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1260229127.85.0.0981625608981.issue7447@psf.upfronthosting.co.za>


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

There are also a couple more things that could be improved in the
documentation of sum():
1) add a note about the "performance trap" mentioned by Alex [1]
2) remove the reduce() example because, even if it's true for that
particular example, it's not always true for the general case (in the
py3 doc it has been removed already).

See also [2] and the other messages in that thread.

[1]: http://mail.python.org/pipermail/python-dev/2003-October/039529.html
[2]: http://mail.python.org/pipermail/python-dev/2003-October/039586.html

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Tue Dec  8 00:41:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:41:50 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1260229310.03.0.728215550528.issue6594@psf.upfronthosting.co.za>


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

Your example takes 0.5s to dump here.

----------

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

From report at bugs.python.org  Tue Dec  8 00:42:21 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 07 Dec 2009 23:42:21 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
In-Reply-To: <1260223144.81.0.540527211376.issue1537721@psf.upfronthosting.co.za>
Message-ID: <19229.37591.763254.796952@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> We can't change default behaviour because it will break
    Antoine> compatibility, so an additional method looks ok to me.

Why can't default behavior be changed?

S

----------

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

From report at bugs.python.org  Tue Dec  8 00:44:40 2009
From: report at bugs.python.org (flox)
Date: Mon, 07 Dec 2009 23:44:40 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260229480.97.0.156918048146.issue5596@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

And the test_urllib may leak on 2.7, too.

Patch attached.

----------
Added file: http://bugs.python.org/file15482/issue5596_urllib.diff

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

From report at bugs.python.org  Tue Dec  8 00:45:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Dec 2009 23:45:06 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
In-Reply-To: <19229.37591.763254.796952@montanaro.dyndns.org>
Message-ID: <1260229537.3381.22.camel@localhost>


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

Le lundi 07 d?cembre 2009 ? 23:42 +0000, Skip Montanaro a ?crit :
> Skip Montanaro <skip at pobox.com> added the comment:
> 
> Antoine> We can't change default behaviour because it will break
>     Antoine> compatibility, so an additional method looks ok to me.
> 
> Why can't default behavior be changed?

Well, because it will break assumptions about the generated documents?

----------

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

From report at bugs.python.org  Tue Dec  8 00:48:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Dec 2009 23:48:03 +0000
Subject: [issue7432] Py3k doc: "from __future__ import division" not necessary
In-Reply-To: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
Message-ID: <1260229683.19.0.991498429215.issue7432@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/issue7432>
_______________________________________

From report at bugs.python.org  Tue Dec  8 00:49:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Dec 2009 23:49:38 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1260229778.6.0.475705499008.issue4380@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/issue4380>
_______________________________________

From report at bugs.python.org  Tue Dec  8 01:00:17 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 00:00:17 +0000
Subject: [issue7453] HPUX: socketmodule.c -- error 1588: "AI_PASSIVE"
	undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

At line 790, the constant AI_PASSIVE is used without doing a ifdef check 
(like done at around 5235). 

building '_socket' extension
cc +DAportable -Ae -D_REENTRANT +Z +z -DNDEBUG -O -I. -I./Include -
IInclude -I/home/apy/rrun/build/activepython-DEV/build/py2_7a1-
hpux11_00-parisc-apy27-rrun/python -c /home/apy/rrun/build/activepython-
DEV/build/py2_7a1-hpux11_00-parisc-apy27-
rrun/python/Modules/socketmodule.c -o build/temp.hp-ux-B.11.00-9000-800-
2.7/home/apy/rrun/build/activepython-DEV/build/py2_7a1-hpux11_00-parisc-
apy27-rrun/python/Modules/socketmodule.o
cc: "/home/apy/rrun/build/activepython-DEV/build/py2_7a1-hpux11_00-
parisc-apy27-rrun/python/Modules/socketmodule.c", line 790: error 1588: 
"AI_PASSIVE" undefined.

----------
components: Build, Library (Lib)
messages: 96092
nosy: srid
severity: normal
status: open
title: HPUX: socketmodule.c -- error 1588: "AI_PASSIVE" undefined.
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  8 01:08:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Dec 2009 00:08:25 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260230905.93.0.436156404381.issue7451@psf.upfronthosting.co.za>


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

The problem with this is that it makes json in Python diverge even more
from the simplejson trunk.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Dec  8 01:12:40 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 00:12:40 +0000
Subject: [issue7454] Solaris SPARC: _multiprocessing.so: symbol sem_timedwait:
	referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

[...]
cc -xcode=pic32 -DNDEBUG -O -DHAVE_SEM_TIMEDWAIT=0 -
IModules/_multiprocessing -I. -I./Include -IInclude -
I/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python -c /export/home/apy/rrun/build/activepython-
DEV/build/py2_7a1-solaris8-sparc-apy27-
rrun/python/Modules/_multiprocessing/semaphore.c -o build/temp.solaris-
2.8-sun4u-2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-
solaris8-sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.o
"/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.c", line 318: 
warning: implicit function declaration: sem_timedwait
cc -G build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/multiprocessing.o 
build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/socket_connection.o 
build/temp.solaris-2.8-sun4u-
2.7/export/home/apy/rrun/build/activepython-DEV/build/py2_7a1-solaris8-
sparc-apy27-rrun/python/Modules/_multiprocessing/semaphore.o -o 
build/lib.solaris-2.8-sun4u-2.7/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: 
ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-
sun4u-2.7/_multiprocessing.so: symbol sem_timedwait: referenced symbol 
not found

$ uname -a
SunOS nail 5.8 Generic_117350-55 sun4u sparc SUNW,Sun-Fire-280R

----------
components: Build, Library (Lib)
files: config.log
messages: 96094
nosy: srid
severity: normal
status: open
title: Solaris SPARC: _multiprocessing.so: symbol sem_timedwait: referenced symbol not found
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file15483/config.log

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

From report at bugs.python.org  Tue Dec  8 01:20:45 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 00:20:45 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260231645.44.0.603402298331.issue5596@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Dec  8 01:26:23 2009
From: report at bugs.python.org (naktinis)
Date: Tue, 08 Dec 2009 00:26:23 +0000
Subject: [issue1495089] sys.getfilesystemencoding
Message-ID: <1260231983.26.0.869443971414.issue1495089@psf.upfronthosting.co.za>


naktinis <naktinis at gmail.com> added the comment:

I guess this is still not answered.
Documentation (http://docs.python.org/library/sys.html) clearly states:
"On Unix, the encoding is the user?s preference according to the result
of nl_langinfo(CODESET), or None if the nl_langinfo(CODESET) failed."

So in case setlocale is not yet called the actual output should look
like this (according to documentation):
>>> import sys
>>> print sys.getfilesystemencoding()
None

According to the documentation if nl_langinfo(CODESET) returns
something, then sys.getfilesystemencoding() should return the very same
thing. Apparently this is not the case in the provided code. I also get
different output on my machine.

Or am I missing something?

----------
nosy: +naktinis

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

From report at bugs.python.org  Tue Dec  8 01:40:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 00:40:04 +0000
Subject: [issue7453] HPUX: socketmodule.c -- error 1588: "AI_PASSIVE"
	undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1260232804.47.0.0655482420633.issue7453@psf.upfronthosting.co.za>


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

Are you sure it isn't defined somewhere? HP claims it exists:
http://www.docs.hp.com/en/B3921-90010/getaddrinfo.3N.html

On the other hand, it seems commenting out this line doesn't harm any
existing test, so we could enable it conditionally.

----------
nosy: +loewis, pitrou
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 01:41:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 00:41:51 +0000
Subject: [issue7454] Solaris SPARC: _multiprocessing.so: symbol sem_timedwait:
	referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1260232911.8.0.175078687499.issue7454@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 01:42:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 00:42:48 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260232968.44.0.434013472695.issue7451@psf.upfronthosting.co.za>


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

Unless Bob applies it to simplejson as well, that is.

----------

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

From report at bugs.python.org  Tue Dec  8 01:53:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 00:53:33 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260233613.67.0.0680315662045.issue7451@psf.upfronthosting.co.za>


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

I've just noticed that there is a persistent decoder instance in
`json._default_decoder`. To avoid keeping references to past keys
forever, this updated patch clears the memo dict when a string has
finished decoding.

----------

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

From report at bugs.python.org  Tue Dec  8 01:54:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 00:54:36 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260233676.93.0.0473582413611.issue7451@psf.upfronthosting.co.za>


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

Here is the patch.

----------
Added file: http://bugs.python.org/file15484/json-opts3.patch

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

From report at bugs.python.org  Tue Dec  8 01:59:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 00:59:47 +0000
Subject: [issue7453] HPUX: socketmodule.c -- error 1588: "AI_PASSIVE"
	undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1260233987.21.0.395242965575.issue7453@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Yes, I even tried grep'ing the system header files. BTW, the build works 
fine on a newer HP-UX machine (11.22), whereas it fails only on a 
particular older version:

$ uname -a
HP-UX bertha B.11.00 U 9000/800 136901587 unlimited-user license

The documentation link you gave is applicable to 11i (which is >= 
11.11).

So I presume that AI_PASSIVE was made available only in later versions 
of HP-UX.

----------

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

From report at bugs.python.org  Tue Dec  8 02:00:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 01:00:04 +0000
Subject: [issue7453] HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE"
	undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1260234004.52.0.173534162851.issue7453@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
title: HPUX: socketmodule.c -- error 1588: "AI_PASSIVE" undefined. -> HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE" undefined.

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

From report at bugs.python.org  Tue Dec  8 02:22:12 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 01:22:12 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260235332.18.0.928669139402.issue5596@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Another false-positive in test_zipimport_support.
Both on 2.7 and 3.2.

Patch attached.

----------
Added file: http://bugs.python.org/file15485/issue5596_zipimport_support.diff

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

From report at bugs.python.org  Tue Dec  8 02:23:13 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 01:23:13 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260235393.17.0.835811414039.issue5596@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15486/issue5596_zipimport_support_py3k.diff

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

From report at bugs.python.org  Tue Dec  8 02:34:57 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 08 Dec 2009 01:34:57 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
In-Reply-To: <1260229537.3381.22.camel@localhost>
Message-ID: <19229.44347.937442.566146@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> We can't change default behaviour because it will break
    Antoine> compatibility, so an additional method looks ok to me.

    >> Why can't default behavior be changed?

    Antoine> Well, because it will break assumptions about the generated documents?

Isn't the alpha period (2.7 and 3.2 in this case) precisely when an API can
change?

Skip

----------

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

From report at bugs.python.org  Tue Dec  8 02:40:21 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 01:40:21 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
In-Reply-To: <19229.44347.937442.566146@montanaro.dyndns.org>
Message-ID: <1260236451.3381.25.camel@localhost>


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

> Isn't the alpha period (2.7 and 3.2 in this case) precisely when an API can
> change?

Well, it can, but only if there are compelling reasons to do so. It
should be the exception rather than the rule.
The reasons here seem far from compelling, and moreover we can't detect
whether the user is expecting the new or the old behaviour.

----------

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

From report at bugs.python.org  Tue Dec  8 03:00:30 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 08 Dec 2009 02:00:30 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
In-Reply-To: <1260236451.3381.25.camel@localhost>
Message-ID: <19229.45882.7244.687730@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> Isn't the alpha period (2.7 and 3.2 in this case) precisely when an
    >> API can change?

    Antoine> Well, it can, but only if there are compelling reasons to do
    Antoine> so. It should be the exception rather than the rule.  The
    Antoine> reasons here seem far from compelling, and moreover we can't
    Antoine> detect whether the user is expecting the new or the old
    Antoine> behaviour.

Fine.  Dirkjan, assuming there are the necessary test cases and
documentation changes, feel free to check in your patch and close the
ticket.

Skip

----------

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

From report at bugs.python.org  Tue Dec  8 03:22:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Dec 2009 02:22:19 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260238939.24.0.502353774572.issue5596@psf.upfronthosting.co.za>


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


----------
nosy:  -r.david.murray

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

From report at bugs.python.org  Tue Dec  8 03:25:49 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 08 Dec 2009 02:25:49 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260239149.83.0.418600782643.issue5596@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/issue5596>
_______________________________________

From report at bugs.python.org  Tue Dec  8 03:44:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 08 Dec 2009 02:44:38 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1260240278.99.0.405403145321.issue6071@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Will this be fixed for Python 2.7 final?

----------

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

From report at bugs.python.org  Tue Dec  8 03:59:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 02:59:19 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>


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

load_pop() pops a value if the stack length is >= 0. The test is wrong:
if the length is zero, the stack is empty and stackUnderflow() have to
be called.

Example:

  $ ../../python -c "import cPickle; cPickle.loads('0')"
  Erreur de segmentation

----------
components: Extension Modules
files: cpickle_load_pop.patch
keywords: patch
messages: 96106
nosy: haypo
severity: normal
status: open
title: cPickle: stack underflow in load_pop()
versions: Python 2.7
Added file: http://bugs.python.org/file15487/cpickle_load_pop.patch

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

From report at bugs.python.org  Tue Dec  8 07:20:15 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 08 Dec 2009 06:20:15 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260253215.5.0.292494658635.issue7455@psf.upfronthosting.co.za>


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

Can you add a test for this?

----------
nosy: +eric.smith
stage:  -> test needed

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

From report at bugs.python.org  Tue Dec  8 07:40:37 2009
From: report at bugs.python.org (nirinA raseliarison)
Date: Tue, 08 Dec 2009 06:40:37 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260254437.5.0.733088346316.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

having the gamma function, one certainly needs the other Euler constant:
C = 0.5772....

the C constant is taken from GSL

----------
Added file: http://bugs.python.org/file15488/pymath.h.diff

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

From report at bugs.python.org  Tue Dec  8 07:41:21 2009
From: report at bugs.python.org (nirinA raseliarison)
Date: Tue, 08 Dec 2009 06:41:21 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260254481.46.0.775216948342.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

for expm1, we use the Taylor development near zero, but
we have to precise what means small value for x. here this means
abs(x) < math.log(2.0).
one can also use abs(x) < C

----------
Added file: http://bugs.python.org/file15489/mathmodule.c.diff

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

From report at bugs.python.org  Tue Dec  8 07:42:01 2009
From: report at bugs.python.org (nirinA raseliarison)
Date: Tue, 08 Dec 2009 06:42:01 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260254521.97.0.869082071103.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

finally, for the error function, with the same kind of idea as with expm1,
here is a pure python definition

these patches are against r27a1:76674

if all these make sense, i'll check for NAN, infinity, test suite...

----------
Added file: http://bugs.python.org/file15490/erf.py

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

From report at bugs.python.org  Tue Dec  8 07:53:03 2009
From: report at bugs.python.org (nirinA raseliarison)
Date: Tue, 08 Dec 2009 06:53:03 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260255183.17.0.785436778577.issue3366@psf.upfronthosting.co.za>


nirinA raseliarison <nirina at mail.blueline.mg> added the comment:

may be some error when i send this the first time,
i cannot see the file, so i resend mathmodule.c.diff
sorry if you get it twice

----------
Added file: http://bugs.python.org/file15491/mathmodule.c.diff

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

From report at bugs.python.org  Tue Dec  8 08:46:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 07:46:24 +0000
Subject: [issue7456] rfc822.Message.getheaders undocumented
In-Reply-To: <1260258384.35.0.620529013187.issue7456@psf.upfronthosting.co.za>
Message-ID: <1260258384.35.0.620529013187.issue7456@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

rfc822 misses a doc about getheaders. 

Also, I am wondering why getheaders can't take a default value like
getheader.

----------
assignee: georg.brandl
components: Documentation
messages: 96112
nosy: georg.brandl, tarek
severity: normal
status: open
title: rfc822.Message.getheaders undocumented
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 09:32:54 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 08:32:54 +0000
Subject: [issue7457] Adding a read_pkg_file to DistributionMetadata
In-Reply-To: <1260261174.05.0.469810624752.issue7457@psf.upfronthosting.co.za>
Message-ID: <1260261174.05.0.469810624752.issue7457@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This API will allow readong back static PKG-INFO files.

----------
assignee: tarek
components: Distutils
messages: 96113
nosy: tarek
priority: normal
severity: normal
status: open
title: Adding a read_pkg_file to DistributionMetadata
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 09:55:31 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Dec 2009 08:55:31 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260262531.06.0.781856357291.issue7452@psf.upfronthosting.co.za>


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

Works for me on 10.4.11 PPC (G3) machine rather than Intel (which 
shouldn't make a difference).  But from your config.log, the gcc version 
is older than what I have on 10.4 (build 5250 vs build 5370).  Suggest 
ensuring you have the most recent Xcode for 10.4 installed.

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

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

From report at bugs.python.org  Tue Dec  8 10:38:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 09:38:11 +0000
Subject: [issue7456] rfc822.Message.getheaders undocumented
In-Reply-To: <1260258384.35.0.620529013187.issue7456@psf.upfronthosting.co.za>
Message-ID: <1260265091.06.0.55194986474.issue7456@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Forget about this, I have realized this module is deprecated in python 3.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Dec  8 11:03:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Dec 2009 10:03:39 +0000
Subject: [issue7457] Adding a read_pkg_file to DistributionMetadata
In-Reply-To: <1260261174.05.0.469810624752.issue7457@psf.upfronthosting.co.za>
Message-ID: <1260266619.72.0.836881951706.issue7457@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r76702 + r76704 (2.7) and r76706 (3.2)

----------
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Tue Dec  8 11:21:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:21:10 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>


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

str.find() and str.rfind() reads non initialized memory (using
memcmp()) if start is bigger than end.

Attached patch fixes the issue and includes a patch.

----------
components: Interpreter Core
messages: 96117
nosy: haypo
severity: normal
status: open
title: crash in str.find() and str.rfind() with invalid start value
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  8 11:21:48 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:21:48 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260267708.96.0.763863873974.issue7458@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file15492/str_find.patch

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

From report at bugs.python.org  Tue Dec  8 11:23:39 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:23:39 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260267819.22.0.0888776665031.issue7458@psf.upfronthosting.co.za>


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

In my test, start=6287518193 is an arbitrary value, it may crash or
not. The test might use any random integer > 0.

----------

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

From report at bugs.python.org  Tue Dec  8 11:33:16 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:33:16 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260268396.22.0.517334928296.issue7458@psf.upfronthosting.co.za>


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

The bug was introduced in Python 2.5 during the needforspeed sprint:
r46469 (May 27 2006).
http://wiki.python.org/moin/NeedForSpeed

Python < 2.5 is not affected, Python 3.x is affected.

CRASH_rfind.py is more stable and should always crash if your Python
version has the bug.

----------
Added file: http://bugs.python.org/file15493/CRASH_rfind.py

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

From report at bugs.python.org  Tue Dec  8 11:43:12 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 10:43:12 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260268992.08.0.18912653482.issue7458@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

This bug does not occur on Debian 64 bits.

 ~ $ uname -srvm
Linux 2.6.30-bpo.1-amd64 #1 SMP Mon Aug 17 08:42:50 UTC 2009 x86_64

Tested with variants:
        from random import getrandbits
        self.checkequal(-1, 'ab', 'find', 'xxx', getrandbits(64), 0)
        self.checkequal(-1, 'ab', 'find', 'xxx', getrandbits(96), 0)
        self.checkequal(-1, 'ab', 'rfind', 'xxx', getrandbits(64), 0)
        self.checkequal(-1, 'ab', 'rfind', 'xxx', getrandbits(96), 0)

----------
nosy: +flox

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

From report at bugs.python.org  Tue Dec  8 11:49:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 10:49:01 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260269341.6.0.168492953411.issue7455@psf.upfronthosting.co.za>


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

> Can you add a test for this?

I wasn't sure of the right place to add the test. I tried
Lib/test/pickletester.py, but it doesn't work because UnpicklingError
is not defined there.

Well, here is a new version of my patch with an unit test.

----------
Added file: http://bugs.python.org/file15494/cpickle_load_pop-2.patch

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

From report at bugs.python.org  Tue Dec  8 12:05:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 11:05:35 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260270335.15.0.122661044258.issue7458@psf.upfronthosting.co.za>


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

> This bug does not occur on Debian 64 bits.

It does, sometime :-) Read uninitiliazed memory doesn't always crash.

   $ python -c "'ab'.rfind('xxx', (1 << 63) + 10, 0)"
   Erreur de segmentation

Note: my 64 bits test in CRASH_rfind.py is wrong, ctypes.c_long should
be used instead of ctypes.c_int.

----------

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

From report at bugs.python.org  Tue Dec  8 12:11:57 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 11:11:57 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260270717.31.0.757409060036.issue7458@psf.upfronthosting.co.za>


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

New patch with a more stable test. test_unicode does also fail (error
or crash) without the patch on find.h.

----------
Added file: http://bugs.python.org/file15495/str_find-2.patch

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

From report at bugs.python.org  Tue Dec  8 12:21:39 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 11:21:39 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260271299.34.0.466254945101.issue7458@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I got it to crash (2.7):

~ $ ./python Lib/test/regrtest.py string_tests test_unicode test_str
test_unicode
test test_unicode failed -- Traceback (most recent call last):
AssertionError: -1 != -8276732

test_str
test test_str failed -- Traceback (most recent call last):
AssertionError: -1 != -255833

2 tests failed:
    test_unicode test_str
[56425 refs]
~ $ 

Thank you haypo :)

----------
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 12:27:37 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 11:27:37 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1260271657.67.0.834085074564.issue6986@psf.upfronthosting.co.za>


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

I wrote new patches to:
 - implement the "alternate method"
 - add unit tests
 - and finally to move the tests in the right file

Is the patch now correct? Can you apply it? It doesn't still crash
Python trunk and it generates a lot of noise in my fuzzer :-)

----------

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

From report at bugs.python.org  Tue Dec  8 13:53:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Dec 2009 12:53:22 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260276802.66.0.581263268854.issue7452@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Dec  8 13:54:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Dec 2009 12:54:09 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260276849.56.0.383717138432.issue7452@psf.upfronthosting.co.za>


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

Do you get the same problem with py3k?

----------

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

From report at bugs.python.org  Tue Dec  8 14:01:42 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 13:01:42 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260277302.76.0.224091249974.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Could you also post the generated pyconfig.h?

----------

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

From report at bugs.python.org  Tue Dec  8 16:01:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 15:01:04 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260284464.52.0.126564077281.issue7458@psf.upfronthosting.co.za>


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

You shouldn't harcode 1 << 63 and 1 << 64, but calculate them based on
sys.maxsize instead.

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Dec  8 16:32:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Dec 2009 15:32:48 +0000
Subject: [issue1495089] sys.getfilesystemencoding
Message-ID: <1260286368.36.0.251344498209.issue1495089@psf.upfronthosting.co.za>


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

This is surprisingly non-transparent.  However, it works as documented
in py3.

It sorta works as documented in p2, except that there's a bit left out
of the docs.

In py2, the code that results in getfilesystemencoding's value sets the
locale based on the environment, does the nl_langinfo(CODESET), and then
restores the locale to the default (C).

In py3, python initialization sets LC_CTYPE to the enviroment, and uses
that to determine getsystemfilencoding's default value.  LC_CTYPE is
left set to the environment.

This means that in py2, using locale.nl_langinfo doesn't get you the
same value that is used to set getfilesystemencoding until after you've
done a call to set the locale to the environment.  In py3, however,
locale.nl_langinfo(locale.CODESET) will by default return the value that
is used to set getfilesystemencoding's value.

If you'd like to submit a doc patch for p2, please feel free, and I'll
apply it.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Dec  8 16:35:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 15:35:07 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted
	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1260286507.43.0.175567777054.issue7437@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The problem shouldn't be present in 3.1 and 2.7, both trees no longer 
contain the ancient documentation files.

IMHO the best fix is to remove 
Mac/Resources/app/Resources/English.lproj/Documentation/ide/ (and the 
link to ide/index.html in .../Documentation/index.html).

Is anyone on the nosy list capable of testing such a patch? I can 
provide a 2.6.4+ installer with this fix, but cannot test the fix myself 
because I don't have access to a machine that's capable of running 10.3.

----------

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

From report at bugs.python.org  Tue Dec  8 16:36:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 15:36:00 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1260286560.9.0.840677015727.issue6986@psf.upfronthosting.co.za>


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

The patch looks good to me.

----------
priority:  -> high
resolution:  -> accepted
stage:  -> commit review
type:  -> crash
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 16:59:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 15:59:47 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260287987.75.0.266675022519.issue7458@psf.upfronthosting.co.za>


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

pitrou> You shouldn't harcode 1 << 63 and 1 << 64, but calculate 
pitrou> them based on sys.maxsize instead.

(sys.maxint) Yes, you're right. Does str_find-3.patch looks better?
It's not easy to always detect an Heisenbug :-)

----------
Added file: http://bugs.python.org/file15496/str_find-3.patch

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

From report at bugs.python.org  Tue Dec  8 17:06:55 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 16:06:55 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260288415.85.0.975136796209.issue7458@psf.upfronthosting.co.za>


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

sys.maxint/sys.maxsize: oops, sys.maxsize *does* exist (in Python >=
2.6), sorry. Here is a new patch using sys.maxsize.

Anyway, sys.maxsize sounds better because the integer overflow occurs
in a Py_ssize_t variable (j).

----------
Added file: http://bugs.python.org/file15497/str_find-4.patch

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

From report at bugs.python.org  Tue Dec  8 17:07:01 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 16:07:01 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260288421.74.0.837844459833.issue7458@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15496/str_find-3.patch

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

From report at bugs.python.org  Tue Dec  8 17:07:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 16:07:15 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260288435.03.0.369217535909.issue7458@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15492/str_find.patch

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

From report at bugs.python.org  Tue Dec  8 17:07:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 16:07:18 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260288438.94.0.693966238907.issue7458@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15493/CRASH_rfind.py

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

From report at bugs.python.org  Tue Dec  8 17:07:26 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 16:07:26 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260288446.85.0.997694853228.issue7458@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15495/str_find-2.patch

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

From report at bugs.python.org  Tue Dec  8 17:10:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 16:10:01 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1260288601.44.0.531898162648.issue6986@psf.upfronthosting.co.za>


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

This has been committed in r76708, r76710, r76711. Thank you!

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec  8 17:31:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:31:00 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260289860.39.0.428241186923.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is due to a block starting at '#ifdef HAVE_GCC_ASM_FOR_X87' in 
Python/pymath.c.

A simple patch to pymacconfig.h fixes the issue, I'll commit it once I've 
fully tested the result.

----------

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

From report at bugs.python.org  Tue Dec  8 17:37:34 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:37:34 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260290254.16.0.954925044579.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r76712 (trunk), r76713 (3.2), r76714 (3.1).

The python3 branches contained about half of the fix, I merged the trunk 
version into python3 anyway to keep all 3 branches in sync.

The issue does not affect the 2.6 branch.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Tue Dec  8 17:40:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:40:50 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two corrupted
	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1260290450.14.0.511787257937.issue7437@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should be fixed in r76715, I've removed the documentation that caused 
the installer issues in the first place.

----------
resolution:  -> fixed
stage:  -> test needed
status: open -> pending
type:  -> behavior

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

From report at bugs.python.org  Tue Dec  8 17:43:05 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:43:05 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1260290585.2.0.354092462942.issue6800@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: ronaldoussoren -> 

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

From report at bugs.python.org  Tue Dec  8 17:43:41 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 08 Dec 2009 16:43:41 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python/import.c defines magic word which is used in the beginning of
.pyc files to verify if .pyc files have been generated by compatible
version of Python.

Python 2 supports undocumented -U option increases magic word by 1.
Python 3 uses unicode strings by default and doesn't support -U option,
but seemingly incorrect change was committed in r55013, which causes
that magic word is always increased by 1 in Python 3 in contrary to
documentation, which says that it could only happen with some command
line options.

This problem cannot be fixed in Python 3.1.2 for compatibility with
e.g. 3.1.1, but it can be fixed in 3.2. Additionally documentation in
3.1.2 can be fixed.

----------
components: Interpreter Core
files: python-3.2-fix_magic_word.patch
keywords: patch
messages: 96138
nosy: Arfrever, gvanrossum
severity: normal
status: open
title: Magic word incorrect in Python 3
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15498/python-3.2-fix_magic_word.patch

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

From report at bugs.python.org  Tue Dec  8 17:44:22 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:44:22 +0000
Subject: [issue3432] Mac, 2.6 framework install error
In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>
Message-ID: <1260290662.95.0.366150610178.issue3432@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Is this issue still relevant? I cannot reproduce this on my machines.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Dec  8 17:45:28 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:45:28 +0000
Subject: [issue7190] Problems running threaded Tkinter program under OS X IDLE
In-Reply-To: <1256304335.58.0.401726660666.issue7190@psf.upfronthosting.co.za>
Message-ID: <1260290728.05.0.264843542233.issue7190@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: pending -> closed

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

From report at bugs.python.org  Tue Dec  8 17:52:14 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 08 Dec 2009 16:52:14 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260291134.74.0.00471433763721.issue7459@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file15499/python-3.1-fix_documentation_of_magic_word.patch

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

From report at bugs.python.org  Tue Dec  8 17:59:23 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 16:59:23 +0000
Subject: [issue7184] build failures on Snow Leopard
In-Reply-To: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
Message-ID: <1260291563.11.0.441771906595.issue7184@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

richard: could you please elaborate on what you think is wrong?

readline doesn't get build because OSX' libedit isn't good enough
for the readline module in 2.6, this is fixed in 2.7.

On my machine the other ones do get build, although I had to move 
/Library/Frameworks/Python.framework to the side to avoid picking up 
bits from the already installed 32-bit tree to get the curses bits to 
build.

As Ned noted the compiler on 10.6 creates 64-bit binaries by default. 
You may have 32-bit OSS libraries on your machine that cause problems 
during a 64-bit build.  If you want a 32-bit build rather than 64-bit 
one you can build a universal binary using --enable-universal-sdk=/

----------

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

From report at bugs.python.org  Tue Dec  8 18:20:57 2009
From: report at bugs.python.org (Lorenz Quack)
Date: Tue, 08 Dec 2009 17:20:57 +0000
Subject: [issue7460] extended slicing not sufficiently covered in docs
In-Reply-To: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>
Message-ID: <1260292857.39.0.569709796057.issue7460@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

I find the documentation regarding extended slicing to be lacking.
To be honest I couldn't find any documentation about it.
The only - and quite good - source of information I found was [1].
Maybe I didn't search enough. If so I would appreciate a link to the
relevant section.

In fact I didn't really know about extended slicing (except for the
start, stop, step notation) until I implemented a C extension and got a
TypeError in Python 3 because I was only supporting simple slicing. And
this is despite the fact that I don't consider myself a python n00b.

As I am still learning about this protocol at the time of writing. I
might have some things backwards and I don't feel qualified to improve
the docs myself. Instead I would like to point out where I would have
expected some information about this topic:

To begin improvement a hint around "PySequence_GetSlice" that this is a
more or less deprecated API and "tp_as_mapping->mp_subscript" should be
used instead would be useful. 
In addition "PyObject_GetItem/tp_as_mapping->mp_subscript" could say
that a slice object is passed when extended slicing is used.

sincerely yours
//Lorenz

PS: I marked this Python 3.x even though the documentation of 2.x lacks
as well because I only got the TypeError in 3.x whereas in 2.x
everything works fine with simple slicing.

[1] http://mail.python.org/pipermail/python-3000/2007-August/009851.html

----------
assignee: georg.brandl
components: Documentation
messages: 96141
nosy: donlorenzo, georg.brandl
severity: normal
status: open
title: extended slicing not sufficiently covered in docs
type: feature request
versions: Python 3.0, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 18:33:50 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 17:33:50 +0000
Subject: [issue7458] crash in str.find() and str.rfind() with invalid start
	value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260293630.56.0.237368357547.issue7458@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I reviewed the patch, and it seems partially redundant.

Actually the "find" method was not broken.
There is already a test "if (str_len < 0) return -1;" for this one.

See attached patch.

----------
Added file: http://bugs.python.org/file15501/issue7458_rfind.diff

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

From report at bugs.python.org  Tue Dec  8 18:36:39 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 17:36:39 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260293799.68.0.399179910622.issue7452@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> Do you get the same problem with py3k?

Not in 3.1.1 at least.

> Fixed in r76712 (trunk)

That fixes the issue. Thanks! Let me know if you still need pyconfig.h.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Dec  8 18:48:06 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Dec 2009 17:48:06 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260294486.86.0.102048556916.issue7452@psf.upfronthosting.co.za>


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

"PPC (G3) machine rather than Intel (which shouldn't make a difference)" 
... but did in this case. Perhaps it's too early in the morning yet but I 
don't see why that error doesn't show up for me when building trunk on an 
Intel machine under 10.6, i.e. this gives no error:
/usr/bin/gcc-4.0 -c -arch ppc -arch i386 -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -DNDEBUG -g -fwrapv 
-O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE 
-o Python/pymath.o Python/pymath.c
(This is with one patch to configure to fix the test for Darwin 10)

----------

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

From report at bugs.python.org  Tue Dec  8 18:58:12 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Dec 2009 17:58:12 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260295092.41.0.309523542878.issue7459@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't see a bug here. The value returned by imp.get_magic() matches the 
first bytes of a bytecode file. That's all that matters.

Of course, we could remove the global variable and just use the defined 
constant; but that's just an optimization, not a bugfix.

PS. The two uploaded patches look about the same?

----------

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

From report at bugs.python.org  Tue Dec  8 19:03:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Dec 2009 18:03:20 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260295400.71.0.501283990182.issue7452@psf.upfronthosting.co.za>


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

Ned:  maybe your pyconfig.h isn't defining HAVE_GCC_ASM_FOR_X87 in the first place, for some reason?

I *do* get that error for trunk / 10.6 (with the 10.5 SDK;  I don't have the 10.4 SDK installed):

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ /usr/bin/gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -I. 
-IInclude -o Python/pymath.o Python/pymath.c
/var/folders/nH/nHvjwWGlGMWNLkYlpsol8U+++TI/-Tmp-//ccq7GcaH.s:11:Invalid mnemonic 'fnstcw'
/var/folders/nH/nHvjwWGlGMWNLkYlpsol8U+++TI/-Tmp-//ccq7GcaH.s:26:Invalid mnemonic 'fldcw'
lipo: can't open input file: /var/folders/nH/nHvjwWGlGMWNLkYlpsol8U+++TI/-Tmp-//ccDS89Qs.out (No such file or directory)

----------

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

From report at bugs.python.org  Tue Dec  8 19:07:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2009 18:07:30 +0000
Subject: [issue7458] crash in str.rfind() with an invalid start value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1260295650.5.0.810744219217.issue7458@psf.upfronthosting.co.za>


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

flox> Actually the "find" method was not broken.

Oh, you're right, str.find() was already fixed by r66631 (related to
issue #3967). I prefer your patch flox ;-)

I fixed this issue title.

----------
title: crash in str.find() and str.rfind() with invalid start value -> crash in str.rfind() with an invalid start value

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

From report at bugs.python.org  Tue Dec  8 20:08:35 2009
From: report at bugs.python.org (GD)
Date: Tue, 08 Dec 2009 19:08:35 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two
	corrupted	file names, ignored on 10.4
In-Reply-To: <1260290450.14.0.511787257937.issue7437@psf.upfronthosting.co.za>
Message-ID: <BLU120-W86F5D3D9109E4D40DA20B828F0@phx.gbl>


GD <downgeoff2 at hotmail.com> added the comment:

Point me in the direction of a binary to download and I can test it for you.

GD 		 	   		  
_________________________________________________________________
Get gifts for them and cashback for you. Try Bing now.
http://www.bing.com/shopping/search?q=xbox+games&scope=cashback&form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Shopping_Giftsforthem_cashback_1x1

----------
status: pending -> open
title: OS X 2.6.4 installer fails on 10.3 with two corrupted file names, ignored on 10.4 -> OS X 2.6.4 installer fails on 10.3 with two corrupted	file names, ignored on 10.4
Added file: http://bugs.python.org/file15502/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7437>
_______________________________________
-------------- next part --------------
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br>Point me in the direction of a binary to download and I can test it for you.<br><br>GD 		 	   		  <br /><hr />Get gifts for them and cashback for you. <a href='http://www.bing.com/shopping/search?q=xbox+games&scope=cashback&form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Shopping_Giftsforthem_cashback_1x1' target='_new'>Try Bing now.</a></body>
</html>

From report at bugs.python.org  Tue Dec  8 20:45:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 19:45:41 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260301541.53.0.308602576207.issue5596@psf.upfronthosting.co.za>


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

I've committed fixes to test_urllib and test_zipimport_support similar
to the ones you proposed. Thank you!

----------

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

From report at bugs.python.org  Tue Dec  8 20:52:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 19:52:32 +0000
Subject: [issue7461] os.popen() objects don't support the context manager
	protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This works under trunk but fails under py3k:

>>> import os
>>> with os.popen("ls", "r") as f:
...  print(f.read())
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__

----------
components: Library (Lib)
messages: 96151
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: os.popen() objects don't support the context manager protocol
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  8 21:14:08 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Dec 2009 20:14:08 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260303248.11.0.489015306678.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: which version of Python do you build? The issue was only in the 
trunk (2.7), the other branches were fine (although the code in 3.1 and 
3.2 was suboptimal). BTW. The issue affected universal builds on all OSX 
versions.

The trunk should be fine now as well, as of r76712.

Sridhar: I don't need pyconfig.h. I was thinking of a configure issue 
where your machine behaved differently from what I'd expect. I turned 
out to be a universal-binary related issue.

Mark: what's the output of svnversion? I committed a fix in r76712, that 
fixed the issue for me on 10.6.

----------

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

From report at bugs.python.org  Tue Dec  8 21:38:34 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Dec 2009 20:38:34 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260304714.51.0.184272806983.issue7452@psf.upfronthosting.co.za>


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

Ronald, it's a more complicated configure issue. I'm in the middle of 
pinning down the details.  More shortly ...

----------

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

From report at bugs.python.org  Tue Dec  8 22:27:28 2009
From: report at bugs.python.org (Mark Wielaard)
Date: Tue, 08 Dec 2009 21:27:28 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1260307648.29.0.166110225667.issue4111@psf.upfronthosting.co.za>


Mark Wielaard <mjw at redhat.com> added the comment:

I took the patch and tweaked it a little so that it works with systemtap
(at least for the function entry/exit probes). It is against 2.6.2 since
that was what was in the Fedora 12 src package I was using. Cleaned up
the configure checks a little, but otherwise it is almost exactly as is.

Also tracked in Fedora as 
https://bugzilla.redhat.com/show_bug.cgi?id=545179

----------
components:  -Installation
title: Add DTrace probes -> Add Systemtap/DTrace probes
Added file: http://bugs.python.org/file15503/stap-python.patch

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

From report at bugs.python.org  Tue Dec  8 23:03:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Dec 2009 22:03:04 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260309784.52.0.99577542685.issue7452@psf.upfronthosting.co.za>


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

Ronald:  sorry, I wasn't clear.  I only get that failure before your fix;  
afterwards, it's fine.

----------

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

From report at bugs.python.org  Tue Dec  8 23:18:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Dec 2009 22:18:41 +0000
Subject: [issue7461] os.popen() objects don't support the context manager
	protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260310721.68.0.252754892298.issue7461@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch+test

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file15504/with_popen.patch

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

From report at bugs.python.org  Tue Dec  8 23:46:44 2009
From: report at bugs.python.org (flox)
Date: Tue, 08 Dec 2009 22:46:44 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

While looking at issue7458 I stopped on:

  /* XXX - create reversefastsearch helper! */

Here is the patch which is just the translation of the same algorithm
already implemented for "find/index".
http://effbot.org/zone/stringlib.htm

Note: it supersedes patch for 7458.

----------
components: Interpreter Core
files: fastsearch_rfind.patch
keywords: patch
messages: 96157
nosy: flox
severity: normal
status: open
title: Implement fastsearch algorithm for rfind/rindex
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15505/fastsearch_rfind.patch

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

From report at bugs.python.org  Wed Dec  9 00:43:01 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Dec 2009 23:43:01 +0000
Subject: [issue7454] Solaris SPARC: _multiprocessing.so: symbol sem_timedwait:
	referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1260315781.96.0.423613388919.issue7454@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file15506/pyconfig.h

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

From report at bugs.python.org  Wed Dec  9 00:46:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 23:46:29 +0000
Subject: [issue7461] os.popen() objects don't support the context manager
	protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260315989.69.0.724290173303.issue7461@psf.upfronthosting.co.za>


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

We should also proxy other special methods. There is __iter__, __next__,
what else?

----------

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

From report at bugs.python.org  Wed Dec  9 00:48:44 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 23:48:44 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260316124.95.0.312837876164.issue5596@psf.upfronthosting.co.za>


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

No leaks anymore!
http://mail.python.org/pipermail/python-checkins/2009-December/088162.html
Thanks flox!

----------

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

From report at bugs.python.org  Wed Dec  9 00:58:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Dec 2009 23:58:06 +0000
Subject: [issue7461] os.popen() objects don't support the context manager
	protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260316686.69.0.096544098527.issue7461@psf.upfronthosting.co.za>


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

Ah, iterating already works. Sorry for the noise.

----------

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

From report at bugs.python.org  Wed Dec  9 01:04:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Dec 2009 00:04:07 +0000
Subject: [issue7461] os.popen() objects don't support the context manager
	protocol
In-Reply-To: <1260301952.86.0.775558943909.issue7461@psf.upfronthosting.co.za>
Message-ID: <1260317047.08.0.67528769975.issue7461@psf.upfronthosting.co.za>


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

I added a test for iterating and committed the patch in r76723 and
r76724. Thanks!

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

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

From report at bugs.python.org  Wed Dec  9 01:06:01 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 09 Dec 2009 00:06:01 +0000
Subject: [issue7454] Solaris SPARC: _multiprocessing.so: symbol sem_timedwait:
	referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1260317161.3.0.275873794517.issue7454@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

After ./configure step, I made the following changes to pyconfig.h in 
order to fix this issue:

$ diff  pyconfig.h.orig pyconfig.h
561c561
< /* #undef HAVE_SEM_TIMEDWAIT */
---
> #undef HAVE_SEM_TIMEDWAIT

Ideally, something needs to be changed in configure.in I believe. 

It seems that this bug was introduced in r71009. Any idea Jesse/Martin?

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

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

From report at bugs.python.org  Wed Dec  9 01:24:21 2009
From: report at bugs.python.org (flox)
Date: Wed, 09 Dec 2009 00:24:21 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1260318261.72.0.917842148468.issue7462@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

(removed comment which should not be copied)

----------
Added file: http://bugs.python.org/file15507/fastsearch_rfind.patch

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

From report at bugs.python.org  Wed Dec  9 01:24:46 2009
From: report at bugs.python.org (flox)
Date: Wed, 09 Dec 2009 00:24:46 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1260318286.35.0.0504846477288.issue7462@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15505/fastsearch_rfind.patch

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

From report at bugs.python.org  Wed Dec  9 02:16:12 2009
From: report at bugs.python.org (Denis)
Date: Wed, 09 Dec 2009 01:16:12 +0000
Subject: [issue7114] HTMLParser doesn't handle <![CDATA[ ... ]]>
In-Reply-To: <1255383173.02.0.819385756545.issue7114@psf.upfronthosting.co.za>
Message-ID: <1260321372.85.0.899100879884.issue7114@psf.upfronthosting.co.za>


Denis <python at sokolov.cc> added the comment:

The CDATA sections are part of XML specification.
http://www.w3.org/TR/REC-xml/#sec-cdata-sect

HTML is not XML, so HTMLParser does the right thing here.

----------
nosy: +Denis

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

From report at bugs.python.org  Wed Dec  9 10:11:07 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 09 Dec 2009 09:11:07 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260349867.14.0.510989285608.issue7452@psf.upfronthosting.co.za>


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

I agree that adding the definitions of HAVE_GCC_ASM_FOR_X87 to 
pymacconfig.h solves the problem.

[mini-rant on]
This problem is another illustration of how easy it is to inadvertently 
introduce significant bugs in the OS X multi-architecture support, bugs 
which can currently go undetected without a lot of diligence on 
everyone's part.  We were lucky on this one.  Thanks, Sridhar.
[mini-rant off]

After digging around a lot, I see now why I hadn't noticed it before.  Always specifying --enable-universalsdk=/Path/To/sdk and default arch 
options (as the current installer builds do) causes configure to include 
-arch ppc and -arch i386 in CFLAGS and these get added to the gcc call 
in autoconf tests AC_TRY_COMPILE and AC_TRY_RUN.  That meant the 
autoconf test for HAVE_GCC_ASM_FOR_X87 was *always* NO because the PPC 
arch compile always failed on the Intel assembler code test.  And the 
compile failure is not obvious unless you examine configure.log in 
detail and notice that the result of the test was NO because of the 
multiple architectures.

If configure is called with just --enable-universalsdk (no path) but on 
10.5 or 10.6, the multiple archs still get added to CFLAGS, the test 
returns NO again, and the problem is still masked:

CFLAGS='-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
g -O2'

But if you make that same configure call on 10.4, the multiple archs are 
not added:

CFLAGS='-g -O2'

On a 10.4 PPC system (my case) the test *still* returns NO so the 
problem is *still* masked.  It's only if you run the build with that 
configure on a 10.4 i386 system that the test will pass, causing HAVE_GCC_ASM_FOR_X87 to finally be defined.  Then, during the make of 
the multi-architecture build, the root problem will finally be exposed, 
as it was here.

That also means that, for multi-arch builds on OS X, the X87 control 
word code would never be used in the python.org installers or any other 
intel/ppc multi-architecture build.

I hope that is a reasonably close to correct analysis but I could have a 
few details wrong. It's clearly easy to get wrong.

Looking elsewhere in configure.in, there are other architecture-specific 
run-time tests that could give incorrect results in a multi-arch 
environment.  The math tests immediately following appear to take a 
conservative approach so I'm guessing that, if there were conflicting 
results during the multiple arch compiles and runs, the code would work 
correctly though possibly sub-optimally.  I didn't see any other obvious 
incorrect results although it is difficult to tell when so many 
configure tests get compile or build errors by design.

There seem to be at least two issues brought out here:

1. How to make core developers and patch contributors more aware of the 
special requirements of multi-architecture builds?

2. What, if any, additions or changes to tests and testing process 
should be made to help catch problems like this (and others that might 
be lurking)?

At a minimum, I would like to see a message added to configure.in that 
is output on OS X to warn that some of the autoconf derived values for 
architecture-specific SIZEOF and processor features are overridden in 
Include/pyconfig.h.  Currently there doesn't seem to be any reference to 
this in configure.in and it so easy to be misled by the autoconf 
results.  Adding comments to the source of the overridden tests would be 
great but a bit of work.  Conditionally skipping the tests would be even 
better, if it could be made to work.  A more systematic test process 
would also help.

----------

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

From report at bugs.python.org  Wed Dec  9 11:01:52 2009
From: report at bugs.python.org (Murray Cumming)
Date: Wed, 09 Dec 2009 10:01:52 +0000
Subject: [issue7463] PyDateTime_IMPORT() causes compiler warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>


New submission from Murray Cumming <murrayc at murrayc.com>:

At least in Python 2.5 and 2.6 (I haven't checked newer versions), the 
PyDateTime_IMPORT() macro passes string literals to a function that
takes non-const char* parameters:

#define PyDateTime_IMPORT \
        PyDateTimeAPI = (PyDateTime_CAPI*) PyCObject_Import("datetime", \
                                                            "datetime_CAPI")

This makes it impossible to build code with warnings as errors, when
using that macro.

----------
components: None
messages: 96166
nosy: murrayc
severity: normal
status: open
title: PyDateTime_IMPORT() causes compiler warnings
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Wed Dec  9 12:29:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Dec 2009 11:29:13 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260358153.2.0.620945675657.issue7459@psf.upfronthosting.co.za>


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

I think the point is more of self-documentation not being deceiving.
Here someone tries to use import.c 's embedded documentation about
existing magic numbers and he/she gets mystified because the actual
magic number doesn't seem to correspond.

Also, it's true that the "Unicode mode fixup" is obsolete and should be
removed anyway.

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Dec  9 12:30:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Dec 2009 11:30:02 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260358202.94.0.676613728403.issue7459@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Wed Dec  9 14:42:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Dec 2009 13:42:02 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260366122.37.0.719360221995.issue7452@psf.upfronthosting.co.za>


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

A reply to Ned from the person who introduced this bug in the first
place (sorry, folks):

[Ned]
> 1. How to make core developers and patch contributors more aware of the 
> special requirements of multi-architecture builds?

I guess I was already aware of this, at least after Ned (IIRC), some
months ago, detected essentially the same problem in py3k after we'd put
the short float repr in.  So this was really just sloppiness on my part.
 I did testing of the short float repr for single-architecture builds on
OS X 10.4/PPC (32-bit), OS X 10.5/Intel (32-bit and 64-bit) and OS X
10.6/Intel (64-bit only), but still missed this.

Something that I would have found helpful at one stage would be
prominent instructions (somewhere, maybe in the python-dev FAQ?) for
creating and testing multi-architecture builds on various OS X versions.
 Perhaps all those instructions need to do is to point to the
Mac/BuildScript/README.txt?  Even now, I'm still not 100% clear on
exactly which selection of options should be supplied to the configure
scripts, and why.

> At a minimum, I would like to see a message added to configure.in that 
> is output on OS X to warn that some of the autoconf derived values for 
> architecture-specific SIZEOF and processor features are overridden in 
> Include/pyconfig.h.

Do you mean Include/pymacconfig.h?  If so, I agree such a warning would
be good to have.

As an aside, I *think* it's actually safe just to undefine
HAVE_GCC_ASM_FOR_X87 unconditionally on OS X:  the inline assembler that
it enables is only ever used for machines which suffer from double
rounding, which is a symptom of using the x87 FPU for basic arithmetic.
gcc on OS X (either Apple gcc or GNU gcc) always seems to use SSE2
instructions for arithmetic, even for 32-bit builds, so the fnstcw and
fldcw instructions aren't ever needed or used on OS X.

----------

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

From report at bugs.python.org  Wed Dec  9 16:23:24 2009
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Wed, 09 Dec 2009 15:23:24 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260372204.85.0.642875021592.issue7451@psf.upfronthosting.co.za>


Valentin Kuznetsov <vkuznet at gmail.com> added the comment:

I wonder if you can make a patch for 2.6 python branch.

----------

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

From report at bugs.python.org  Wed Dec  9 16:31:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Dec 2009 15:31:44 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260372704.63.0.950919586897.issue5949@psf.upfronthosting.co.za>


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

Applied to trunk in r76276.  However, when I tried to backport it to
2.6, the tests hang in test_connect for the SSL version.  The hang isn't
interruptible by ctl-C.  Perhaps there's some SSL fix that hasn't been
backported, and if so it would be nice to figure out if it can be
backported.  (Note, to backport the tests I removed the 'reap_threads'
context manager calls and replaced it with a reap_children call at the
end of test_main).

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Dec  9 16:58:57 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Dec 2009 15:58:57 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260372204.85.0.642875021592.issue7451@psf.upfronthosting.co.za>
Message-ID: <1260374368.3368.21.camel@localhost>


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

> I wonder if you can make a patch for 2.6 python branch.

No, 2.6 doesn't have the same C accelerator in the first place.

----------

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

From report at bugs.python.org  Wed Dec  9 17:33:39 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Dec 2009 16:33:39 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260376419.11.0.708647675826.issue7459@psf.upfronthosting.co.za>


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


----------
assignee:  -> benjamin.peterson

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

From report at bugs.python.org  Wed Dec  9 17:42:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Dec 2009 16:42:45 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260376965.21.0.183285306176.issue5949@psf.upfronthosting.co.za>


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

Added skipping of the SSL tests if ssl is not available in r76727.

----------

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

From report at bugs.python.org  Wed Dec  9 17:47:02 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 16:47:02 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260377222.15.0.158780473339.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch

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

From report at bugs.python.org  Wed Dec  9 17:58:44 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 09 Dec 2009 16:58:44 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260377924.58.0.897323905508.issue7452@psf.upfronthosting.co.za>


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

Mark, I wasn't ranting at you or Ronald or anyone in particular.  It's no 
secret that Python's build system is complex and fragile in some areas.  
On the other hand, the build system is ambitious, covering a wide variety 
of platforms and variants, and is largely successful.  In particular, 
supporting multi-architecture builds across multiple OS levels for OS X 
is, IMO, a Good Thing to be doing. But there is a cost for all that.  It 
would be good to be able to scrape away some of the overall cruft that's 
accumulated over the many years.  Hmm, a GSOC project to implement SCons 
builds for the current platforms and to facilitate cross-platform builds?  
Anyway, I did indeed mean Include/pymacconfig.h.

----------

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

From report at bugs.python.org  Wed Dec  9 18:04:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Dec 2009 17:04:49 +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: <1260378289.43.0.0313534847572.issue7316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
stage:  -> patch review

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

From report at bugs.python.org  Wed Dec  9 18:05:56 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 17:05:56 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260378356.69.0.174587047587.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch

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

From report at bugs.python.org  Wed Dec  9 18:06:02 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 17:06:02 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260378362.76.0.529189471817.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch

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

From report at bugs.python.org  Wed Dec  9 18:26:51 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 17:26:51 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260379611.27.0.258957295931.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I have attached a proper backport for the 2.6 maintenance branch. There
were some features (not bugfixes) of the trunk that the tests depended
on, which are not backported.

However, the tests still hang, because there are changes to
SocketServer.py that were not backported to 2.6. The changes are needed
to properly call close() on the underlying socket of the SecureTCPServer
and thus trigger the EOF. To avoid the backporting of bits in
SocketServer, I hacked the necessary bits into this version of the tests.

----------
Added file: http://bugs.python.org/file15510/test_imaplib_issue5949-py26.patch

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

From report at bugs.python.org  Wed Dec  9 18:26:58 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 17:26:58 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260379618.78.0.860644740406.issue5949@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch

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

From report at bugs.python.org  Wed Dec  9 18:27:13 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 09 Dec 2009 17:27:13 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

in urllib2, you will find these lines:
        # Wrap the HTTPResponse object in socket's file object adapter
        # for Windows.  That adapter calls recv(), so delegate recv()
        # to read().  This weird wrapping allows the returned object to
        # have readline() and readlines() methods.

        # XXX It might be better to extract the read buffering code
        # out of socket._fileobject() and into a base class.

        r.recv = r.read
        fp = socket._fileobject(r, close=True)

This, storing a bound method in the instance, will cause a reference 
cycle that the user knows nothing about.

I propose creating a wrapper instance with a recv() method instead.  Or, 
is there a standard way of storing bound methods on instances?  A 
'weakmethod', perhaps?

----------
components: Library (Lib)
messages: 96175
nosy: krisvale
severity: normal
stage: needs patch
status: open
title: circular reference in HTTPResponse by urllib2
type: resource usage
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Dec  9 19:08:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Dec 2009 18:08:02 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260382082.17.0.387729632032.issue5949@psf.upfronthosting.co.za>


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

Do you know which patches?  It's possible they just haven't been
evaluated for backport yet, and if that's so I'll see if I can take care
of it.

----------

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

From report at bugs.python.org  Wed Dec  9 19:24:47 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 18:24:47 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260383087.02.0.785429385754.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I tracked the necessary change to r73638 and issue6267. However, I am
not sure it is in scope to backport all of that.

The only changed actually needed from this set to make SocketServer
behave correctly with a SSLSocket is:

     def close_request(self, request):
         """Called to clean up an individual request."""
+        #explicitly shutdown.  socket.close() merely releases
+        #the socket and waits for GC to perform the actual close.
+        request.shutdown(socket.SHUT_WR)
         request.close()

Hence in my py26 patch, I have made a call to shutdown() within the
handler. I would call this a bug, but nobody seems to have noticed but
me, so I defer to you about the best solution.

----------

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

From report at bugs.python.org  Wed Dec  9 19:34:47 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 18:34:47 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260383687.36.0.983277956583.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I've revised my opinion. If you extract out only the changes to
SocketServer and ignore the others, then I would consider it a good
backport (fixes bugs only). I have attached such a patch.

BTW, with this patch, you can remove the shutdown() call in the
test_imaplib patch.

----------
Added file: http://bugs.python.org/file15511/socketserver_issue_6267.patch

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

From report at bugs.python.org  Wed Dec  9 19:49:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Dec 2009 18:49:46 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260384586.37.0.205038555186.issue5949@psf.upfronthosting.co.za>


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

I'll take a look at the socketserver issue, but probably not today.

In the meantime, can you take a look at this port of the tests to py3k
when you get a chance?  The tests pass without changes to imaplib, but
the imaplib code is a bit different in py3k.  I'd like your opinion on
whether the fact that _get_line unconditionally chomps the last two
bytes is a bug waiting to happen in some other context, even though it
doesn't happen in this particular one in py3k.

----------
Added file: http://bugs.python.org/file15512/test_imaplib_issue5949_py3k.patch

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

From report at bugs.python.org  Wed Dec  9 20:49:13 2009
From: report at bugs.python.org (Scott Dial)
Date: Wed, 09 Dec 2009 19:49:13 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260388153.68.0.204484005046.issue5949@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

It seems that on the py3k branch, the EOF situation is handled roughly
in the same manner (the broken line is returned) and ultimately the
IMAP4.abort exception is raised because b'* ' is an invalid response
(the 'OK' having been dropped). IOW, it passes the EOF test only because
trimming broke the welcome message format. If it got an EOF in the
middle of a more complicated response, it would go undetected or cause a
broken response.

I propose adding the following test case:

    @reap_threads
    def test_line_termination(self):

        class BadNewlineHandler(SimpleIMAPHandler):

            def cmd_CAPABILITY(self, tag, args):
                self._send(b'* CAPABILITY IMAP4rev1 AUTH\n')
                self._send('{} OK CAPABILITY
completed\r\n'.format(tag).encode('ASCII'))

        with self.reaped_server(BadNewlineHandler) as server:
            self.assertRaises(imaplib.IMAP4.abort,
                              self.imap_class, *server.server_address)

Which silently misreads the CAPABILITY response as including "AUT" and
not "AUTH". It would be a perversely broken server, but I think this
test case demonstrates why an explicit check and exception should be
thrown always.

----------

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

From report at bugs.python.org  Wed Dec  9 22:29:08 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Dec 2009 21:29:08 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1260394148.34.0.307553861083.issue6911@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/issue6911>
_______________________________________

From report at bugs.python.org  Wed Dec  9 22:31:03 2009
From: report at bugs.python.org (flox)
Date: Wed, 09 Dec 2009 21:31:03 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260394263.84.0.586314960832.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch for the documentation. (source: upstream documentation)

----------
Added file: http://bugs.python.org/file15513/issue6472_upstream_docs.diff

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

From report at bugs.python.org  Wed Dec  9 22:38:15 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Dec 2009 21:38:15 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260394695.94.0.905241292654.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: the best way to ensure universal builds don't get broken is through 
the buildbots. AFAIK there are no buildbots that create universal 
binaries at the moment. Sadly enough I don't have the resources to 
provide one.

Mark: Mac/README explains how to build universal binaries and 
Mac/BuildScript/build-installer.py is used to build the default binary 
installer. 

To build a universal binary framework:


../configure \
    --enable-framework   \      # Creates a framework
    --enable-universalsdk      # Create universal binary using 10.4 SDK
make
make install

The build can be tweaked using a number of options:

* Use an alternate SDK:
   --enable-universalsdk=PATH

  (I tend to use --enable-universalsdk=/ for my private builds,
   the 10.4u SDK is used in the default installers to ensure that
   users on 10.4 PPC can build universal extensions)

* Select architectures to include in the build:   
   --with-universal-archs=VALUE

* Pick an alternate framework name:
    --with-framework-name=NAME

* Pick a different deployment target:

    MACOSX_DEPLOYMENT_TARGET=X.Y

  (Default is 10.3 for 32-bit builds and 10.5 for builds that include
   a 64-bit architecture).

BTW. I agree that the current configure script sucks, it is very hard
to tweak it beyond adding simple feature tests. IIRC it has taken me
several Python releases to reliably run the feature detection tests 
because some compiler flags didn't get exported correctly to the bits
of the configure script that runs the feature tests.

One way to improve on the script is to create a number of clearly 
labeled sections, such as: compiler/platform setup,  architecture tests
(SIZEOF_* detection, X86_FPU tests, ...), platform feature tests. 

The architecture tests could then be prepended with a comment block
that explains how to deal with them for universal builds on OSX.

----------

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

From report at bugs.python.org  Wed Dec  9 22:39:35 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Dec 2009 21:39:35 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260394775.82.0.943318427723.issue7452@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. Am I correct when I state that this issue has been fixed and can be 
closed?

----------

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

From report at bugs.python.org  Wed Dec  9 22:46:54 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Dec 2009 21:46:54 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1260395214.13.0.653172189668.issue6834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

FWIW: I now have a 2.7 tree with the new pythonw on my machine, open 
issues are:

* Ensure IDLE.app gets build in such a way that the GUI works for
  all supported universal binaries (including a 4-way build on 10.5, 
  where the system Tk doesn't work in 64-bit mode)

* Update NEWS file

* Port to 3.2

----------

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

From report at bugs.python.org  Wed Dec  9 22:49:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Dec 2009 21:49:19 +0000
Subject: [issue7154] urllib.request system proxy configuration lookup broken
	for OS X in Python 3
In-Reply-To: <1255733208.5.0.407244004895.issue7154@psf.upfronthosting.co.za>
Message-ID: <1260395359.8.0.670986237846.issue7154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree that _scproxy should be ported to the 3.x trees. Such a port 
should be fairly straightforward, but is harder than just copying files 
over due to the str/unicode changes in the 3.x tree.

----------

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

From report at bugs.python.org  Wed Dec  9 22:49:42 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Dec 2009 21:49:42 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1260395382.85.0.561091197796.issue6692@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/issue6692>
_______________________________________

From report at bugs.python.org  Wed Dec  9 22:51:08 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 09 Dec 2009 21:51:08 +0000
Subject: [issue1123727] gensuitemodule.processfile fails
Message-ID: <1260395468.49.0.94550980289.issue1123727@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
priority: normal -> low

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

From report at bugs.python.org  Thu Dec 10 02:13:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 01:13:58 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260407638.74.0.235069335703.issue5949@psf.upfronthosting.co.za>


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

Unfortunately, the SocketServer patches introduced other issues (see for
example issue 6381).  So I'm reluctant to backport those changes, since
as you say no one had reported problems.  It seems like the chance of
inadvertently breaking someone's working 2.6 code is too high given the
absence of any actual bug report that we'd be fixing.

So I'm inclined to go with your revised test for the 2.6 backport of
this bugfix.

----------

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

From report at bugs.python.org  Thu Dec 10 03:09:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 02:09:12 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260410952.0.0.107995721424.issue5949@psf.upfronthosting.co.za>


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

Committed to py3k in r76730 with the suggested additional test.

----------

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

From report at bugs.python.org  Thu Dec 10 03:18:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Dec 2009 02:18:15 +0000
Subject: [issue7459] Magic word incorrect in Python 3
In-Reply-To: <1260290620.85.0.183191555328.issue7459@psf.upfronthosting.co.za>
Message-ID: <1260411495.51.0.598846926672.issue7459@psf.upfronthosting.co.za>


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

Fixed in r76731. Thanks.

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

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

From report at bugs.python.org  Thu Dec 10 03:20:56 2009
From: report at bugs.python.org (Aaron Altman)
Date: Thu, 10 Dec 2009 02:20:56 +0000
Subject: [issue7465] Call to another class's constructor in
	unittest.TestCase.setUp returns the same instance
In-Reply-To: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
Message-ID: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>


New submission from Aaron Altman <aaron at tomorrowsfunction.com>:

Not sure if this is intended behavior.  I have a baseClass I'm writing
tests for.  My test architecture has an instance of this baseClass
assigned as a member of TestBaseClass(unittest.TestCase) in
TestBaseClass.setUp.

The problem occurs when tests in TestBaseClass modify state within the
member baseClass instance.  I think there should be a fresh new instance
of baseClass for every test that gets run, but the old state from the
last test is still there.

Example code and output from Python 2.6.2 attached.

----------
components: Library (Lib), Tests
files: unittest_doesnt_reinstantiate_members.txt
messages: 96189
nosy: awaltman
severity: normal
status: open
title: Call to another class's constructor in unittest.TestCase.setUp returns the same instance
versions: Python 2.6
Added file: http://bugs.python.org/file15514/unittest_doesnt_reinstantiate_members.txt

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

From report at bugs.python.org  Thu Dec 10 03:21:10 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 10 Dec 2009 02:21:10 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

'''
    This brute [possibly a] solution to

    http://projecteuler.net/index.php?section=problems&id=159

    causes segmentation fault.


    $ p3 # an AMD 64 bit build.
    Python 3.1.1 (r311:74480, Oct  2 2009, 12:29:57) 
    [GCC 4.3.3] on linux2
    Type "help", "copyright", "credits" or "license" for more 
information.
    >>>


    The block between "load_primes" and "print(result)" can be written
    as a single statement using various comprehensions.  sum(max(...))
    The program does not seg-fault this way, but the result was wrong.
    I unrolled the code to fix my algorithm, disclosing the segmentation 
fault.
'''

import functools
import operator
import itertools
import array

PrimeQ = Primes = 'use load_primes(n) function'

def load_primes(n):
    global PrimeQ,Primes
    PrimeQ = sieve(1+n)
    Primes = array.array('L',(i for (i,Q,) in enumerate(PrimeQ) if Q))

def sieve(n):
    a = array.array('b',(True,))*n
    a[0] = a[1] = False
    for (i,j) in enumerate(a):
        if j:
            for k in range(i**2,n,i):
                a[k] = False
    return a

def PrimeRange(a):
    '''
        see "load_primes"
    '''
    n = 1+int(a**(1/2))
    for p in Primes:
        if n < p:
            raise StopIteration
        yield p

def PrimeFactor(a):
    '''
        see "load_primes"

        >>> load_primes(30)
        >>> print([PrimeFactor(x)for x in (6,7,)])
        [[2, 3], [7]]
    '''
    if (a < len(PrimeQ)) and PrimeQ[a]:
        return [a]
    for p in PrimeRange(a):
        (q,r,) = divmod(a,p)
        if not r:
            return [p]+PrimeFactor(q)
    return [a]

def product(a):
    return functools.reduce(operator.mul,a,1)

def digital_root(n):
    while 9 < n:
        n = sum(map(int,str(n)))
    return n

def partition(L, chain=itertools.chain):
    '''
        python recipe by Ray Hettinger
    '''
    s = L
    n = len(s)
    first, middle, last = [0], range(1, n), [n]
    return [[L[a:b] for (a,b) in zip(chain(first, div), chain(div, 
last))]
            for i in range(n) for div in itertools.combinations(middle, 
i)]





load_primes(1000)

s = 0
for n in range(2,10**6):
    factorizations = [
        [product(p)for p in group]for group in 
partition(PrimeFactor(n))]
    mx = 0
    for factorization in factorizations:
        digital_roots = tuple(map(digital_root,factorization))
        sdr = sum(digital_roots)
        mx = max(mx,sdr)
    s += mx

print('result!',s)

----------
messages: 96190
nosy: LambertDW
severity: normal
status: open
title: Segmentation fault after about 20 seconds on lenovo T500
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec 10 03:21:34 2009
From: report at bugs.python.org (Aaron Altman)
Date: Thu, 10 Dec 2009 02:21:34 +0000
Subject: [issue7465] Call to another class's constructor in
	unittest.TestCase.setUp returns the same instance multiple times
In-Reply-To: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
Message-ID: <1260411694.67.0.856785361851.issue7465@psf.upfronthosting.co.za>


Changes by Aaron Altman <aaron at tomorrowsfunction.com>:


----------
title: Call to another class's constructor in unittest.TestCase.setUp returns the same instance -> Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times

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

From report at bugs.python.org  Thu Dec 10 03:40:59 2009
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 10 Dec 2009 02:40:59 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260412859.57.0.915574583917.issue7466@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

Further isolation, following change removes segmentation fault: 

        digital_roots = tuple(map(digital_root,factorization))

becomes

        digital_roots = [digital_root(factor) for factor in 
factorization]

----------

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

From report at bugs.python.org  Thu Dec 10 03:42:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 02:42:23 +0000
Subject: [issue7465] Call to another class's constructor in
	unittest.TestCase.setUp returns the same instance multiple times
In-Reply-To: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
Message-ID: <1260412943.67.0.945231731215.issue7465@psf.upfronthosting.co.za>


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

Yes, this working as intended.  Consider:

Python 2.7a1+ (trunk:76725, Dec  9 2009, 09:26:36)
[GCC 4.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class baseClass(object):
...     def __init__(self, testList=[]):
...         self.testList = testList
...     def insertItem(self):
...         self.testList.append("testing from baseClass")
...
>>> a = baseClass()
>>> b = baseClass()
>>> del b
>>> a.insertItem()
>>> print a.testList
['testing from baseClass']
>>> b = baseClass()
>>> print b.testList
['testing from baseClass']


See
http://docs.python.org/faq/design.html#why-are-default-values-shared-between-objects
for an explanation of why.

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

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

From report at bugs.python.org  Thu Dec 10 03:46:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 02:46:32 +0000
Subject: [issue7465] Call to another class's constructor in
	unittest.TestCase.setUp returns the same instance multiple times
In-Reply-To: <1260411656.89.0.306552268984.issue7465@psf.upfronthosting.co.za>
Message-ID: <1260413192.04.0.482055070405.issue7465@psf.upfronthosting.co.za>


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

Heh, that first b = baseClass(); del b wasn't supposed to be there and
doesn't change the result, just in case you were wondering.

----------

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

From report at bugs.python.org  Thu Dec 10 04:10:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 03:10:19 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1260414619.81.0.778420295589.issue6692@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> josiahcarlson
nosy: +josiahcarlson
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Thu Dec 10 07:59:31 2009
From: report at bugs.python.org (Douglas Turk)
Date: Thu, 10 Dec 2009 06:59:31 +0000
Subject: [issue7467] The zipfile module does not check files' CRCs,
	including in ZipFile.testzip
In-Reply-To: <1260428371.84.0.68619284631.issue7467@psf.upfronthosting.co.za>
Message-ID: <1260428371.84.0.68619284631.issue7467@psf.upfronthosting.co.za>


New submission from Douglas Turk <douglas.turk at depthanalysis.com>:

The zipfile module does not calculate the CRC of files in a zipfile as
they are read as of Python 2.6. The old ZipFile.read function in Python
2.5 used to do this, and ZipFile.testzip appears to rely on ZipFile.read
to check the CRC. This means that ZipFile.testzip does not check the CRC
as it is documented to.

It would be useful if ZipExtFile could check the CRC once it had read
all the data, because this would mean that e.g. ZipFile.extract would
also automatically check the CRC. Perhaps ZipExtFile.read could raise a
BadZipFile exception if it reaches EOF and the CRC is wrong.

Steps to reproduce:
-Create a zip file, then change a byte in a file's contents (easiest if
files are stored, not deflated).
-Run ZipFile.testzip on the edited file. Note that it does not report a
CRC failure, but other zip tools do.

I can provide a patch in a couple of days if that's useful.

----------
components: Library (Lib)
files: test.zip
messages: 96194
nosy: dougturk
severity: normal
status: open
title: The zipfile module does not check files' CRCs, including in ZipFile.testzip
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15515/test.zip

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

From report at bugs.python.org  Thu Dec 10 09:23:53 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 10 Dec 2009 08:23:53 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1260433433.63.0.581204840811.issue6692@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I have a patch for adding epoll() support which is almost ready
(asyncore supports poll(), not epoll()), it's just a matter of writing
tests. 

kqueue() shouldn't be too difficult to implement considering that we can
take Twisted as example.

...But aside from the implementation details I'd say there's a crucial
problem with the current API:

asyncore.loop([timeout[, use_poll[, map[, count]]]])

The "use_poll" argument should be deprecated in favor of something else,
maybe a "poller" which accepts a callable, like this:


>>> asyncore.loop(poller=asyncore.select_poller)
>>> asyncore.loop(poller=asyncore.epoll_poller)
>>> asyncore.loop(poller=asyncore.kqueue_poller)

----------

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

From report at bugs.python.org  Thu Dec 10 10:18:23 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 10 Dec 2009 09:18:23 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1260436703.7.0.707189290938.issue1706039@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I've attached a patch that applies cleanly against py3k.

I do not have an in-depth understanding of the new io module, but at a
cursory glance, it seems to not use FILE streams, and would not be
subject to this bug. However, Py_UniversalNewlineFgets() still remains,
and I have patched it accordingly. Additionally, I have added the test
to test_fileio.

py3k doesn't fail any of these tests for me, but the original issue was
only exposed on OS X.

----------
Added file: http://bugs.python.org/file15516/issue1706039-py3k.patch

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

From report at bugs.python.org  Thu Dec 10 10:21:48 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 10 Dec 2009 09:21:48 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1260436908.65.0.0180107565757.issue1706039@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Added file: http://bugs.python.org/file15517/issue1706039-py3k.patch

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

From report at bugs.python.org  Thu Dec 10 10:21:52 2009
From: report at bugs.python.org (Scott Dial)
Date: Thu, 10 Dec 2009 09:21:52 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1260436912.92.0.927416077378.issue1706039@psf.upfronthosting.co.za>


Changes by Scott Dial <scott at scottdial.com>:


Removed file: http://bugs.python.org/file15516/issue1706039-py3k.patch

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

From report at bugs.python.org  Thu Dec 10 11:02:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Dec 2009 10:02:27 +0000
Subject: [issue3363] python version incorrectly reported in crash reports on
	Mac OS X 10.4.11 PPC
In-Reply-To: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>
Message-ID: <1260439347.11.0.388947446322.issue3363@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

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

From report at bugs.python.org  Thu Dec 10 12:17:20 2009
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Dec 2009 11:17:20 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260443840.0.0.522662479396.issue7466@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Segfault confirmed on 64 bit Ubuntu, Python 3.2a0:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5074dea6e0 (LWP 11665)]
0x000000000042111b in _PyTuple_Resize (pv=0x7fff7ce03b10, newsize=25) at
Objects/tupleobject.c:853
853             _PyObject_GC_UNTRACK(v);

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Dec 10 12:22:50 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Dec 2009 11:22:50 +0000
Subject: [issue7468] PyErr_Format documentation doesn't mention all format
	codes
In-Reply-To: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za>
Message-ID: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I haven't checked the 3.1, 2.7 and 2.6 documentation, but at least for 3.2 
the documentation of PyErr_Format lists a very small number of supported 
format characters compared to PyUnicode_FromFormat even though 
PyErr_Format calls PyUnicode_FromFormatV to do the actual formatting.

----------
assignee: georg.brandl
components: Documentation
messages: 96198
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: PyErr_Format documentation doesn't mention all format codes
versions: Python 3.2

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

From report at bugs.python.org  Thu Dec 10 12:28:04 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 11:28:04 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260444484.4.0.644139381319.issue7466@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Yes, confirmed too. Both 3.1 and 3.2 are broken.

Minimal sequence to trigger the bug:

"""
~ $ ./python 
Python 3.2a0 (py3k:76743M, Dec 10 2009, 12:19:41) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

"""
def m(i):
    if i == 10:
        return next(i for i in '0')

MAX_LOOP = 1<<10
t = range(11)
for i in range(MAX_LOOP):
  d = map(m, t)
  tup = tuple(d)

## python: Objects/tupleobject.c:853: _PyTuple_Resize:
## Assertion `g->gc.gc_refs != (-2)' failed.

----------
components: +Interpreter Core
nosy: +flox
versions: +Python 3.2

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

From report at bugs.python.org  Thu Dec 10 12:55:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 11:55:44 +0000
Subject: [issue7469] Design and History FAQ entry on Floating Point does not
	mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

See
http://docs.python.org/dev/faq/design.html#why-are-floating-point-calculations-so-inaccurate.
 The 3.1 version is the same, so it also needs to be updated.  The entry
links to the tutorial, which has the correct information for 3.1/3.2,
but not for trunk.

----------
keywords: easy
messages: 96200
nosy: eric.smith, mark.dickinson, r.david.murray, rhettinger
priority: low
severity: normal
stage: needs patch
status: open
title: Design and History FAQ entry on Floating Point does not mention short repr.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Dec 10 14:14:36 2009
From: report at bugs.python.org (Christian Boos)
Date: Thu, 10 Dec 2009 13:14:36 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>


New submission from Christian Boos <cboos at neuf.fr>:

For a stream with a "poor" encoding, such as sys.stderr on Windows where 
encoding is cp437, the encoding of an unicode message will fail 
(expected) and then a fallback encoding to UTF-8 will be done:

(in 
http://code.python.org/hg/trunk/file/bd98b2c097fe/Lib/logging/__init__.p
y#l837):
837                 except UnicodeError:
838                     stream.write(fs % msg.encode("UTF-8"))

However, that fallback won't work, as at this point, fs was already 
converted to unicode and is now u'%s\n', so the (msg.encode("UTF-8")) 
str will be decoded to unicode again using the default encoding, which 
will likely fail with a UnicodeDecodeError if msg contains non-ascii 
characters.

The solution would be to keep using fs as "%s\n" in this line.

This is similar to issue6991, but not exactly the same and it only 
happens for Python 2.7. Using logging_error.py, I've tested Python 2.3 
to Python 2.6 (works) and Python 2.7a1 (fails), current trunk must have 
the same issue as 2.7a1. Patch follows.

----------
components: Library (Lib)
files: logging_error.py
messages: 96201
nosy: cboos, vinay.sajip
severity: normal
status: open
title: logger.StreamHandler emit encoding fallback is wrong
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15518/logging_error.py

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

From report at bugs.python.org  Thu Dec 10 14:18:59 2009
From: report at bugs.python.org (Christian Boos)
Date: Thu, 10 Dec 2009 13:18:59 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260451139.62.0.638271874136.issue7470@psf.upfronthosting.co.za>


Christian Boos <cboos at neuf.fr> added the comment:

One way to solve the issue. 

PS: copy/pasting URLs to the Mercurial repo apparently doesn't work, for 
some reason (probably the line anchor); the URL I gave above was:

 http://code.python.org/hg/trunk/file/bd98b2c097fe/Lib/logging/__init__.py

 + #l837

----------
keywords: +patch
Added file: http://bugs.python.org/file15519/issue7470.patch

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

From report at bugs.python.org  Thu Dec 10 14:21:52 2009
From: report at bugs.python.org (Christian Boos)
Date: Thu, 10 Dec 2009 13:21:52 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260451312.36.0.562250615767.issue7470@psf.upfronthosting.co.za>


Christian Boos <cboos at neuf.fr> added the comment:

PPS: Ok, links to the Mercurial repo /really/ don't work, and it was not 
the #l837 part ;-)

----------

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

From report at bugs.python.org  Thu Dec 10 17:11:25 2009
From: report at bugs.python.org (asnakelover)
Date: Thu, 10 Dec 2009 16:11:25 +0000
Subject: [issue7471] gzip module too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>


New submission from asnakelover <a3277638 at uggsrock.com>:

It's not a big problem because we can just shell to zcat but compare
these two:

$ time python ./b.py >/dev/null

real    0m10.977s
user    0m7.128s
sys     0m0.888s
$ time python ./a.py >/dev/null

real    1m19.015s
user    1m18.185s
sys     0m0.072s

$ # Notice that the gzip module (a.py) had the benefit of the files
being in a disk cache by too now...

$ cat a.py 
import gzip
import os

apt_cache_dir = "/var/cache/apt/apt-file"

for apt_cache_file in os.listdir(apt_cache_dir):
    if not apt_cache_file.endswith(".gz"):
        continue
    f = gzip.open(os.path.join(apt_cache_dir, apt_cache_file))
    for line in f:
        print line

$ cat b.py 
import os
import subprocess
from cStringIO import StringIO

apt_cache_dir = "/var/cache/apt/apt-file"

for apt_cache_file in os.listdir(apt_cache_dir):
    if not apt_cache_file.endswith(".gz"):
        continue
    p = subprocess.Popen(["zcat", os.path.join(apt_cache_dir,
apt_cache_file)],
        stdout = subprocess.PIPE)
    f = StringIO(p.communicate()[0])
    assert p.returncode == 0 
    for line in f:
        print line

Also tried this one just for "completeness":

$ cat c.py 
import gzip
import os
from cStringIO import StringIO

apt_cache_dir = "/var/cache/apt/apt-file"

for apt_cache_file in os.listdir(apt_cache_dir):
    if not apt_cache_file.endswith(".gz"):
        continue
    f = gzip.open(os.path.join(apt_cache_dir, apt_cache_file))
    f = StringIO(f.read())
    for line in f:
        print line

But after it had ran (with some thrashing) for 3 and a half minutes I
killed it.

----------
components: Library (Lib)
messages: 96204
nosy: asnakelover
severity: normal
status: open
title: gzip module too slow
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec 10 17:13:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 16:13:47 +0000
Subject: [issue7471] gzip module too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260461627.23.0.815065409729.issue7471@psf.upfronthosting.co.za>


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

How does the following compare?

f = gzip.open(...)
s = f.read()
for line in s.splitlines():
    print line

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Dec 10 17:15:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 16:15:50 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260461750.75.0.749643599251.issue7471@psf.upfronthosting.co.za>


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

(GZipFile.readline() is implemented in pure Python, which explains why
it's rather slow)

----------
priority:  -> normal
title: gzip module too slow -> GZipFile.readline too slow

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

From report at bugs.python.org  Thu Dec 10 17:22:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 16:22:47 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260462167.36.0.555912505887.issue7466@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
priority:  -> high
stage:  -> needs patch

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

From report at bugs.python.org  Thu Dec 10 17:32:33 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 16:32:33 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260462753.18.0.516096852836.issue7466@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Fix is coming soon...

## Sample code:

import gc
tuple(gc.collect() for i in range(11))

## python: Objects/tupleobject.c:853: _PyTuple_Resize:
## Assertion `g->gc.gc_refs != (-2)' failed.


And Trunk is affected

----------
versions: +Python 2.7

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

From report at bugs.python.org  Thu Dec 10 17:35:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 16:35:12 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260462912.74.0.0517668127935.issue7466@psf.upfronthosting.co.za>


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

An even simpler way to reproduce:

>>> import gc
>>> def g(it):
...   for x in it:
...     gc.collect()
...     yield x
... 
>>> t = tuple(g(range(100)))
Erreur de segmentation


This is probably caused by the GC optimizations I introduced in trunk
and 3.1.

----------
assignee:  -> pitrou

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

From report at bugs.python.org  Thu Dec 10 17:35:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 16:35:36 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260462936.6.0.105240348005.issue7466@psf.upfronthosting.co.za>


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

Ok, you've been faster than me, flox :-)

----------

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

From report at bugs.python.org  Thu Dec 10 18:17:53 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 17:17:53 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260465473.62.0.235976191206.issue7466@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Well... here comes the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file15520/issue7466.diff

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

From report at bugs.python.org  Thu Dec 10 18:38:21 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 17:38:21 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260466701.74.0.462042828345.issue7466@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15520/issue7466.diff

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

From report at bugs.python.org  Thu Dec 10 18:39:00 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 17:39:00 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260466740.54.0.403739055193.issue7466@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15521/issue7466.diff

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

From report at bugs.python.org  Thu Dec 10 18:43:02 2009
From: report at bugs.python.org (Yukihiro Nakadaira)
Date: Thu, 10 Dec 2009 17:43:02 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>


New submission from Yukihiro Nakadaira <yukihiro.nakadaira at gmail.com>:

email.encoders.encode_7or8bit(): typo "iso-2202".  "iso-2022" is correct.

Index: Lib/email/encoders.py
===================================================================
--- Lib/email/encoders.py	(revision 76749)
+++ Lib/email/encoders.py	(working copy)
@@ -62,7 +62,7 @@
         # iso-2022-* is non-ASCII but still 7-bit
         charset = msg.get_charset()
         output_cset = charset and charset.output_charset
-        if output_cset and output_cset.lower().startswith('iso-2202-'):
+        if output_cset and output_cset.lower().startswith('iso-2022-'):
             msg['Content-Transfer-Encoding'] = '7bit'
         else:
             msg['Content-Transfer-Encoding'] = '8bit'

----------
components: Library (Lib)
messages: 96211
nosy: ynkdir
severity: normal
status: open
title: email.encoders.encode_7or8bit(): typo "iso-2202".  "iso-2022" is correct.
type: behavior

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

From report at bugs.python.org  Thu Dec 10 19:21:05 2009
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Thu, 10 Dec 2009 18:21:05 +0000
Subject: [issue1395552] add support for thread function result storage
Message-ID: <1260469265.97.0.987940692853.issue1395552@psf.upfronthosting.co.za>


Michal Bo?o? <michal.bozon at gmail.com> added the comment:

why would we throw the thread function result out of the window?
because there is a another way, to do it? there are always many ways,
how to do it, so why would we want to do it very difficult way?

i think that not having the result stored somewhere is a bug and i'm
voting for fixing it

----------
nosy: +mykhal

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

From report at bugs.python.org  Thu Dec 10 19:43:42 2009
From: report at bugs.python.org (Paul Nelson)
Date: Thu, 10 Dec 2009 18:43:42 +0000
Subject: [issue7473] x84_64 arch Missing from 2.6.4 Mac universal binaries -
	Cripples building embedded 64-bit
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>


New submission from Paul Nelson <Paul.Nelson at jmp.com>:

By excluding the x86_64 architecture from the supplied MacOS install, 
you are crippling the ability to build an 64-bit application that embeds 
python.  The Apple supplied universal binary includes all 3 architectures 
ppc, i386, and x86_64.  If you are going to supply a Mac build you need to 
do the same.  A 64-bit app has to link against 64-bit libraries, so the 
64-bit build IS NECESSARY.  You give no warning that you are excluding 1/3  
of the architectures from your build.  It also forces the unlucky 
downloader to circumvent the install, or rebuild from source.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 96213
nosy: prniii, ronaldoussoren
severity: normal
status: open
title: x84_64 arch Missing from 2.6.4 Mac universal binaries - Cripples building embedded 64-bit
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec 10 19:59:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 18:59:10 +0000
Subject: [issue1395552] add support for thread function result storage
Message-ID: <1260471550.65.0.318265168748.issue1395552@psf.upfronthosting.co.za>


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

I agree with Stephen.  You can implement this functionality easily
through the current API (subclassing), so there's no need to complicate
the existing API to handle this one communication method as a special case.

Furthermore, this particular use case is the tip of a small iceberg
usually called "Futures", which provides a much cleaner API for the use
case.  There has been a suggestion to include such a package in core,
though it will probably be some time before the library is mature enough
for a decision to be made.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec 10 20:24:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Dec 2009 19:24:42 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1260473082.52.0.684127321308.issue7472@psf.upfronthosting.co.za>


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


----------
assignee:  -> barry
nosy: +barry

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

From report at bugs.python.org  Thu Dec 10 21:33:04 2009
From: report at bugs.python.org (Eric)
Date: Thu, 10 Dec 2009 20:33:04 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>


New submission from Eric <etzool at hotmail.com>:

I am attempting to create a multiprocessing.SyncManager subclass
instance, register a test class with it, start the manager, and
instantiate the test class.  The example I'm providing here is basically
equivalent, and illustrates the same problem (example code is at the
bottom of this message).

This works without issue as long as the manager is started in the file
you actually invoke from the command line.  Handled in exactly the same
way, however, with the call to the SyncManager instance's start method
made in an included file, attempting to instantiate anything, including
built-in list() and dict() objects, via the manager causes script to
hang indefinitely.

Output on ctrl+c breaking seems to indicate the call may be hanging in
the challenge process.

Invocation and output (starting/started are wrapped around the start()
call; creating/created are wrapped around the manager's registered
object instantiation):

$ python test.py 
starting...
...started
creating...
^CTraceback (most recent call last):
  File "test.py", line 6, in <module>
    obj = test_manager.TC()
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 634, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 532, in
_create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/usr/lib64/python2.6/multiprocessing/connection.py", line 140,
in Client
    answer_challenge(c, authkey)
  File "/usr/lib64/python2.6/multiprocessing/connection.py", line 372,
in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
KeyboardInterrupt


test.py:

from test_inc import test_manager

print "creating..."
obj = test_manager.dict()
print "...created"

test_inc.py:

from multiprocessing.managers import SyncManager

test_manager = SyncManager()	
print "starting..."
test_manager.start()
print "...started"

Environment: Linux 2.6.28-gentoo-r5 #4 SMP x86_64 Intel(R) Core(TM)2 Duo
CPU T5470 @ 1.60GHz GenuineIntel GNU/Linux

Version: Python 2.6.4

Apologies if this is my failure to understand how the library (or even
Python) works, but it seems quite odd that this would be expected behavior.

----------
components: Extension Modules
messages: 96215
nosy: etzool
severity: normal
status: open
title: multiprocessing.managers.SyncManager managed object creation fails when started outside of invoked file
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec 10 21:33:28 2009
From: report at bugs.python.org (Eric)
Date: Thu, 10 Dec 2009 20:33:28 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1260477208.67.0.964481269948.issue7474@psf.upfronthosting.co.za>


Changes by Eric <etzool at hotmail.com>:


----------
type:  -> crash

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

From report at bugs.python.org  Thu Dec 10 21:50:24 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 10 Dec 2009 20:50:24 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260478224.44.0.56255526087.issue7471@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/issue7471>
_______________________________________

From report at bugs.python.org  Thu Dec 10 22:10:53 2009
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Thu, 10 Dec 2009 21:10:53 +0000
Subject: [issue1395552] add support for thread function result storage
Message-ID: <1260479453.31.0.896239800351.issue1395552@psf.upfronthosting.co.za>


Michal Bo?o? <michal.bozon at gmail.com> added the comment:

i still do not agree, it will always feel somehow incomplete, being able 
to easily "threadize" the function:

>>> t = threading.Thread(target=func)

and then not being able to get the target function result (easily)

----------

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

From report at bugs.python.org  Thu Dec 10 22:11:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2009 21:11:00 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1260479460.87.0.215741114016.issue7474@psf.upfronthosting.co.za>


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


----------
nosy: +jnoller
priority:  -> normal
type: crash -> behavior

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

From report at bugs.python.org  Thu Dec 10 23:27:15 2009
From: report at bugs.python.org (asnakelover)
Date: Thu, 10 Dec 2009 22:27:15 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260484035.55.0.626629150168.issue7471@psf.upfronthosting.co.za>


asnakelover <a3277638 at uggsrock.com> added the comment:

Hope this reply works right, the python bug interface is a bit confusing
for this newbie, it doesn't say "Reply" anywhere - sorry if it goes FUBAR.

I tried the splitlines() version you suggested, it thrashed my machine
so badly I pressed alt+sysrq+f (which invokes kernel oom_kill) after
about 1 minute so I didn't lose anything important. About half a minute
later the machine came back to life. In other words: the splitlines
version used way, way too much memory - far worse even than making a
cStringIO from a GzipFile instance.read().

It's not just a GzipFile.readline() issue either, c.py calls .read() and
tries to turn the result into a cStringIO and that was the worst one of
my three previous tests. I'm going to look at this purely from a
consumer angle and not even look at gzip module source, from this angle
(a consumer), zcat out performs it by a factor of 10 when gzip module is
used with .readline() and by a good deal more when I try to read the
whole gzip file as a string to turn into a cStringIO to emulate as
closely as possible what happens with forking a zcat process. When I
tried to splitlines() it was even worse. This is probably a RAM issue,
but it just brings us back to - should gzip module eat so much ram when
shelling out to zcat uses far less?

----------

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

From report at bugs.python.org  Thu Dec 10 23:27:40 2009
From: report at bugs.python.org (flox)
Date: Thu, 10 Dec 2009 22:27:40 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

AFAIK these codecs were not ported to Python 3.

1. I found no hint in documentation on this matter.

2. Is it possible to contribute some of them, or there's a good reason
to look elsewhere?

----------
components: Library (Lib)
messages: 96218
nosy: flox
severity: normal
status: open
title: codecs missing: base64 bz2 hex zlib ...
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Dec 10 23:38:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 22:38:08 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260484688.25.0.329775811034.issue7471@psf.upfronthosting.co.za>


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

> I tried the splitlines() version you suggested, it thrashed my machine
> so badly I pressed alt+sysrq+f (which invokes kernel oom_kill) after
> about 1 minute so I didn't lose anything important.

This sounds very weird. How much memory do you have, and how large are
the .gz files you are reading? What is your system exactly?

----------

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

From report at bugs.python.org  Thu Dec 10 23:52:04 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 10 Dec 2009 22:52:04 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260485524.38.0.499163422457.issue7475@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/issue7475>
_______________________________________

From report at bugs.python.org  Thu Dec 10 23:54:37 2009
From: report at bugs.python.org (asnakelover)
Date: Thu, 10 Dec 2009 22:54:37 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260485677.82.0.178769470321.issue7471@psf.upfronthosting.co.za>


asnakelover <a3277638 at uggsrock.com> added the comment:

The gz in question is 17mb compressed and 247mb uncompressed. Calling
zcat the python process uses between 250 and 260 mb with the whole
string in memory using zcat as a fork. Numbers for the gzip module
aren't obtainable except for readline(), which doesn't use much memory
but is very slow. Other methods thrash the machine to death.

The machine has 300mb free RAM from a total of 1024mb.

It's not a new issue, I didn't find it when searching python bug
archives for some reason but google:

http://www.google.com/search?q=python+gzip+slow+zcat

It's an issue which people have stumbled into before but nobody seems to
have made headway any headway (I expect they just forked and called zcat
or gzip, like I did...).

It's a minor point since it's so easy to work around, in fact I have my
IDS system completed already - thank you so much python for being so RAD
friendly - yet the module is worthless if a user has zcat/gzip c
programs and knows they exist as it stands.

----------

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

From report at bugs.python.org  Fri Dec 11 00:03:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Dec 2009 23:03:22 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260485677.82.0.178769470321.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260486235.3414.6.camel@localhost>


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

> The gz in question is 17mb compressed and 247mb uncompressed. Calling
> zcat the python process uses between 250 and 260 mb with the whole
> string in memory using zcat as a fork. Numbers for the gzip module
> aren't obtainable except for readline(), which doesn't use much memory
> but is very slow. Other methods thrash the machine to death.
> 
> The machine has 300mb free RAM from a total of 1024mb.

That would be the explanation. Reading the whole file at once and then
doing splitlines() on the result consumes twice the memory, since a list
of lines must be constructed while the original data is still around. If
you had more than 600 MB free RAM the splitlines() solution would
probably be adequate :-)

Doing repeated calls to splitlines() on chunks of limited size (say 1MB)
would probably be fast enough without using too much memory. It would be
a bit less trivial to implement though, and it seems you are ok with the
subprocess solution.

----------

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

From report at bugs.python.org  Fri Dec 11 00:06:11 2009
From: report at bugs.python.org (asnakelover)
Date: Thu, 10 Dec 2009 23:06:11 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260486371.63.0.140692433245.issue7471@psf.upfronthosting.co.za>


asnakelover <a3277638 at uggsrock.com> added the comment:

Yes, subprocess works fine and was the quickest to implement and
probably the fastest to run too.

How can I put this without being an ass? Hell, I'm no good at diplomacy
- the gzip module blows chunks - if I can shell out to a standard unix
util and it uses a tiny fraction of the memory to do the same job the
module is inherently broken no matter how pretty it's code looks.

You can of course tell me to STFU - but look around the web I won't be
the first or last user to bemoan "import gzip"... :)

----------

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

From report at bugs.python.org  Fri Dec 11 00:15:15 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Dec 2009 23:15:15 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260486915.31.0.572111759191.issue7475@psf.upfronthosting.co.za>


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

These are not encodings, in that they don't convert characters to bytes.
It was a mistake that they were integrated into the codecs interfaces in
Python 2.x; this mistake is corrected in 3.x.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Dec 11 00:16:29 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 10 Dec 2009 23:16:29 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260486989.53.0.612807162614.issue7464@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I have two solutions for this problem.  The first is a mundane one, and 
what I employed in our production environment:
class RecvAdapter(object):
    def __init__(self, wrapped):
        self.wrapped = wrapped
    def recv(self, amt):
        return self.wrapped.read(amt)
    def close(self):
        self.wrapped.close()

...
    fp = socket._fileobject(RecvAdapter(r), close=True)


The second solution is a bit more interesting.  It involves applying 
what I call a weakmethod: A bound method that holds a weak ref to the 
object instance:

import weakref
class WeakMethod(object):
    def __init__(self, bound):
        self.weakself = weakref.proxy(bound.im_self)
        self.methodname = bound.im_func.func_name
    def __call__(self, *args, **kw):
        return getattr(self.weakself, self.methodname)(*args, **kw)

We then do:
    r.recv = WeakMethod(r.read)
    fp = socket._fileobject(r, close=True)

I've had many uses for a WeakMethod through the years.  I wonder if such 
a class might be considered useful enough to be put into the weakref 
module.

----------
keywords: +patch

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

From report at bugs.python.org  Fri Dec 11 00:19:06 2009
From: report at bugs.python.org (John Wiseman)
Date: Thu, 10 Dec 2009 23:19:06 +0000
Subject: [issue7476] pipes.quote does not handle zero-length args correctly
In-Reply-To: <1260487146.66.0.443499521552.issue7476@psf.upfronthosting.co.za>
Message-ID: <1260487146.66.0.443499521552.issue7476@psf.upfronthosting.co.za>


New submission from John Wiseman <jjwiseman at gmail.com>:

In python 2.5.2, I believe pipes.quote gives the wrong result for zero-
length arguments.

>>> from pipes import quote
>>> args = ['arg1', '', 'arg3']
>>> print 'mycommand %s' % (' '.join(quote(arg) for arg in args))
mycommand arg1  arg3

I think the result should be something like
mycommand arg1 '' arg3

----------
components: Library (Lib)
messages: 96225
nosy: jjwiseman
severity: normal
status: open
title: pipes.quote does not handle zero-length args correctly
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Dec 11 00:25:04 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Dec 2009 23:25:04 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260486915.31.0.572111759191.issue7475@psf.upfronthosting.co.za>
Message-ID: <4B21834D.9070601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> These are not encodings, in that they don't convert characters to bytes.
> It was a mistake that they were integrated into the codecs interfaces in
> Python 2.x; this mistake is corrected in 3.x.

Martin, I beg your pardon, but these codecs indeed implement valid
encodings and the fact that these codecs were removed was a
mistake.

They should be readded to Python 3.x.

Note that just because a codec doesn't convert between bytes
and characters only, doesn't make it wrong in any way. The codec
architecture in Python is designed to support same type encodings
just as well as ones between bytes and characters.

----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Dec 11 00:26:11 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Dec 2009 23:26:11 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260487571.42.0.829192568031.issue7475@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Reopening the ticket.

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

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

From report at bugs.python.org  Fri Dec 11 00:28:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Dec 2009 23:28:53 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260487733.55.0.095730812516.issue7475@psf.upfronthosting.co.za>


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

It's not possible to add these codecs back. Bytes objects (correctly)
don't have an encode method, and string objects (correctly) don't have a
decode method. The codec architecture of Python 3.x just doesn't support
this kind of application; the codec architecture of 2.x was flawed.

----------

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

From report at bugs.python.org  Fri Dec 11 01:00:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Dec 2009 00:00:06 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260489606.19.0.100098831942.issue7464@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The WeakMethod idea is not new:

http://code.activestate.com/recipes/81253/

http://mindtrove.info/articles/python-weak-references/#toc-extending-weak-
references

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

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

From report at bugs.python.org  Fri Dec 11 01:17:40 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 11 Dec 2009 00:17:40 +0000
Subject: [issue7476] pipes.quote does not handle zero-length args correctly
In-Reply-To: <1260487146.66.0.443499521552.issue7476@psf.upfronthosting.co.za>
Message-ID: <1260490660.47.0.939481377279.issue7476@psf.upfronthosting.co.za>


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

In addition, quote is undocumented, although there is a test for it. It
should also be documented and/or have a docstring.

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

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

From report at bugs.python.org  Fri Dec 11 01:52:02 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 11 Dec 2009 00:52:02 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260492722.74.0.534394191875.issue7470@psf.upfronthosting.co.za>


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

Sorry Christian, your patch appears just to rename 'fs' to 'ufs' so I'm
not sure if your patch is exactly what you intended.

----------
assignee:  -> vinay.sajip

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

From report at bugs.python.org  Fri Dec 11 02:56:15 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Dec 2009 01:56:15 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1260496575.52.0.0637226596777.issue7474@psf.upfronthosting.co.za>


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


----------
assignee:  -> jnoller

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

From report at bugs.python.org  Fri Dec 11 03:09:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Dec 2009 02:09:22 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260497362.43.0.859042266456.issue7475@psf.upfronthosting.co.za>


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

I agree with Martin. gzip and bz2 convert bytes to bytes. Encodings deal
strictly with unicode -> bytes.

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

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

From report at bugs.python.org  Fri Dec 11 07:54:16 2009
From: report at bugs.python.org (Jerry Seutter)
Date: Fri, 11 Dec 2009 06:54:16 +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: <1260514456.31.0.876692703209.issue7449@psf.upfronthosting.co.za>


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

The patch makes it so that tests that use threading skip rather than
generate errors when python is compiled --without-threads.

I added a skip_if_no('modulename') decorator to test_support.

Let me know if this patch is too big to review and I'll break it up.  It
is 800 lines.

One thing to note: when threading is disabled, all sqlite3 tests are
skipped.  There are a few test files that do not use threading, but I
couldn't think of an easy way to split them out.

Tested on OS X and Linux.

----------
keywords: +patch
Added file: http://bugs.python.org/file15522/nothreads.patch

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

From report at bugs.python.org  Fri Dec 11 07:54:56 2009
From: report at bugs.python.org (Jerry Seutter)
Date: Fri, 11 Dec 2009 06:54:56 +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: <1260514496.96.0.501475421788.issue7449@psf.upfronthosting.co.za>


Changes by Jerry Seutter <jseutter at gmail.com>:


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Dec 11 08:25:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 07:25:14 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260486371.63.0.140692433245.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260516346.3404.1.camel@localhost>


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

> How can I put this without being an ass? Hell, I'm no good at diplomacy
> - the gzip module blows chunks - if I can shell out to a standard unix
> util and it uses a tiny fraction of the memory to do the same job the
> module is inherently broken no matter how pretty it's code looks.

Well, let's say it is suboptimal. But it's certainly ok if you don't
have any tight performance constraints.
In any case, it won't improve until someone proposes a patch :-)

----------

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

From report at bugs.python.org  Fri Dec 11 08:37:40 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Dec 2009 07:37:40 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260517060.59.0.16083994841.issue7464@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

weak method idea seems interesting. I have not used it anytime yet, and
in this case,it seems okay.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri Dec 11 09:21:41 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 08:21:41 +0000
Subject: [issue7475] No hint about codecs removed : base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260519701.03.0.938917129835.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

?Everything you thought you knew about binary data and Unicode
 has changed.?

Reopening for the documentation part.

This "mistake" deserves some words in the documentation:
  docs.python.org/dev/py3k/whatsnew/3.0.html
      #text-vs-data-instead-of-unicode-vs-8-bit

And the conversion may be automated with 2to3, maybe.

----------
assignee:  -> georg.brandl
components: +2to3 (2.x to 3.0 conversion tool), Documentation -Library (Lib)
nosy: +georg.brandl
status: closed -> open
title: codecs missing: base64 bz2 hex zlib ... -> No hint about codecs removed : base64 bz2 hex zlib ...

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

From report at bugs.python.org  Fri Dec 11 09:31:19 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 08:31:19 +0000
Subject: [issue7475] No hint about codecs removed : base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260520279.6.0.727191204438.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Is it possible to add "DeprecationWarning" for these codecs
when using "python -3" ?

>>> {}.has_key('a')
__main__:1: DeprecationWarning: dict.has_key() not supported in 3.x;
            use the in operator
False
>>> print `123`
<stdin>:1: SyntaxWarning: backquote not supported in 3.x; use repr()
123
>>> 'abc'.encode('base64')
'YWJj\n'

----------

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

From report at bugs.python.org  Fri Dec 11 09:31:52 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 08:31:52 +0000
Subject: [issue7475] No hint about codecs removed : base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260520312.12.0.389449267758.issue7475@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Dec 11 09:33:13 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 08:33:13 +0000
Subject: [issue7475] No hint about codecs removed: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260520393.89.0.740845066663.issue7475@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
title: No hint about codecs removed : base64 bz2 hex zlib ... -> No hint about codecs removed: base64 bz2 hex zlib ...

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

From report at bugs.python.org  Fri Dec 11 10:17:44 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 11 Dec 2009 09:17:44 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1260523064.26.0.123366246777.issue7470@psf.upfronthosting.co.za>


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

Never mind my earlier comment, I looked at the change more carefully
after a cup of coffee, and it now makes sense to me ;-)

Fixed checked into trunk (r76754), thanks.

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

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

From report at bugs.python.org  Fri Dec 11 10:26:31 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 09:26:31 +0000
Subject: [issue7475] No hint about codecs removed: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260523591.91.0.86886828928.issue7475@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15523/issue7475_warning.diff

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

From report at bugs.python.org  Fri Dec 11 10:40:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 11 Dec 2009 09:40:40 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1260524440.42.0.182404892809.issue7464@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

cool.  The mindtrove one in particular seems nice.  I didn't realize 
that one could build boundobjects oneself.
Is there any chance of getting a weakmethod class into the weakref 
module?

----------

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

From report at bugs.python.org  Fri Dec 11 10:46:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 11 Dec 2009 09:46:56 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260487733.55.0.095730812516.issue7475@psf.upfronthosting.co.za>
Message-ID: <4B22150C.4040703@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> It's not possible to add these codecs back. Bytes objects (correctly)
> don't have an encode method, and string objects (correctly) don't have a
> decode method. The codec architecture of Python 3.x just doesn't support
> this kind of application; the codec architecture of 2.x was flawed.

Of course it does support these kinds of codecs. The codec
architecture hasn't changed between 2.x and 3.x, just the way
a few methods work.

All we agreed to is that unicode.encode() will only return bytes,
while bytes.decode() will only return unicode. So the methods won't
support same type conversions, because Guido didn't want to
have methods that return different types based on the chosen
parameter (the codec name in this case).

However, you can still use codecs.encode() and codecs.decode()
to work with codecs that return different combinations of
types. I explicitly added that support back to 3.0.

You can't argue that just because two methods don't support
a certain type combination, the whole architecture doesn't
support this anymore.

Also note that codecs allow a much more far-reaching use
than just through the unicode and bytes methods: you can
use them as seamless wrappers for streams, subclass from
them, use their methods directly, etc. etc.

So your argument that just because the two methods don't
support these codecs anymore is just not good enough
to warrant their removal.

----------
title: No hint about codecs removed: base64 bz2 hex zlib ... -> codecs missing: base64 bz2 hex zlib ...

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

From report at bugs.python.org  Fri Dec 11 10:47:23 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 11 Dec 2009 09:47:23 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260524843.41.0.788795778082.issue7475@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution: invalid -> 

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

From report at bugs.python.org  Fri Dec 11 10:56:24 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Dec 2009 09:56:24 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <20091211095612.GA9452@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Dec 11, 2009 at 09:40:40AM +0000, Kristj?n Valur J?nsson wrote:
> Is there any chance of getting a weakmethod class into the weakref 
> module?

This is a separate feature request on weakref module. It may opened
and discussion carried out there?

----------

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

From report at bugs.python.org  Fri Dec 11 10:56:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 11 Dec 2009 09:56:58 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260497362.43.0.859042266456.issue7475@psf.upfronthosting.co.za>
Message-ID: <4B221767.7010401@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Benjamin Peterson wrote:
> 
> Benjamin Peterson <benjamin at python.org> added the comment:
> 
> I agree with Martin. gzip and bz2 convert bytes to bytes. Encodings deal
> strictly with unicode -> bytes.

Sorry, Bejamin, but that's simply not true.

Codecs can work with arbitrary types, it's just that the helper
methods on unicode and bytes objects only support one combination
of types in Python 3.x.

codecs.encode()/.decode() provide access to all codecs, regardless
of their supported type combinations and of course, you can use
them directly via the codec registry, subclass from them, etc.

----------

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

From report at bugs.python.org  Fri Dec 11 11:22:24 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 10:22:24 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260526944.71.0.320922162987.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Thinking about it, I am +1 to reimplement the codecs.

We could implement new methods to replace the old one.
(similar to base64.encodebytes and base64.decodebytes)

>>> b'abc'.encodebytes('base64')
b'YWJj\n'
>>> b'abc'.encodebytes('zlib').encodebytes('base64')
b'eJxLTEoGAAJNASc=\n'
>>> b'UHl0aG9u'.decodebytes('base64').decode('utf-8')
'Python'

----------
components: +Library (Lib)

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

From report at bugs.python.org  Fri Dec 11 12:30:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Dec 2009 11:30:00 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260531000.96.0.934785127505.issue7452@psf.upfronthosting.co.za>


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

Yes, this can be closed as far as I'm concerned.

----------

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

From report at bugs.python.org  Fri Dec 11 12:39:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 11:39:47 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260531587.44.0.429072628022.issue7455@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15487/cpickle_load_pop.patch

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

From report at bugs.python.org  Fri Dec 11 12:39:53 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 11:39:53 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260531593.9.0.311819380347.issue7455@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file15494/cpickle_load_pop-2.patch

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

From report at bugs.python.org  Fri Dec 11 12:40:44 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 11:40:44 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260531644.08.0.0851895531894.issue7455@psf.upfronthosting.co.za>


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

Oops, cpickle_load_pop-2.patch contains an useless variable (picklingError 
= pickle.UnpicklingError). Here is the version 3 of my patch.

----------
Added file: http://bugs.python.org/file15524/cpickle_load_pop-3.patch

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

From report at bugs.python.org  Fri Dec 11 12:42:39 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 11:42:39 +0000
Subject: [issue4853] I/O operation on closed socket: improve the error message
In-Reply-To: <1231201863.3.0.481342348653.issue4853@psf.upfronthosting.co.za>
Message-ID: <1260531759.46.0.62172470898.issue4853@psf.upfronthosting.co.za>


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

Well, this issue is not really important. The current behaviour is already 
correct (raising an error if the file is closed).

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Dec 11 13:08:52 2009
From: report at bugs.python.org (Hasan)
Date: Fri, 11 Dec 2009 12:08:52 +0000
Subject: [issue7477] kqueue timers don't work properly
In-Reply-To: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>
Message-ID: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>


New submission from Hasan <halayli at gmail.com>:

kqueue timers are not working at all on Mac OSX 10.6.1 (probably not 
working on other BSDs as well but haven't tested it).

Here's a simply repro:

from select import *
kq = kqueue()
e = kevent(10000, flags=KQ_EV_ENABLE|KQ_EV_ONESHOT, 
filter=KQ_FILTER_TIMER)
e
<select.kevent ident=10000 filter=-7 flags=0x14 fflags=0x0 data=0x0 
udata=0x0>
new_e = f.control([e], 1, 0)

This should block 10s before it returns control with new_e having a timer 
event returned. However, it isn't the case.
control returns immediately returning a busted event:
[<select.kevent ident=10000 filter=-7 flags=0x4000 fflags=0x0 data=0x2 
udata=0x0>]

Am I missing something?

----------
components: Library (Lib)
messages: 96247
nosy: hasan
severity: normal
status: open
title: kqueue timers don't work properly
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec 11 13:11:19 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 12:11:19 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>


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

Methods create_function, create_aggregate, set_authorizer, 
set_progress_handler, create_collation of the _sqlite3.Connection class 
doesn't catch PyDict_SetItem/PyDict_DelItem errors. The error will be 
catched by next opcode/function call.

The error occurs if the callback argument is not hashable.

Attached patch adds the missing tests, and add unit tests.

There is not unit test for Connection.create_collation() because I don't 
know how to test it. The call to PyDict_SetItem() is different, because 
the callback is not the dictionary key but the value (so it's not a 
problem if the callback is not hashable).

----------
components: Extension Modules
messages: 96248
nosy: haypo
severity: normal
status: open
title: _sqlite3 doesn't catch PyDict_SetItem error
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 11 13:13:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Dec 2009 12:13:11 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1260533591.66.0.505559269981.issue7478@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file15525/_sqlite3_setdict.patch

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

From report at bugs.python.org  Fri Dec 11 13:33:41 2009
From: report at bugs.python.org (steve)
Date: Fri, 11 Dec 2009 12:33:41 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>


New submission from steve <eyebootleg at gmail.com>:

Reason for opening this bug:
============================
I am opening a bug because the documentation here:
http://docs.python.org/library/os.html#os.lchmod

Says that in python 2.6 there is a method os.lchmod() for changing the
permissions of unix symbolic links,  

I am running Python 2.6 on several flavors of Linux, and non of them
have os.lchmod().  My understanding is that one can not change the
permissions of a sybolic link on Linux because the symlink basically
'inherits' the permissions of the file if points to.

Is this ment to be used on other flavors of UNIX other than Linux?

I am only really familiar with Linux, and have not played with man y
other flavors on UNIX.  Can other flavor change the permission of
symbolic links?


What I am Looking for from this bug report:
===========================================
I would like to know what is happening with os.lchmod.  If it is not
suppose to be there, I would like it removed from the documentation.  If
it is mena for other flavors of unix, but not linux.  I think it should
be implemented as just a function that passes.

Let me know what you think.

Peace,
Steve

----------
assignee: georg.brandl
components: Documentation
messages: 96249
nosy: bluegeek, georg.brandl
severity: normal
status: open
title: os.lchmod is not present
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Dec 11 13:35:30 2009
From: report at bugs.python.org (Hasan)
Date: Fri, 11 Dec 2009 12:35:30 +0000
Subject: [issue7477] kqueue timers don't work properly
In-Reply-To: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>
Message-ID: <1260534930.62.0.442935565481.issue7477@psf.upfronthosting.co.za>


Hasan <halayli at gmail.com> added the comment:

Typo in the repro.

The statement:
new_e = f.control
should be:
new_e = kq.control

----------

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

From report at bugs.python.org  Fri Dec 11 13:54:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Dec 2009 12:54:40 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <4B221767.7010401@egenix.com>
Message-ID: <1afaf6160912110454r5551146dn32ccdd17fd6e430f@mail.gmail.com>


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

2009/12/11 Marc-Andre Lemburg <report at bugs.python.org>:
> codecs.encode()/.decode() provide access to all codecs, regardless
> of their supported type combinations and of course, you can use
> them directly via the codec registry, subclass from them, etc.

Didn't you have a proposal for bytes.transform/untransform for
operations like this?

----------

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

From report at bugs.python.org  Fri Dec 11 14:06:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 13:06:30 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260536790.65.0.072539354732.issue7479@psf.upfronthosting.co.za>


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

lchmod seems to be a BSD-specific function.

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Dec 11 14:09:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 13:09:43 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1260536983.71.0.762427753711.issue7478@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ghaering
priority:  -> normal
stage:  -> patch review
type:  -> crash
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec 11 14:10:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 13:10:15 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260537015.61.0.827407413847.issue7455@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Fri Dec 11 14:11:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 13:11:27 +0000
Subject: [issue7394] sqlite3: some OperationalError exceptions should be
	ProgrammingError (PEP 249)
In-Reply-To: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
Message-ID: <1260537087.08.0.262319338057.issue7394@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ghaering

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

From report at bugs.python.org  Fri Dec 11 14:13:51 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 11 Dec 2009 13:13:51 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1afaf6160912110454r5551146dn32ccdd17fd6e430f@mail.gmail.com>
Message-ID: <4B22458C.6010503@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Benjamin Peterson wrote:
> 
> Benjamin Peterson <benjamin at python.org> added the comment:
> 
> 2009/12/11 Marc-Andre Lemburg <report at bugs.python.org>:
>> codecs.encode()/.decode() provide access to all codecs, regardless
>> of their supported type combinations and of course, you can use
>> them directly via the codec registry, subclass from them, etc.
> 
> Didn't you have a proposal for bytes.transform/untransform for
> operations like this?

Yes. At the time it was postponed, since I brought it up late
in the 3.0 release process. Perhaps I should bring it up again.

Note that those methods are just convenient helpers to access
the codecs and as such only provide limited functionality.

The full machinery itself is accessible via the codecs module and
the code in the encodings package. Any decision to include a codec
or not needs to be based on whether it fits the framework in those
modules/packages, not the functionality we expose on unicode and
bytes objects.

----------

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

From report at bugs.python.org  Fri Dec 11 14:34:58 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Dec 2009 13:34:58 +0000
Subject: [issue1398] Can't pickle partial functions
In-Reply-To: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
Message-ID: <1260538498.44.0.353778668339.issue1398@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Indeed. Jack Diederich added support for pickling partial functions in
r70931.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec 11 14:54:21 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Dec 2009 13:54:21 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1260539661.7.0.919931740491.issue6687@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Mark Dickinson wrote:
> Is there still a need for a separate C function for creating a zero-
> initialized bytes object from a Py_ssize_t or a Python integer?

What C function are you referring to?

> And this check doesn't cover other, similar, cases: for example, list('')
> will still be converted by PyBytes_FromObject, while list('123') won't.

Well, one is a just empty list and the other a list of strings. I don't see
why converting a empty list to bytes should raise an error. Although I agree
the type check is a bit out of place, I think it will help prevents bugs. 

In addition, PyBytes_FromObject() is documented as equivalent to the
built-in
bytes(). Since calling bytes() with any unicode string raises a TypeError
exception, unless an encoding is specified, I believe PyBytes_FromObject()
should also follow this convention.

----------

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

From report at bugs.python.org  Fri Dec 11 15:11:02 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Dec 2009 14:11:02 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1260540662.33.0.734953300064.issue2335@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

If there are no objections, I will commit this patch later this week.

----------

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

From report at bugs.python.org  Fri Dec 11 15:15:10 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Dec 2009 14:15:10 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1260540910.18.0.125918792636.issue2333@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

If there are no objections, I will commit this patch later this week
after issue #2335.

----------

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

From report at bugs.python.org  Fri Dec 11 15:17:27 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Dec 2009 14:17:27 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1260541047.91.0.69075611786.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Can someone review the patches? I would like to commit this later this week.

----------

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

From report at bugs.python.org  Fri Dec 11 16:11:01 2009
From: report at bugs.python.org (Paul Nelson)
Date: Fri, 11 Dec 2009 15:11:01 +0000
Subject: [issue7473] x84_64 arch Missing from 2.6.4 Mac universal binaries -
	Cripples building embedded 64-bit
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260544261.37.0.944893504328.issue7473@psf.upfronthosting.co.za>


Paul Nelson <Paul.Nelson at jmp.com> added the comment:

Once the binary (ppc, i386) binary is installed it becomes impossible to 
rebuild python from source as 3-way binary on the system, without first 
removing the 2.6.4 dual architecture 
/Library/Frameworks/Python.framework.  
It causes compile failures in _curses and _curses_panel, on x86_64.
(Leopard 10.5.7 intel)

Please distribute it as a 3-way binary. Or warn in big type that the 
current install is really only suitable for Tiger and earlier systems.  
Especially since Apple is really pushing for apps to be 64-bit as well 
as 32.

Thanks
Paul

----------
type: behavior -> compile error

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

From report at bugs.python.org  Fri Dec 11 16:32:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2009 15:32:43 +0000
Subject: [issue7473] x84_64 arch Missing from 2.6.4 Mac universal binaries -
	Cripples building embedded 64-bit
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260545563.54.0.742314549845.issue7473@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't agree that the current binaries are only useful for Tiger and 
earlier, the binaries work just fine on Leopard and Snow Leopard as 
well.

FWIW. I'm planning to provide a 3-way universal binary, or even just 
intel (i386, x86_64) for Python 2.7 and 3.2. That installer will only 
support OSX 10.5 or later.

BTW. I'll gladly review and patches that make it easier to compile a 3-
way univeral build without first removing the existing build. 

The reason that the current installer is not 3-way universal is that it 
is not possibly to have a 3-way universal binary that will run on 10.3.9 
or later unless you use different deployment targets for the various 
architectures and those different deployment targets cause observable 
differences in behavior because Apple fixed a number of Unix API issues 
for deployment target 10.5 (or later).

----------

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

From report at bugs.python.org  Fri Dec 11 16:33:38 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2009 15:33:38 +0000
Subject: [issue7473] Compile error when building a 3-way universal framework
	when a 2-way universal framework is present
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260545618.18.0.0879109321321.issue7473@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> accepted
stage:  -> needs patch
title: x84_64 arch Missing from 2.6.4 Mac universal binaries - Cripples building embedded 64-bit -> Compile error when building a 3-way universal framework when a 2-way universal framework is present

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

From report at bugs.python.org  Fri Dec 11 16:34:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2009 15:34:00 +0000
Subject: [issue7452] Invalid mnemonic 'fnstcw'
In-Reply-To: <1260228814.04.0.00170758422827.issue7452@psf.upfronthosting.co.za>
Message-ID: <1260545640.53.0.969397463819.issue7452@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/issue7452>
_______________________________________

From report at bugs.python.org  Fri Dec 11 16:49:34 2009
From: report at bugs.python.org (Paul Nelson)
Date: Fri, 11 Dec 2009 15:49:34 +0000
Subject: [issue7473] Compile error when building a 3-way universal framework
	when a 2-way universal framework is present
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1260546574.57.0.285139780285.issue7473@psf.upfronthosting.co.za>


Paul Nelson <Paul.Nelson at jmp.com> added the comment:

I would humbly suggest that it be 3-way, until it is 10.6 (Snow Leopard) 
and above.  In our case as long as we support Leopard, we will be 
supporting all 3 architectures for our software.  

It would be appreciated if the web page indicated that the .dmg is 
currently only (ppc i386),  It would have prevented issues like ours 
where I am working on embedding python into the product which is 32 bit 
and 64 bit intel and 32-bit ppc.  And several developers unwittingly 
installed the 2.6.4 (ppc i386) on their system, and then could no longer 
build the 64-bit version of our application, since XCode tried linking 
with the new 2.6 framework even though the 2.5 Python framework was the 
one specified in the project file.

----------

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

From report at bugs.python.org  Fri Dec 11 16:55:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Dec 2009 15:55:59 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260546959.7.0.0406594135464.issue7466@psf.upfronthosting.co.za>


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

IMO it would be better to call _PyObject_GC_IS_TRACKED() explicitly
rather than rely on a subtle difference between the two APIs as in the
current patch.

----------

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

From report at bugs.python.org  Fri Dec 11 17:45:15 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 16:45:15 +0000
Subject: [issue7466] Segmentation fault after about 20 seconds on lenovo T500
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260549915.87.0.709520763217.issue7466@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Ok. It is here:
  http://bugs.python.org/file15520/issue7466.diff

----------

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

From report at bugs.python.org  Fri Dec 11 17:46:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Dec 2009 16:46:04 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1260549964.95.0.276518111858.issue6687@psf.upfronthosting.co.za>


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

> What C function are you referring to?

A currently non-existent one!  I was wondering whether the current bytes-
from-integer functionality that PyBytes_FromObject supplies is important 
enough to preserve somehow.  I'd guess not.

----------

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

From report at bugs.python.org  Fri Dec 11 18:05:52 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 17:05:52 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260551152.45.0.612192230242.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I've ported the codecs from Py2:
    base64, bytes_escape, bz2, hex, quopri, rot13, uu and zlib

It's not a big deal. Basically:
 - StringIO.StringIO --> io.BytesIO
 - 'string_escape' --> 'bytes_escape'

Will add documentation if we agree on the feature.

----------
Added file: http://bugs.python.org/file15526/issue7475_missing_codecs_py3k.diff

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

From report at bugs.python.org  Fri Dec 11 18:26:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Dec 2009 17:26:07 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260552367.67.0.613915456861.issue3366@psf.upfronthosting.co.za>


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

nirinA:  thanks for prodding this issue.  Yes, it is still alive (just). 
:)

About adding the Euler constant:  I agree this should be added.  Do you 
have time to expand your patch to include docs and a test or two?

For expm1, I was planning to use the libm function when it exists (which 
I expect it will on most platforms), and just use a quick hack based on 
the identity

  expm1(x) = sinh(x/2)*exp(x/2)

for platforms where it's missing.

I'll look at the erf and erfc implementations.

Daniel:  re incomplete beta and gamma functions, I'd prefer to limit 
this particular issue to the C99 math functions.  It's difficult to know 
where to draw the line, but it seems to me that these are really the 
domain of numpy/scipy.  And they involve multiple input arguments, which 
makes them *darned hard* to write and test!  Anyway, if you'd like to 
see those added to Python's math module, maybe this could be brought up 
on python-dev to see how much support there is.

----------

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

From report at bugs.python.org  Fri Dec 11 18:27:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Dec 2009 17:27:00 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260552420.1.0.14073011685.issue3366@psf.upfronthosting.co.za>


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

> expm1(x) = sinh(x/2)*exp(x/2)

Should be 2*sinh(x/2)*exp(x/2).

----------

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

From report at bugs.python.org  Fri Dec 11 18:32:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Dec 2009 17:32:25 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260552745.21.0.479482188456.issue3366@psf.upfronthosting.co.za>


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

lgamma patch committed to trunk (with looser tests) in r76755.

----------

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

From report at bugs.python.org  Fri Dec 11 19:00:32 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Dec 2009 18:00:32 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1260554432.16.0.54522327733.issue7380@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


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

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

From report at bugs.python.org  Fri Dec 11 19:09:00 2009
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 11 Dec 2009 18:09:00 +0000
Subject: [issue7480] trite documentation issue.
In-Reply-To: <1260554940.07.0.376480280758.issue7480@psf.upfronthosting.co.za>
Message-ID: <1260554940.07.0.376480280758.issue7480@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/dev/py3k/library/stdtypes.html#index-559

Proposal: remove last sentence from

"class.__bases__
The tuple of base classes of a class object. If there are no base 
classes, this will be an empty tuple."


Reason: Sentence is a python 2 relic.  The only case is this---

>>> object.__bases__
()

Point being that documentation should be clear, puzzles left as a 
comprehension test.

----------
assignee: georg.brandl
components: Documentation
messages: 96269
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: trite documentation issue.
versions: Python 3.1

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

From report at bugs.python.org  Fri Dec 11 19:31:48 2009
From: report at bugs.python.org (Alan Isaac)
Date: Fri, 11 Dec 2009 18:31:48 +0000
Subject: [issue5716] Overzealous deprecation of BaseException.message
In-Reply-To: <1239106026.05.0.616331762443.issue5716@psf.upfronthosting.co.za>
Message-ID: <1260556308.07.0.911961759416.issue5716@psf.upfronthosting.co.za>


Alan Isaac <alan.isaac at gmail.com> added the comment:

FYI a patch has been committed that should fix this. For discussion see
http://bugs.python.org/issue6844

----------
nosy: +aisaac

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

From report at bugs.python.org  Fri Dec 11 20:15:40 2009
From: report at bugs.python.org (John Mark Schofield)
Date: Fri, 11 Dec 2009 19:15:40 +0000
Subject: [issue7481] Failing to start a thread leaves "zombie" thread in
	"initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>


New submission from John Mark Schofield <jschofield at gmail.com>:

SUMMARY: When you attempt to start a thread, and you're unable to (you
get thread.error) it leaves a thread stuck in an "initial" state that
never exits. (threading.enumerate() shows the threads and lists their
status as "initial.")

REPRODUCTION STEPS: See attached file.

EXPECTED RESULT: Failing to start a thread should not leave the thread
in an un-executable state. I would expect the thread start to either
succeed or result in the thread being closed and GC'd.

VERIFIED ON:
Python 2.5.2 on OS X 10.5.8
Python 2.5.2 on Ubuntu 8.04
Python 2.5.4 on Windows XP Professional (Version 2002) SP3
Python 2.6.1 on OS X 10.6.2

----------
files: repro_case.py
messages: 96271
nosy: schof
severity: normal
status: open
title: Failing to start a thread leaves "zombie" thread in "initial" state
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15527/repro_case.py

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

From report at bugs.python.org  Fri Dec 11 20:21:09 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 11 Dec 2009 19:21:09 +0000
Subject: [issue7466] Segmentation fault with tuple + gc.collect()
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260559269.23.0.860083477797.issue7466@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: Segmentation fault after about 20 seconds on lenovo T500 -> Segmentation fault with tuple + gc.collect()

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

From report at bugs.python.org  Fri Dec 11 21:33:47 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 11 Dec 2009 20:33:47 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260563627.31.0.730723249837.issue7471@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I tried passing a size to readline to see if increasing the chunk helps
(test file was 120meg with 700k lines).  For values 1k-10k all took
around 30 seconds, with a value of 100 it took 80 seconds, with a value
of 100k it ran for several minutes before I killed it.  The default
starts at 100 and quickly maxes to 512, which seems to be a sweet spot
(thanks whomever figured that out!).

I profiled it and function overhead seems to be the real killer.  30% of
the time is spent in readline().  The next() function does almost
nothing and consumes 1/4th the time of readline().  Ditto for read() and
_unread().  Even lowly len() consumes 1/3rd the time of readline()
because it is called over 2million times.

There doesn't seem to be any way to speed this up without rewriting the
whole thing as a C module.  I'm closing the bug WONTFIX.

----------
nosy: +jackdied
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Dec 11 22:01:24 2009
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 11 Dec 2009 21:01:24 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1260565284.26.0.468410175005.issue7455@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

This seems to have been introduced in r72930 when the stackUnderflow()
was moved from the top of the function to the bottom.  It used to test
for len > 0.

Question, should cPickle and pickle be raising the same error here? 
UnpicklingError is defined in pickle.py and never used but cPickle.c
uses it frequently.

----------
nosy: +collinwinter, jackdied

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

From report at bugs.python.org  Fri Dec 11 22:53:56 2009
From: report at bugs.python.org (Hasan)
Date: Fri, 11 Dec 2009 21:53:56 +0000
Subject: [issue7477] kqueue timers don't work properly
In-Reply-To: <1260533332.03.0.937259620365.issue7477@psf.upfronthosting.co.za>
Message-ID: <1260568436.22.0.0966892273424.issue7477@psf.upfronthosting.co.za>


Hasan <halayli at gmail.com> added the comment:

Closing it. My mistake. I was passing incorrect arguments. KQ_EV_ONESHOT 
requires KQ_EV_ADD as well, and timer data goes into data.

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

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

From report at bugs.python.org  Fri Dec 11 23:17:29 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Dec 2009 22:17:29 +0000
Subject: [issue7482] Improve ZeroDivisionError message for float and complex
	object
In-Reply-To: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
Message-ID: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The current error messages for divisions by 0 of float and complex
object say "float/complex division", whereas for int and long is
"integer/long division by zero":
>>> 5/0
ZeroDivisionError: integer division or modulo by zero
>>> 5.0/0
ZeroDivisionError: float division

The attached patch adds "by zero" to the error messages of float and
complex in case of division, modulo or divmod by zero.

(Should I add tests to check the error message too?)

----------
assignee: ezio.melotti
components: Interpreter Core
files: issue7482.patch
keywords: needs review, patch, patch
messages: 96275
nosy: ezio.melotti, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Improve ZeroDivisionError message for float and complex object
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15528/issue7482.patch

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

From report at bugs.python.org  Fri Dec 11 23:59:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Dec 2009 22:59:31 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1260572371.46.0.474065011925.issue1967@psf.upfronthosting.co.za>


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

The patch (backport_dictviews.diff) doesn't seem to work for me. I
applied it on trunk after a svn up, did "./configure && make" and when I
tried d.view{items|keys|values} Python segfaulted:

Python 2.7a1+ (trunk:76759M, Dec 12 2009, 00:28:52)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = dict(a=3, b=5)
>>> d.viewitems()
Segmentation fault

I'm tested it on Ubuntu 9.10.

The docstrings of the three methods are also wrong:

+PyDoc_STRVAR(viewkeys__doc__,
+	     "D.keys() -> a set-like object providing a view on D's keys");

This should be "D.viewkeys() -> ...", same with the other two.

----------
keywords: +needs review -26backport
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Dec 12 00:09:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 11 Dec 2009 23:09:10 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <4B221767.7010401@egenix.com>
Message-ID: <4B22D112.3000100@v.loewis.de>


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

> codecs.encode()/.decode() provide access to all codecs, regardless
> of their supported type combinations and of course, you can use
> them directly via the codec registry, subclass from them, etc.

I presume that the OP didn't talk about codecs.encode, but about
the methods on string objects. flox, can you clarify what precisely
it is that you miss?

----------

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

From report at bugs.python.org  Sat Dec 12 00:14:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Dec 2009 23:14:03 +0000
Subject: [issue5716] Overzealous deprecation of BaseException.message
In-Reply-To: <1239106026.05.0.616331762443.issue5716@psf.upfronthosting.co.za>
Message-ID: <1260573243.23.0.279092271433.issue5716@psf.upfronthosting.co.za>


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

Closing this as a duplicate of #6844.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> BaseException DeprecationError raises inappropriately

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

From report at bugs.python.org  Sat Dec 12 00:15:18 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 11 Dec 2009 23:15:18 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260573318.83.0.661273227963.issue7479@psf.upfronthosting.co.za>


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

All functions in the POSIX/os module are available only on those systems
that support them, and then do exactly what the system says they should
do. So if your system doesn't have lchmod, the os module won't provide
such a function on your system. There are systems which do provide
lchmod, e.g. NetBSD 1.3 and later.

Exposing this as a no-op function on systems which don't implement it
would be incorrect. If you want to wrap it with a no-op function in your
application, go ahead - it's easy enough.

I fail to see a bug in this report, so closing it as invalid.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Dec 12 00:52:52 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 11 Dec 2009 23:52:52 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1260575572.13.0.257194075858.issue1615158@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Sat Dec 12 04:15:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Dec 2009 03:15:28 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260587728.09.0.338611522435.issue7479@psf.upfronthosting.co.za>


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

Perhaps the bug is a small documentation bug, in that it should be
"Availability: BSD-based unix"?  We don't seem to have any other
examples of doing that in the docs, though.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat Dec 12 04:22:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Dec 2009 03:22:01 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260588121.48.0.439515013354.issue6108@psf.upfronthosting.co.za>


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

In r64791, BaseException gained a new __unicode__ method that does the
equivalent of the following things:
 * if the number of args is 0, returns u''
 * if it's 1 returns unicode(self.args[0])
 * if it's >1 returns unicode(self.args)

Before this, BaseException only had a __str__ method, so unicode(e)
(with e being an exception derived from BaseException) called:
 * e.__str__().decode(), if e didn't implement __unicode__
 * e.__unicode__(), if e implemented an __unicode__ method

Now, all the derived exceptions that don't implement their own
__unicode__ method inherit the "generic" __unicode__ of BaseException,
and they use that instead of falling back on __str__.
This is generally ok if the numbers of args is 0 or 1, but if there are
more args, there's usually some specific formatting in the __str__
method that is lost when BaseException.__unicode__ returns
unicode(self.args).

Possible solutions:
 1) implement a __unicode__ method that does the equivalent of calling
unicode(str(self)) (i.e. converting to unicode the message returned by
__str__ instead of converting self.args);
 2) implement a __unicode__ method that formats the message as __str__
for all the exceptions with a __str__ that does some specific formatting;

Attached there's a proof of concept (issue6108.diff) where I tried to
implement the first method with UnicodeDecodeError. This method can be
used as long as __str__ always returns only ascii.

The patch seems to work fine for me (note: this is my first attempt to
use the C API). If the approach is correct I can do the same for the
other exceptions too and submit a proper patch.

----------
assignee:  -> ezio.melotti
keywords: +patch
Added file: http://bugs.python.org/file15529/issue6108.diff

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

From report at bugs.python.org  Sat Dec 12 04:49:37 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 12 Dec 2009 03:49:37 +0000
Subject: [issue7483] str.format behaviour changed from Python 2.6
In-Reply-To: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
Message-ID: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

In Python 2.6,

>>> '{0:0<30}'.format(1)
'100000000000000000000000000000'
>>> '{0:-<30}'.format(1)
'1-----------------------------'


In Python 2.7a / 3.1,

>>> '{0:0<30}'.format(1)
'000000000000000000000000000001'
>>> '{0:-<30}'.format(1)
'1-----------------------------'

----------
components: Interpreter Core
messages: 96282
nosy: falsetru
severity: normal
status: open
title: str.format behaviour changed from Python 2.6
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Dec 12 05:22:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Dec 2009 04:22:18 +0000
Subject: [issue7483] str.format behaviour changed from Python 2.6
In-Reply-To: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
Message-ID: <1260591738.24.0.992951121337.issue7483@psf.upfronthosting.co.za>


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


----------
assignee:  -> eric.smith
nosy: +eric.smith

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

From report at bugs.python.org  Sat Dec 12 06:24:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Dec 2009 05:24:39 +0000
Subject: [issue7483] str.format behaviour changed from Python 2.6
In-Reply-To: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
Message-ID: <1260595479.18.0.574200062202.issue7483@psf.upfronthosting.co.za>


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

The problem seems to be in Objects/stringlib/formatter.h at line 472:
    if (format->fill_char == '0')
        spec->n_min_width = format->width - n_non_digit_non_padding;
    else
        spec->n_min_width = 0;

I tried to comment out that part and leave just the "spec->n_min_width =
0;" and '{0:0<30}'.format(1) returned the correct result.
Even if it showed that the problem is there, this is probably the wrong
solution.

----------
nosy: +ezio.melotti
priority:  -> high
versions: +Python 3.2

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

From report at bugs.python.org  Sat Dec 12 06:50:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Dec 2009 05:50:13 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1260597013.66.0.834800893656.issue1615158@psf.upfronthosting.co.za>


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


----------
keywords: +needs review

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

From report at bugs.python.org  Sat Dec 12 07:55:56 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=)
Date: Sat, 12 Dec 2009 06:55:56 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>


New submission from Manuel P?gouri?-Gonnard <mpg at elzevir.fr>:

Hi,

The verify method of SMTP objects created with smtplib doesn't work
properly with servers running Postfix, due to quoting problems: the
address is enclosed in pointed brackets by the method, which changes the
way it is interpreted by the server.

The attached demo file uses the mx1.nic.fr server, which runs Postfix
and exhibits the problem at the time of the writing.

RFC 5321 says the argument of VRFY is a string representing a "user
name", without saying much about what a "user name" is, but nothing
suggests it should be quoted in pointed brackets. Moreover, the example
in D.4 doens't use any quoting. 

Anyway, even if Postfix was wrong, I think it would be worth trying to
support it, since it is quite widely used.

Thanks!

----------
components: Library (Lib)
files: bsl.py
messages: 96284
nosy: mpg
severity: normal
status: open
title: smtplib: verify breaks with Postfix servers
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file15530/bsl.py

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

From report at bugs.python.org  Sat Dec 12 09:00:19 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Dec 2009 08:00:19 +0000
Subject: [issue7483] str.format behaviour changed from Python 2.6
In-Reply-To: <1260589777.59.0.256814428179.issue7483@psf.upfronthosting.co.za>
Message-ID: <1260604819.28.0.199296335072.issue7483@psf.upfronthosting.co.za>


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

This is a duplicate of issue 6902. I have a patch for that in the works.

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

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

From report at bugs.python.org  Sat Dec 12 09:22:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Dec 2009 08:22:54 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1260606174.74.0.815825984619.issue7402@psf.upfronthosting.co.za>


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

The example alone can't be fixed, because half of the section talks
about how useful reduce() is.
The whole document should IMHO be rewritten, possibly using some of the
examples in
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
I already asked to David and he said that the license (CC-BY-SA) allows
to do that.
If you agree to rewrite it and no one else volunteer, I can try to do
it, but I don't know when I'll have time.

----------
nosy: +ezio.melotti
priority:  -> low
versions:  -Python 3.0

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

From report at bugs.python.org  Sat Dec 12 09:29:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Dec 2009 08:29:11 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1260606551.25.0.139617897813.issue7396@psf.upfronthosting.co.za>


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


----------
nosy: +michael.foord, ncoghlan, pitrou, r.david.murray
priority:  -> normal
versions:  -Python 3.0

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

From report at bugs.python.org  Sat Dec 12 09:40:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Dec 2009 08:40:58 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1260607258.94.0.819957378103.issue7402@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I think the example is fine as-is.  It could be changed to a
product example:  reduce(operator.mul, range(1, n+1)) or somesuch. 
Also, the text could be modified to mention sum().  But it is also fine
if the example is unchanged, it does show how reduce() works.

Recommend closing or just having a very minor edit.

----------
assignee: rhettinger -> 

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

From report at bugs.python.org  Sat Dec 12 10:45:52 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Dec 2009 09:45:52 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260611152.6.0.843542248986.issue7479@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't see why we can't start it.  I'd prefer "Some Unices" though,
since you never know when e.g. Linux is going to start supporting e.g.
lchmod().

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

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

From report at bugs.python.org  Sat Dec 12 11:07:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 12 Dec 2009 10:07:27 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260612447.12.0.967395589488.issue7479@psf.upfronthosting.co.za>


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

If we do that, we would probably need to acknowledge that most functions
in the POSIX module are available only on some Unixes - namely all that
are listed in posix_methods with conditional compilation. That, in turn,
would be silly for things like getcwd where probably only minority
systems (e.g. embedded systems without file system) fail to support it.

I think the problem of this report really originates in the
unfamiliarity of the OP with Unix implementations other than Linux,
rather than in a flaw of the Python documentation.

----------

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

From report at bugs.python.org  Sat Dec 12 12:38:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Dec 2009 11:38:40 +0000
Subject: [issue7469] Design and History FAQ entry on Floating Point does not
	mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1260617920.44.0.99662961787.issue7469@psf.upfronthosting.co.za>


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

Is there anything actually *wrong* with that FAQ section?  I'm not sure 
how mentioning short float repr would address any particular FAQ.  Unless 
that FAQ is "why do 2.6 and 2.7 give different results?".

I agree that the tutorial section for trunk needs updating.

I also notice that the FAQs for py3k need to be looked at closely:  there 
are a lot of print statements in there, and doubtless some other 2.x-isms.

----------

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

From report at bugs.python.org  Sat Dec 12 13:16:37 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Dec 2009 12:16:37 +0000
Subject: [issue7485] Error in FAQ entry '4.25 Why doesn't Python have a "with"
	statement for attribute assignments?'
In-Reply-To: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
Message-ID: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

The documentation says: "If the referenced object does not have a, b and
c attributes, of course, the end result is still a run-time exception."

For the given example, this is likely not true. Since the attributes are
being assigned to, they will be created. The example is equivalent to:

>>> class a(object): pass
...
>>> ref = a()
>>> ref.a = 21
>>> ref.b = 42
>>> ref.c = 63

----------
assignee: georg.brandl
components: Documentation
messages: 96291
nosy: eric.smith, georg.brandl
severity: normal
status: open
title: Error in FAQ entry '4.25   Why doesn't Python have a "with" statement for attribute assignments?'
versions: Python 2.6

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

From report at bugs.python.org  Sat Dec 12 15:26:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Dec 2009 14:26:54 +0000
Subject: [issue7469] Design and History FAQ entry on Floating Point does not
	mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1260628014.99.0.958910068456.issue7469@psf.upfronthosting.co.za>


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

No, you are right, there's nothing actually inaccurate.  It might be
good for it to say, about repr, that it prints the "minimum number of
digits necessary", which is what is different from the old behavior. 
But I agree that it doesn't *have* to change.

----------

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

From report at bugs.python.org  Sat Dec 12 16:22:49 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 15:22:49 +0000
Subject: [issue7486] doc: Built-in Functions, exec statement is obsolete
In-Reply-To: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>
Message-ID: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

In the documentation of "compile(...)", there's a mention of the "exec
statement".

----------
assignee: georg.brandl
components: Documentation
messages: 96293
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: Built-in Functions, exec statement is obsolete
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Dec 12 16:24:18 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 15:24:18 +0000
Subject: [issue7486] doc: Built-in Functions, exec statement is obsolete
In-Reply-To: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>
Message-ID: <1260631458.76.0.644910459347.issue7486@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15531/issue7486_doc_py3k.diff

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

From report at bugs.python.org  Sat Dec 12 16:36:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Dec 2009 15:36:26 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1260632186.25.0.555610737717.issue7396@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, rebinding a variable to a different type is something that is
considered an acceptable pattern in Python programs, at least in certain
circumstances.  Python programs generally use 'duck typing', and a list
and an iterable have equivalent semantics for the purposes of (most of)
the regrtest code.

On the other hand, regrtest is in general *not* an example of good
Python code, and really ought to be cleaned up at some point.  In
particular, the code blocks in regrtest are simply huge, and this makes
changing it very error prone, with "what type is this variable" being
just one example of the coupling problems.

Attached is a patch against trunk.  Please confirm that this fixes the
problems you found.

----------
assignee:  -> r.david.murray
components: +Tests
keywords: +patch
stage:  -> patch review
versions:  -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15532/regrtest_single_issue7396.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:40:29 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 15:40:29 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260632429.18.0.94666723444.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Martin,

actually, I was trying to convert some piece of code from python2 to
python3. And this statement was not converted by 2to3:
  "x.decode('base64').decode('zlib')"

So, I read the official documentation, and found no hint about the
removal of these codecs.
For my specific use case, I can use "zlib.decompress" and
"base64.decodebytes", but I find that the ".encode()" and ".decode()"
helpers were useful in Python 2.

I don't know all the background of the removal of these codecs. But I
try to contribute to Python, and help Python 3 become at least as
featureful, and useful, as Python 2.

So, after reading the above comments, I think we may end up with
following changes:
 * restore the "bytes-to-bytes" codecs in the "encodings" package
 * then create new helpers on bytes objects (either
   ".transform()/.untransform()" or ".encodebytes()/.decodebytes")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:44:23 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 15:44:23 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1260632663.87.0.336746496608.issue7475@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

> And this statement was not converted

s/this statement/this method call/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:53:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Dec 2009 15:53:08 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260633188.63.0.292190348596.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In r64791, BaseException gained a new __unicode__ method that does the
> equivalent of the following things:

It remains to be seen why that behaviour was chosen. Apparently Nick
implemented it.
IMO __unicode__ should have the same behaviour as __str__. There's no
reason to implement two different formatting algorithms.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:57:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Dec 2009 15:57:04 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1260633424.1.0.989279539797.issue7484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree.  My reading of the rfc is that the form without the brackets
*must* be supported by the MTA, while any other form is optional.  So
smtplib should use the required form for its VRFY query.  Any MTA that
doesn't recognize that form would be broken.

2.5 is in security-fix-only mode, so this can only be fixed in 2.6 and
above.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
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/issue7484>
_______________________________________

From report at bugs.python.org  Sat Dec 12 18:56:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Dec 2009 17:56:43 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260640603.57.0.528445056422.issue7479@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps the top-level module description should just be clearer. Right
now it is not obvious that functions marked "availability: Unix" may
only be available on certain Unix flavours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7479>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:47:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Dec 2009 18:47:25 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1260643645.44.0.810600762557.issue5949@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch modified to skip ssl tests if ssl not available in r76727 in
trunk; that changeset included in all merges.  p3k merge in r76730 as
stated.  2.6 merge in r76761, using the 2.6 patch provided by Scott. 
3.1 merge in r76762.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:25:19 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 12 Dec 2009 19:25:19 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260632429.18.0.94666723444.issue7475@psf.upfronthosting.co.za>
Message-ID: <4B23EE1B.5070903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So, after reading the above comments, I think we may end up with
> following changes:
>  * restore the "bytes-to-bytes" codecs in the "encodings" package
>  * then create new helpers on bytes objects (either
>    ".transform()/.untransform()" or ".encodebytes()/.decodebytes")

I would still be opposed to such a change, and I think it needs a PEP.
If the codecs are restored, one half of them becomes available to
.encode/.decode methods, since the codec registry cannot tell which
ones implement real character encodings, and which ones are other
conversion methods. So adding them would be really confusing.

I also wonder why you are opposed to the import statement. My
recommendation is indeed that you use the official API for these
libraries (and indeed, there is an official API for each of them,
unlike real codecs, which don't have any other documented API).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:27:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Dec 2009 19:27:34 +0000
Subject: [issue7466] Segmentation fault with tuple + gc.collect()
In-Reply-To: <1260411670.47.0.11581679094.issue7466@psf.upfronthosting.co.za>
Message-ID: <1260646054.06.0.135639468001.issue7466@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7466>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:28:35 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Dec 2009 19:28:35 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1260646115.19.0.433461549086.issue7306@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Removing versions that this wouldn't apply to if it were accepted.

----------
versions: +Python 3.2 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7306>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:36:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Dec 2009 19:36:29 +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: <1260646589.94.0.941609480371.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against py3k.

----------
keywords: +needs review
Added file: http://bugs.python.org/file15533/timedlock3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7316>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:48:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Dec 2009 19:48:13 +0000
Subject: [issue7481] Failing to start a thread leaves "zombie" thread in
	"initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1260647293.39.0.422793051237.issue7481@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can reproduce it under Linux using "ulimit -Su 2600".
(deselecting 2.5 as it doesn't receive bug fixes anymore)

----------
nosy: +gps, jyasskin, pitrou
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7481>
_______________________________________

From report at bugs.python.org  Sat Dec 12 21:43:38 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 20:43:38 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Some code samples are not syntax colored in the doc for Python 3.
In the documentation for Python 2, it is OK.

Example:
  http://docs.python.org/dev/py3k/library/stdtypes.html#methods
  http://docs.python.org/dev/library/stdtypes.html#methods

----------
assignee: georg.brandl
components: Documentation
messages: 96306
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: Code is not always colored
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Sat Dec 12 21:46:35 2009
From: report at bugs.python.org (flox)
Date: Sat, 12 Dec 2009 20:46:35 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1260650795.58.0.530323401663.issue7487@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

The bug seems related to Sphynx on Python3.

These examples are NOT colored::

  class Z:
    def __init__(self):
      pass

::

  class F:
    def __foo__(self):
      pass

::

  class C:
      def method(self):
          pass

  c = C()
  c.method.__func__.whoami = 'my name is c'



While these examples are colored correctly::

  class A:
    pass

  class B:
    def b(self):
      pass

  class C(): pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Sat Dec 12 22:36:02 2009
From: report at bugs.python.org (Dror Levin)
Date: Sat, 12 Dec 2009 21:36:02 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1260653762.34.0.0531438281102.issue7247@psf.upfronthosting.co.za>


Changes by Dror Levin <spatz at psybear.com>:


----------
nosy: +spatz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7247>
_______________________________________

From report at bugs.python.org  Sat Dec 12 22:41:51 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sat, 12 Dec 2009 21:41:51 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1260654111.23.0.0607624503191.issue7402@psf.upfronthosting.co.za>


Christoph Zwerschke <cito at online.de> added the comment:

My point was that the passage starts with "there are also many useful
built-in functions people seem not to be aware of for some reasons" and
then it looks like the author himself was not aware of sum() for some
reason because he gives calculating a sum with reduce() as a "classical
example".

It's very hard to come up with good examples for reduce() and I think in
newer Python versions it has been demoted from builtin to functools, so
it's not a good example for a useful built-in fuction anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Sat Dec 12 23:57:35 2009
From: report at bugs.python.org (steve)
Date: Sat, 12 Dec 2009 22:57:35 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1260658655.0.0.527810507051.issue7479@psf.upfronthosting.co.za>


steve <eyebootleg at gmail.com> added the comment:

Thank you for you explanation of os.lchmod()

Adding a note to the documentation would be very useful.  I did search
the internet for an answer before posting the bug, and I was only able
to find forum posts of other people having the same issue.

Thank you again, peace;
Steve,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7479>
_______________________________________

From report at bugs.python.org  Sun Dec 13 01:32:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 00:32:47 +0000
Subject: [issue7486] doc: Built-in Functions, exec statement is obsolete
In-Reply-To: <1260631369.85.0.334138201017.issue7486@psf.upfronthosting.co.za>
Message-ID: <1260664367.29.0.052157183503.issue7486@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76771.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7486>
_______________________________________

From report at bugs.python.org  Sun Dec 13 01:57:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 00:57:37 +0000
Subject: [issue6654] Add "path" to the xmrlpc dispatcher method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1260665857.96.0.88021009873.issue6654@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Hi, Kristjan. Could you port your commit to py3?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Sun Dec 13 02:01:13 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 01:01:13 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1260666073.69.0.789324644231.issue7306@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You can use unittest.skipUnless instead of skipIf since you have a not
condition in all of them.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7306>
_______________________________________

From report at bugs.python.org  Sun Dec 13 02:09:46 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Dec 2009 01:09:46 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260666586.49.0.183979596221.issue6108@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Following this down the rabbit hole a little further: Issue #2517 (the
origin of my checkin) was just a restoration of the __unicode__ slot
implementation that had been ripped out in r51837 due to Issue #1551432.

At the time of the r64791 checkin, BaseException_str and
BaseException_unicode were identical aside from the type of object
returned (checking SVN head shows they're actually still identical).

However, it looks like several exceptions with __str__ overrides (i.e.
Unicode[Encode/Decode/Translate]Error_str, EnvironmentError_str,
WindowsError_str. SyntaxError_str, KeyError_str) are missing
corresponding __unicode__ overrides, so invoking unicode() on them falls
back to the BaseException_unicode implementation instead of using the
custom formatting behaviour of the subclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 02:20:39 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Dec 2009 01:20:39 +0000
Subject: [issue7402] reduce() is an anti-example in "Idioms and Anti-Idioms"
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1260667239.84.0.533339283538.issue7402@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Sun Dec 13 02:39:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 01:39:58 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260668398.25.0.948316318492.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> IMO __unicode__ should have the same behaviour as __str__. There's no
> reason to implement two different formatting algorithms.

If BaseException has both the methods they have to be both overridden by
derived exceptions in order to have the same behaviour. The simplest way
to do it is to convert the string returned by __str__ to unicode, as I
did in issue6108.diff.
If you have better suggestions let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 02:52:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Dec 2009 01:52:49 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260669169.58.0.725721630879.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well the obvious problem with this approach is that it won't work if
__str__() returns a non-ascii string. The only working solution would be
to replicate the functioning of __str__() in each __unicode__()
implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:10:49 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 13 Dec 2009 04:10:49 +0000
Subject: [issue7488] Mac/README continues to refer to 2.6, not 3
In-Reply-To: <1260677449.44.0.892649378192.issue7488@psf.upfronthosting.co.za>
Message-ID: <1260677449.44.0.892649378192.issue7488@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The file Mac/README in the Subversion source continues to refer to 2.6,
not the appropriate version of 3.

----------
components: Build
messages: 96316
nosy: MLModel
severity: normal
status: open
title: Mac/README continues to refer to 2.6, not 3
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7488>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:18:53 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 13 Dec 2009 04:18:53 +0000
Subject: [issue7489] OS X binary installer for 3.1.1 missing from
	http://www.python.org/download/
In-Reply-To: <1260677933.36.0.449137371401.issue7489@psf.upfronthosting.co.za>
Message-ID: <1260677933.36.0.449137371401.issue7489@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Is there some reason the OS X installer is missing from
http://www.python.org/download/ but present on
http://www.python.org/download/releases/3.1.1/? Seems it should be in
both places.

----------
components: None
messages: 96317
nosy: MLModel
severity: normal
status: open
title: OS X binary installer for 3.1.1 missing from http://www.python.org/download/
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7489>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:24:38 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Dec 2009 04:24:38 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260678278.88.0.678718023561.issue6108@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Antoine said, there's a reason BaseException now implements both
__str__ and __unicode__ and doesn't implement the latter in terms of the
former - it's the only way to consistently support Unicode arguments
that can't be encoded to an 8-bit ASCII string:

>>> str(Exception(u"\xc3\xa0"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-1: ordinal not in range(128)
>>> unicode(Exception(u"\xc3\xa0"))
u'\xc3\xa0'

For some of the exception subclasses that will always return ASCII (e.g.
KeyError, which calls repr() on its arguments) then defining __unicode__
in terms of __str__ as Ezio suggests will work.

For others (as happened with BaseException itself), the __unicode__
method will need to be a reimplementation that avoids trying to encode
potentially non-ASCII characters into an 8-bit ASCII string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:39:33 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 04:39:33 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260679173.62.0.287947366267.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What you said is only a special case, and I agree that the solution
introduced with r64791 is correct for that. However, that fix has the
side effect of breaking the code in other situations.


To summarize the possible cases and the behaviours I prepared the
following list (odd numbers -> BaseException; even numbers -> any
exception with overridden __str__ and no __unicode__.):
1) 0 args, e = Exception():
   py2.5  : str(e) -> ''; unicode(e) -> u''
   py2.6  : str(e) -> ''; unicode(e) -> u''
   desired: str(e) -> ''; unicode(e) -> u''
Note: this is OK

2) 0 args, e = MyException(), with overridden __str__:
   py2.5  : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
   py2.6  : str(e) -> 'ascii' or error; unicode(e) -> u''
   desired: str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
Note: py2.5 behaviour is better: if __str__ returns an ascii string
(including ''), unicode(e) should return the same string decoded, if
__str__ returns a non-ascii string, both should raise an error.

3a) 1 str arg, e = Exception('foo'):
   py2.5  : str(e) -> 'foo'; unicode(e) -> u'foo'
   py2.6  : str(e) -> 'foo'; unicode(e) -> u'foo'
   desired: str(e) -> 'foo'; unicode(e) -> u'foo'
Note: this is OK

3b) 1 non-ascii unicode arg, e = Exception(u'f??'):
   py2.5  : str(e) -> error; unicode(e) -> error
   py2.6  : str(e) -> error; unicode(e) -> u'f??'
   desired: str(e) -> error; unicode(e) -> u'f??'
Note: py2.6 behaviour is better: unicode(e) should return u'f??'

4) 1 unicode arg, e = MyException(u'f??'), with overridden __str__:
   py2.5  : str(e) -> error or 'ascii'; unicode(e) -> error or u'ascii'
   py2.6  : str(e) -> error or 'ascii'; unicode(e) -> u'f??'
   desired: str(e) -> error or 'ascii'; unicode(e) -> error or u'ascii'
Note: py2.5 behaviour is better: if __str__ returns an ascii string
str(e) should work, otherwise it should raise an error. unicode(e)
should return the ascii string decoded or an error, not the arg.

5) >1 args of any type, e = Exception('foo', u'f??', 5):
   py2.5  : str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
   py2.6  : str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
   desired: str(e) ->  "('foo', u'f\\xf6\\xf6', 5)";
        unicode(e) -> u"('foo', u'f\\xf6\\xf6', 5)";
Note: this is OK

6) >1 args of any type, e = MyException('foo', u'f??', 5), with
overridden __str__:
   py2.5  : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
   py2.6  : str(e) -> 'ascii' or error; unicode(e) -> u"('foo',
u'f\\xf6\\xf6', 5)";
   desired: str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
Note: py2.5 behaviour is better: if __str__ returns an ascii string,
unicode(e) should return the same string decoded, if __str__ returns a
non-ascii string, both should raise an error.

As you can see, your example corresponds just to the case 3b) (now
fixed), but cases 2, 4, 6 are now broken.

Making this list allowed me to come out with a new patch, that seems to
solve all the problems (2, 4 and 6 while leaving 3b as it is now). The
only exception is for KeyError, if we want it to print the repr, then
KeyError_unicode should be implemented, but I think that Python only
calls str() so it's probably not necessary.

Attached new patch that passes all the tests in issue6108_testcase
except for KeyError. Unless you disagree with the 'desired behaviours'
that I listed, this patch should fix the issue.

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15534/issue6108-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:43:56 2009
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio?=)
Date: Sun, 13 Dec 2009 04:43:56 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1260679436.85.0.367133572118.issue3932@psf.upfronthosting.co.za>


S?rgio <sergio at sergiomb.no-ip.org> added the comment:

the patch fix parsing in simple tag a with title with <br> ?! and
accents like this:

 <a href="8999.html" title="<br>pa?s">

----------
nosy: +sergiomb2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:44:58 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 13 Dec 2009 04:44:58 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260679498.42.0.999819512442.issue6108@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

"2) 0 args, e = MyException(), with overridden __str__:
   py2.5  : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
   py2.6  : str(e) -> 'ascii' or error; unicode(e) -> u''
   desired: str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
Note: py2.5 behaviour is better: if __str__ returns an ascii string
(including ''), unicode(e) should return the same string decoded, if
__str__ returns a non-ascii string, both should raise an error.
"

I'm not sure how you justify raising an unnecessary error when trying to
stringify an exception as being 'better'.

__str__ should not decode its arguments if they are already strings:
they may be valid data for the user even if they are not decodable (and
note that an implicit decode may try to decode('ascii') which is totally
useless.

__str__ and __unicode__ are /different/ things, claiming they have to
behave the same is equivalent to claiming either that we don't need
unicode, or that we don't need binary data.

Surely there is space for both things, which does imply that
unicode(str(e)) != unicode(e).

Why _should_ that be the same anyway?

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:49:14 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Dec 2009 04:49:14 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260679754.74.0.0480987426919.issue6108@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree the 2.6 implementation creates backwards compatibility problems
with subclasses that only override __str__ that we didn't recognise at
the time.

An alternative approach that should work even for the KeyError case is
for BaseException_unicode to check explicitly for the situation where
the __str__ slot has been overridden but __unicode__ is still the
BaseException version and invoke "PyObject_Unicode(PyObject_Str(self))"
when it detects that situation.

That way subclasses that only override __str__ would continue to see the
old behaviour, while subclasses that don't override either would
continue to benefit from the new behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:51:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 04:51:44 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260679904.08.0.251337196474.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Assume the case of e = MyException() (note: 0 args) with a __str__ that
returns a default message. Now, if the message is ascii, str(e) works
and the user see the default message but unicode(e) returns a
not-so-useful empty string.
On the other hand, if __str__ returns a non-ascii string, then it's
wrong in the first place, because str(e) will fail and returning an
empty string with unicode(e) is not going to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 05:56:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 04:56:45 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260680205.95.0.226785360556.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> An alternative approach that should work even for the KeyError case is
> for BaseException_unicode to check explicitly for the situation where
> the __str__ slot has been overridden but __unicode__ is still the
> BaseException version and invoke "PyObject_Unicode(PyObject_Str(self))"
> when it detects that situation.

This is even better, I'll try to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 07:01:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 06:01:56 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260684116.84.0.591665886631.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a new patch (issue6108-3.patch) that checks if __str__ has been
overridden and calls PyObject_Unicode(PyObject_Str(self)).

All the tests (including the one with KeyError) in
issue6108_testcase.diff now pass.

If the patch is OK I'll make sure that the tests cover all the possible
cases that I listed and possibly add a few more before the commit.

----------
Added file: http://bugs.python.org/file15535/issue6108-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 10:38:57 2009
From: report at bugs.python.org (Nir)
Date: Sun, 13 Dec 2009 09:38:57 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260697137.98.0.871265257089.issue7471@psf.upfronthosting.co.za>


Nir <nir at winpdb.org> added the comment:

First patch, please forgive long comment :)

I submit a small patch which speeds up readline() on my data set - a 
74MB (5MB .gz) log file with 600K lines.

The speedup is 350%.

Source of slowness is that (~20KB) extrabuf is allocated/deallocated in 
read() and _unread() with each call to readline().

In the patch read() returns a slice from extrabuf and defers 
manipulation of extrabuf to _read().

In the following, the first timeit() corresponds to reading extrabuf 
slices while the second timeit() corresponds to read() and _unread() as 
they are done today:

>>> timeit.Timer("x[10000: 10100]", "x = 'x' * 20000").timeit()
0.25299811363220215

>>> timeit.Timer("x[: 100]; x[100:]; x[100:] + x[: 100]", "x = 'x' * 
10000").timeit()
5.843876838684082

Another speedup is achieved by doing a small shortcut in readline() for 
the typical case in which the entire line is already in extrabuf.

The patch only addresses the typical case of calling readline() with no 
arguments. It does not address other problems in readline() logic. In 
particular the current 512 chunk size is not a sweet spot. Regardless of 
the size argument passed to readline(), read() will continue to 
decompress just 1024 bytes with each call as the size of extrabuf swings 
around the target size argument as result of the interaction between 
_unread() and read().

----------
keywords: +patch
nosy: +nirai
Added file: http://bugs.python.org/file15536/gzip_7471_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sun Dec 13 10:40:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Dec 2009 09:40:35 +0000
Subject: [issue7489] OS X binary installer for 3.1.1 missing from
	http://www.python.org/download/
In-Reply-To: <1260677933.36.0.449137371401.issue7489@psf.upfronthosting.co.za>
Message-ID: <1260697235.73.0.0223223723286.issue7489@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report; this is now fixed.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7489>
_______________________________________

From report at bugs.python.org  Sun Dec 13 12:03:37 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 13 Dec 2009 11:03:37 +0000
Subject: [issue1123727] gensuitemodule.processfile fails
Message-ID: <1260702217.62.0.756728877737.issue1123727@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This issue is for deprecated Carbon module that has a well-maintained 
alternative outside of the stdlib.

----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1123727>
_______________________________________

From report at bugs.python.org  Sun Dec 13 12:11:42 2009
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 13 Dec 2009 11:11:42 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

In Python 3.x [1] the exception formatting prints the module path, while
under 2.x it prints only the exception class name. This makes it very
tricky to make doctests that pass under both Python 2 and Python 3
without resorting to ugly tricks.

Since IGNORE_EXCEPTION_DETAIL was implemented to hide differences
between exception messages in 2.3 and 2.4, it was suggested on
python-dev [2] that IGNORE_EXCEPTION_DETAIL should be extended to also
ignore the module name, so that `module.name.ExceptionClass` and
`ExceptionClass` would match each other. This is easily done by just
changing the regexp that is done for matching.

I'll attach diffs both for trunk and for py3k-branch, so that both forms
can be used on both versions. The diffs include tests and suggested
documentation changes (although I reserve the right to be useless at
writing documentation).



[1] And possibly in some cases under Python 2.7 according to reports in
the thread on python-dev about this issue, although I haven't been able
to confirm this. I'll include a 2.7 diff anyway, as it would be good if
both syntaxes work under both versions, if people start using 3to2, for
example.

[2] http://mail.python.org/pipermail/python-dev/2009-December/094460.html

----------
components: Tests
files: python-py3k-exception-detail.diff
keywords: patch
messages: 96329
nosy: lregebro
severity: normal
status: open
title: IGNORE_EXCEPTION_DETAIL should ignore the module name
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Sun Dec 13 12:12:13 2009
From: report at bugs.python.org (Lennart Regebro)
Date: Sun, 13 Dec 2009 11:12:13 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260702733.29.0.968347989041.issue7490@psf.upfronthosting.co.za>


Changes by Lennart Regebro <regebro at gmail.com>:


Added file: http://bugs.python.org/file15538/python-trunk-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Sun Dec 13 12:50:07 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 13 Dec 2009 11:50:07 +0000
Subject: [issue7357] tarfile doesn't detect disk full error on extraction
In-Reply-To: <1258644088.41.0.896427627172.issue7357@psf.upfronthosting.co.za>
Message-ID: <1260705007.68.0.502550485861.issue7357@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I changed the default value for the errorlevel argument, so that fatal
errors are now raised as regular exceptions by default (trunk: r76780,
py3k: r76782). Thank you very much for bringing up this issue.

----------
resolution:  -> accepted
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7357>
_______________________________________

From report at bugs.python.org  Sun Dec 13 13:52:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Dec 2009 12:52:53 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1260708773.37.0.817729488004.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should check the return value from PyObject_Str().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 13 13:53:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Dec 2009 12:53:48 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260708828.34.0.963757970672.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

nirinA: thanks for the erf patch.  It's fine as far as it goes;  the main 
technical issue is that the series development only converges at a 
sensible rate for smallish x;  for larger x something more is needed.

Here's a prototype patch for the erf and erfc functions that uses a power 
series (not quite the same as the series nirinA used;  by pulling out a 
factor of exp(-x*2) you can make all coefficients in the remaining series 
positive, which is good for the numerics) for small x, and a continued 
fraction expansion for larger x.   The erf and erfc functions are 
currently written in Python.  I'll do some more testing (and possibly 
tweaking) of this patch and then translate the Python to C.

----------
Added file: http://bugs.python.org/file15539/erf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sun Dec 13 15:24:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 14:24:04 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260714244.1.0.0179011135045.issue7490@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> high
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Sun Dec 13 15:38:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Dec 2009 14:38:00 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260715080.9.0.41898476313.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the C version.

----------
Added file: http://bugs.python.org/file15540/erf_c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sun Dec 13 16:58:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Dec 2009 15:58:47 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Here's an example of a metaclass with a __cmp__ special:

    exarkun at boson:/tmp$ cat metacmp.py
    class X(type):
        def __cmp__(self, other):
            return -1

    class Y:
        __metaclass__ = X

    print Y < Y
    exarkun at boson:/tmp$ python2.5 metacmp.py
    True
    exarkun at boson:/tmp$ python2.6 metacmp.py
    False
    exarkun at boson:/tmp$

In Python 2.6 and Python 2.7a1, the __cmp__ isn't even invoked, as it
was in Python 2.5.

This breaks the ordering of item types in Axiom.  A brief search reveals
that sympy also ran into the problem, but they may have since worked
around it.

----------
components: Interpreter Core
messages: 96334
nosy: exarkun
severity: normal
status: open
title: metaclass __cmp__ is ignored
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:01:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Dec 2009 16:01:38 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260720098.28.0.848406382382.issue7491@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Apparently type has __lt__ and the other rich cmp specials in Python
2.6, but lacked them in Python 2.5.  I suppose these are probably being
given precedence over the overridden __cmp__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:05:12 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 13 Dec 2009 16:05:12 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260720312.27.0.840060190993.issue7491@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It seems that type was switched to use tp_richcompare in r61529:

Add py3k warnings for object, type, cell and dict comparisons. This
should resolve issue2342 and partly resolve issue2373.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:37:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 16:37:11 +0000
Subject: [issue7056] regrtest runtest_inner calls findtestdir unnecessarily
In-Reply-To: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
Message-ID: <1260722231.44.0.540292032153.issue7056@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7056>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:37:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 16:37:18 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260722238.31.0.268764535419.issue7491@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76794.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:24:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 17:24:28 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1260725068.1.0.075037660792.issue6499@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ezio, the original problem this ticket was opened for appears to be
solved, so I'm going to close it.  If you still want to work on the
thread exception issue, please open a new ticket referencing this one.

----------
nosy: +r.david.murray
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/issue6499>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:30:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 17:30:14 +0000
Subject: [issue7348] StringIO.StringIO.readline(-1) returns the wrong result
	compared to other file-like objects
In-Reply-To: <1258570716.97.0.757460234956.issue7348@psf.upfronthosting.co.za>
Message-ID: <1260725414.08.0.518914102362.issue7348@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76798.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7348>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:57:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 17:57:42 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1260727062.71.0.0703172788617.issue6382@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

NB: this issue was triggered by the issue 6267 patch.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:59:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 17:59:40 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1260727180.53.0.482922575111.issue6381@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

NB: this issue was caused by the issue 6267 patch.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:04:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 18:04:05 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1260727445.23.0.57785241878.issue6267@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:07:54 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 18:07:54 +0000
Subject: [issue7492] doc: cPickle is really gone
In-Reply-To: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>
Message-ID: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Word "cPickle" is still used on these pages.

http://docs.python.org/dev/py3k/library/shelve.html
http://docs.python.org/dev/py3k/library/copyreg.html

----------
assignee: georg.brandl
components: Documentation
messages: 96342
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: cPickle is really gone
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7492>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:09:08 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 18:09:08 +0000
Subject: [issue7492] doc: cPickle is really gone
In-Reply-To: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>
Message-ID: <1260727748.38.0.466635484859.issue7492@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15541/issue7492_cpickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7492>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:11:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Dec 2009 18:11:59 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1260727919.81.0.356472422933.issue5596@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:21:27 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 13 Dec 2009 18:21:27 +0000
Subject: [issue6654] Add "path" to the xmrlpc dispatcher method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1260728487.6.0.0887646355446.issue6654@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

yes, I'll do so as soon as I'm able.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:02:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 19:02:37 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1260730957.45.0.879639309187.issue7342@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Committed in r76804. Leaving it open until I port this to 2.6 and 3.x.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:05:20 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 19:05:20 +0000
Subject: [issue7493] doc: patch for py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I reviewed the documentation and tested the examples with Python 3.

I found many parts which are changed or irrelevant.
Here is the patch.

----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_design.diff
keywords: patch
messages: 96345
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/design.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15542/py3k_doc_faq_design.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:05:42 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Dec 2009 19:05:42 +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: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

clearEntries() delete all nodes of the profiler tree, but 
currentProfilerContext keeps a reference to a tree node 
(currentProfilerContext->previous->header attribute).

The patch fixes clearEntries() to delete all references (destroy 
currentProfilerContext and set it to NULL).

----------
components: Extension Modules
files: _lsprof.patch
keywords: patch
messages: 96346
nosy: haypo
severity: normal
status: open
title: _lsprof (cProfile): Profiler.clear() keeps references to detroyed nodes
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file15543/_lsprof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:11:31 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Dec 2009 19:11:31 +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: <1260731491.61.0.262120607262.issue7494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The crash is an Heisenbug (read object which just has been destroyed, 
sometimes it works, sometimes it crash), so it's not easy the write a 
short example showing the crash.

The code looks like:

   import cProfile
   prof = cProfile.Profile()
   prof.enable()
   prof.clear()

The next instruction will be analyzed by the profiler, but the profiler 
will crash in: ptrace_enter_call()->initContext()->getSubEntry()-
>Rotating_Tree_Get(&caller->calls, entry), because caller->calls node is 
invalid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:15:40 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Dec 2009 19:15:40 +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: <1260731740.75.0.561475949996.issue7494@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #3952.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7494>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:18:27 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 19:18:27 +0000
Subject: [issue7495] doc: patch for py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I reviewed the documentation and tested the examples with Python 3.

I found some parts which are changed or irrelevant.
Here is the patch.

The examples for Mandelbrot and Fibonacci work fine.

----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_programming.diff
keywords: patch
messages: 96349
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/programming.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15544/py3k_doc_faq_programming.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:19:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 19:19:38 +0000
Subject: [issue7493] doc: patch for py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1260731978.81.0.899334796124.issue7493@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/issue7493>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:19:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 19:19:54 +0000
Subject: [issue7349] StringIO.StringIO, io.BytesIO,
	and io.StringIO accept None in places where other file-like objects
	don't
In-Reply-To: <1258570914.64.0.211682819163.issue7349@psf.upfronthosting.co.za>
Message-ID: <1260731994.76.0.483324981402.issue7349@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76805. I think I got all the cases...

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7349>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:20:09 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 19:20:09 +0000
Subject: [issue7495] doc: patch for py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1260732009.7.0.0830241220428.issue7495@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/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:21:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 19:21:26 +0000
Subject: [issue7495] doc: patch for py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1260732086.87.0.587168052233.issue7495@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/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 13 20:21:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Dec 2009 19:21:45 +0000
Subject: [issue7493] doc: patch for py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1260732105.01.0.457237615981.issue7493@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/issue7493>
_______________________________________

From report at bugs.python.org  Sun Dec 13 21:35:47 2009
From: report at bugs.python.org (mohammad)
Date: Sun, 13 Dec 2009 20:35:47 +0000
Subject: [issue7496] python does not  work in command prompt
In-Reply-To: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
Message-ID: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>


New submission from mohammad <mohammad.madani63 at gmail.com>:

when i type python in my command promp this message is shown :

C:\Documents and Settings\X>python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

what's the problem ?!

----------
components: Windows
messages: 96351
nosy: memol_jpn
severity: normal
status: open
title: python does not  work in command prompt
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7496>
_______________________________________

From report at bugs.python.org  Sun Dec 13 21:53:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 20:53:15 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, on linux causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

autoconf tries to open a semaphore (/autoconf) to find out if posix
semaphores are available and working.  On linux, a file 'sem.autoconf'
is left behind in /dev/shm, owned by the user running autoconf.  If any
other user on the system compiles python, the autoconf tests will fail
to open this file (which is rw to the owner only), and the resulting
python will claim that the system has a broken semaphore implementation.

----------
components: Interpreter Core
keywords: easy
messages: 96352
nosy: mark.dickinson, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: configure test for posix_semaphore capability leaves semaphore behind, on linux causing test to fail for other users
type: compile error
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:01:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 21:01:06 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, on linux causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260738066.42.0.684479779583.issue7497@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

According to the linux man page, to delete the named semaphore after all
processes are done with it one must call sem_unlink on it.  So an unlink
call should be added to both autoconf tests that use sem_open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:01:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 21:01:52 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260738112.84.0.393389034015.issue7497@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: configure test for posix_semaphore capability leaves semaphore behind, on linux causing test to fail for other users -> configure test for posix_semaphore capability leaves semaphore behind, causing test to fail for other users

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:04:35 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 21:04:35 +0000
Subject: [issue7492] doc: cPickle is really gone
In-Reply-To: <1260727673.98.0.893225016776.issue7492@psf.upfronthosting.co.za>
Message-ID: <1260738275.71.0.652087228067.issue7492@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76812.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7492>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:16:28 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Dec 2009 21:16:28 +0000
Subject: [issue7488] Mac/README continues to refer to 2.6, not 3
In-Reply-To: <1260677449.44.0.892649378192.issue7488@psf.upfronthosting.co.za>
Message-ID: <1260738988.08.0.201621575309.issue7488@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in py3k in r76820 by replacing 2.6 references in paths to <VERSION>. 
Not bothering to backport since this is such a minor thing.

----------
nosy: +brett.cannon
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7488>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:21:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Dec 2009 21:21:32 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260739292.05.0.714500335509.issue7497@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've added the calls to sem_unlink in r76813 (trunk), r76815 (py3k) and 
r76821 (release31-maint).  I also changed the name of the semaphore for 
the second sem_open, so that we can tell which test is leaving files 
behind if it happens again in the future.

David, could you check whether this fixes the problem on linux?

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:21:47 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Dec 2009 21:21:47 +0000
Subject: [issue7496] python does not  work in command prompt
In-Reply-To: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
Message-ID: <1260739307.42.0.755878881337.issue7496@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Your OS is using an encoding called cp720 which Python knows nothing 
about. That means it can't open stdout, stderr, or stdin properly for 
reading/writing according to your set codec. You need to use a codec 
recognized by Python or add support for your codec to allow it to run.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7496>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:22:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 21:22:15 +0000
Subject: [issue7498] test_multiprocessing test_rapid_restart fails if port
	9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

test_rapid_restart has a hardcoded port.  Patch updates it to use
test_support.find_unused_port.  Discovered on a buildbot with a hung
test_multiprocessing run and confirmed to fix the subsequent failures of
other test_multiprocessing runs.

----------
components: Tests
files: test_multiprocessing_find_unused_port.patch
keywords: buildbot, patch
messages: 96358
nosy: jnoller, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing test_rapid_restart fails if port 9999 already in use
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15545/test_multiprocessing_find_unused_port.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7498>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:41:24 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 21:41:24 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I reviewed the documentation and tested the examples with Python 3.

I found some import and print statements to change.
Here is the patch.

Note: I added a warning for the question "How do I get a single
keypress" (without curses). The solution may not work as expected.

----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_library.diff
keywords: patch
messages: 96359
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: patch for py3k/Doc/faq/library.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15546/py3k_doc_faq_library.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Sun Dec 13 22:52:47 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 21:52:47 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

I reviewed some FAQ documents: issue7493, issue7495 and issue7499

But other documents may be inaccurate.
We may add a warning at the top of these documents, until someone
volunteer to review them.

Patch attached.

----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_faq_warnings.diff
keywords: patch
messages: 96360
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: add warnings for FAQ which may not be accurate
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15547/py3k_doc_faq_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7500>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:14:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Dec 2009 22:14:11 +0000
Subject: [issue7496] python does not  work in command prompt
In-Reply-To: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
Message-ID: <1260742451.62.0.544631172094.issue7496@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

See #1616979.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7496>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:16:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 22:16:25 +0000
Subject: [issue7496] python does not  work in command prompt
In-Reply-To: <1260736547.88.0.745783181187.issue7496@psf.upfronthosting.co.za>
Message-ID: <1260742585.9.0.0217738811231.issue7496@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As Benjamin points out, this is a duplicate of issue 1616979, which has
been fixed in both trunk and py3k.  For future reference, Mohammad, a
search with the string 'cp720' and 'status' set to 'don't care' would
have brought up that bug report.  The tracker's default of searching
only open bugs can be misleading if you don't notice it.

----------
nosy: +r.david.murray
priority:  -> normal
resolution: invalid -> duplicate
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7496>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:19:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 22:19:16 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260742756.73.0.100795388076.issue7497@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it does.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:19:52 2009
From: report at bugs.python.org (Robert Collins)
Date: Sun, 13 Dec 2009 22:19:52 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

:!python -m unittest foo.test_suite  
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.6/unittest.py", line 875, in <module>
    main(module=None)
  File "/usr/lib/python2.6/unittest.py", line 816, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.6/unittest.py", line 843, in parseArgs
    self.createTests()
  File "/usr/lib/python2.6/unittest.py", line 849, in createTests
    self.module)
  File "/usr/lib/python2.6/unittest.py", line 613, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.6/unittest.py", line 605, in loadTestsFromName
    (obj, test))
TypeError: calling <function test_suite at 0x7f748dd6d7d0> returned
<unittest.TestSuite tests=[<foo.TestTask testMethod=test_can_construct>,
<foo.TestTask testMethod=test_can_construct>]>, not a test


where foo.py:
def test_suite():
    loader = unittest.TestLoader()
    tests = loader.loadTestsFromName(__name__)
    result = loader.suiteClass()
    result.addTests(generate_scenarios(tests))
    return result

----------
components: Library (Lib)
messages: 96364
nosy: rbcollins
severity: normal
status: open
title: python -m unittest path_to_suite_function errors
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7501>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:23:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2009 22:23:05 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1260742985.6.0.219084432964.issue7501@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord
priority:  -> normal
type: crash -> behavior
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7501>
_______________________________________

From report at bugs.python.org  Sun Dec 13 23:23:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Dec 2009 22:23:24 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1260743004.16.0.120309960922.issue7497@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, David!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:13:29 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:13:29 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260746009.39.0.416142609653.issue7500@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15547/py3k_doc_faq_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7500>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:14:00 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:14:00 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260746040.58.0.232610701885.issue7500@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15548/py3k_doc_faq_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7500>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:27:52 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Dec 2009 23:27:52 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260746872.56.0.152267465134.issue7490@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/issue7490>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:29:11 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 13 Dec 2009 23:29:11 +0000
Subject: [issue7498] test_multiprocessing test_rapid_restart fails if port
	9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1260746951.08.0.551714580305.issue7498@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7498>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:33:52 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Dec 2009 23:33:52 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260747232.54.0.254372496198.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The only design level question I can see is as follows:

ExceptionName matches ExceptionName (always)
a.b.ExceptionName matches ExceptionName (under IGNORE_EXCEPTION_DETAIL)
ExceptionName matches a.b.ExceptionName (under IGNORE_EXCEPTION_DETAIL)
a.b.ExceptionName matches x.y.ExceptionName (???)

Should that 4th case still match under IGNORE_EXCEPTION_DETAIL? My
personal inclination is that it should match, but figured the point was
worth discussing explicitly.

The main reason I think it should match is that it would allow
reasonably graceful handling of module renames between 2.x and 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:43:55 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:43:55 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260747835.48.0.231896279131.issue7499@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15549/py3k_doc_faq_library.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:44:02 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:44:02 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260747842.16.0.654572940392.issue7499@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15546/py3k_doc_faq_library.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:52:13 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:52:13 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260748333.85.0.270202019055.issue7499@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15549/py3k_doc_faq_library.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:52:50 2009
From: report at bugs.python.org (flox)
Date: Sun, 13 Dec 2009 23:52:50 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260748370.89.0.464209731948.issue7499@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15550/py3k_doc_faq_library.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Mon Dec 14 02:30:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 01:30:16 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260754216.48.0.863948803136.issue7490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My impression is that IGNORE_EXCEPTION_DETAIL is designed to allow you
to have a doctest as an example with a fully typed out exception detail,
but have it pass even if the exception detail changes.  If that is
indeed the original design, then I think your case 4 should pass.]

The one argument against it that I can see is the hypothetical case of
an x.y.Error passing when the code actually raised an a.b.Error when a
rename is *not* involved.  But that seems like a marginal enough case
that we could just ignore it.  Especially since having case 4 pass makes
the behavior of the modified IGNORE_EXCEPTION_DETAIL more consistent.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:23:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Dec 2009 02:23:38 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Consider this example, based on two doctests from Twisted:

  from doctest import DocTestSuite
  import twisted.web2.stream
  docTestOne = DocTestSuite(twisted.web2.stream)._tests[0]
  import twisted.web2.test.test_stream
  docTestTwo = DocTestSuite(twisted.web2.test.test_stream)._tests[0]
  print docTestOne.id(), '==', docTestTwo.id(), '?'
  print docTestOne == docTestTwo

One might reasonably expect a false result, since the two DocTestCase
instances represent two different doctests.  One will meet with
surprise, though.

----------
components: Library (Lib)
messages: 96368
nosy: exarkun
severity: normal
status: open
title: All DocTestCase instances compare and hash equal to each other
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:46:54 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Dec 2009 02:46:54 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260758814.86.0.616159200331.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed - particularly since that corner case can still be tested through
doctest if desired by using ELLIPSIS instead of IGNORE_EXCEPTION_DETAIL.

The patches mostly look good, but the doc changes should be updated to
indicate that using ELLIPSIS doesn't handle the case of mismatched
module names.

E.g. """Note that :const:`ELLIPSIS` can also be used to ignore the
details of the exception message, but such a test may still fail based
on whether or not the module details are printed as part of the
exception name. Using :const:`IGNORE_EXCEPTION_DETAIL` is also the only
clear way to write a doctest that doesn't care about the exception
detail yet continues to pass under Python releases prior to 2.4 (doctest
directives appear to be comments to them)."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:05:24 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Mon, 14 Dec 2009 04:05:24 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1260763524.9.0.785275868093.issue6902@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +falsetru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:16:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Dec 2009 05:16:05 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1260767765.29.0.735505404663.issue6902@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:16:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Dec 2009 05:16:50 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1260767810.43.0.664975041002.issue7499@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/issue7499>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:17:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Dec 2009 05:17:37 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260767857.84.0.598365659725.issue7500@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/issue7500>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:17:46 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Dec 2009 05:17:46 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1260767866.34.0.209278576398.issue7500@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/issue7500>
_______________________________________

From report at bugs.python.org  Mon Dec 14 07:27:15 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Dec 2009 06:27:15 +0000
Subject: [issue7388] Documentation: capitalizations of the word 'python'
	needed when used as a name
In-Reply-To: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
Message-ID: <1260772035.03.0.699470844504.issue7388@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/issue7388>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:33:18 2009
From: report at bugs.python.org (Lennart Regebro)
Date: Mon, 14 Dec 2009 07:33:18 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260775998.8.0.680359841367.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

Yes, x.y.Exception and a.b.Exception should match. I just realized I
didn't add an explicit test for that, but maybe that's not strictly
necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:53:54 2009
From: report at bugs.python.org (Pete Hunt)
Date: Mon, 14 Dec 2009 07:53:54 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>


New submission from Pete Hunt <floydophone at gmail.com>:

When pickling a proxy object (such as a list) created on a client, an 
exception is thrown. Example attached.

Python 2.6.4 Mac OS X 10.6

p

----------
components: Library (Lib)
files: multiprocessing_bug.py
messages: 96371
nosy: peterhunt
severity: normal
status: open
title: multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy
versions: Python 2.6
Added file: http://bugs.python.org/file15551/multiprocessing_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:04:09 2009
From: report at bugs.python.org (Pete Hunt)
Date: Mon, 14 Dec 2009 08:04:09 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1260777849.22.0.0270855963589.issue7503@psf.upfronthosting.co.za>


Pete Hunt <floydophone at gmail.com> added the comment:

UPDATE: this example WORKS if you remove "authkey" - so it seems to be a 
problem with authentication.

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:27:49 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 08:27:49 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260779269.39.0.804718149734.issue6472@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Small update of the patch for 3.2: the __cmp__method is replaced with
__eq__ method (on CommentProxy and PIProxy).

----------
Added file: http://bugs.python.org/file15552/issue6472_upstream_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:28:11 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 08:28:11 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260779291.25.0.909409888893.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15471/issue6472_upstream_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:43:15 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 08:43:15 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260780195.01.0.337970902458.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15513/issue6472_upstream_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:44:14 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 08:44:14 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1260780254.71.0.531408693477.issue6472@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15553/issue6472_upstream_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Mon Dec 14 10:41:04 2009
From: report at bugs.python.org (Laszlo (Laca) Peter)
Date: Mon, 14 Dec 2009 09:41:04 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260783664.58.0.779328240768.issue1975@psf.upfronthosting.co.za>


Changes by Laszlo (Laca) Peter <laca at sun.com>:


----------
nosy: +laca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 11:30:12 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Dec 2009 10:30:12 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <4B23EE1B.5070903@v.loewis.de>
Message-ID: <4B2613AE.2000007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> So, after reading the above comments, I think we may end up with
>> following changes:
>>  * restore the "bytes-to-bytes" codecs in the "encodings" package

+1

>>  * then create new helpers on bytes objects (either
>>    ".transform()/.untransform()" or ".encodebytes()/.decodebytes")

+1 - the names are still up for debate, IIRC.

> I would still be opposed to such a change, and I think it needs a PEP.

All this has already been discussed and the only reason it didn't
go in earlier was timing. No need for a PEP.

> If the codecs are restored, one half of them becomes available to
> .encode/.decode methods, since the codec registry cannot tell which
> ones implement real character encodings, and which ones are other
> conversion methods. So adding them would be really confusing.

Not at all. The helper methods check the return types and raise an
exception if the types don't match the expected types.

The codecs registry itself doesn't need to know about the possible
input/output types of codecs, since this information is not
required to match a name to an implementation.

What we could do, is add that information to the CodecInfo object
used for registering the codec. codecs.lookup() would then
return the information to the application.

E.g.

.encode_input_types = (str,)
.encode_output_types = (bytes,)
.decode_input_types = (bytes,)
.decode_output_types = (str,)

Codecs not supporting these CodecInfo attributes would simply
return None.

> I also wonder why you are opposed to the import statement. My
> recommendation is indeed that you use the official API for these
> libraries (and indeed, there is an official API for each of them,
> unlike real codecs, which don't have any other documented API).

That's not the point. The codec API provides a standardized API for
all these encodings. The hex, zlib, bz2, etc. codecs are just
adapters of the different pre-existing APIs to the codec API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:41:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 12:41:22 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1260794482.96.0.638394619128.issue7503@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:42:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 12:42:14 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1260794534.01.0.78260708271.issue7503@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Mon Dec 14 14:54:29 2009
From: report at bugs.python.org (Andrey Chichak)
Date: Mon, 14 Dec 2009 13:54:29 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>


New submission from Andrey Chichak <chch at kit.tomsk.ru>:

After setting cookies with same name and different path only nearest to 
root cookie is available.

Attached patch:
1. Set Cookie to nearest value.
2. Collects all same name values in Cookie._multi['<cookie name>'] in 
order.

----------
components: Library (Lib)
files: Cookie.py.diff
keywords: patch
messages: 96375
nosy: chch
severity: normal
status: open
title: Same name cookies
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15554/Cookie.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Mon Dec 14 14:55:33 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 13:55:33 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260798933.18.0.486545086847.issue4757@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Definitely, zlib.compress should raise a TypeError (like bz2 does).

>>> import bz2, zlib
>>> bz2.compress('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument 1 must be bytes or buffer, not str
>>> zlib.compress('abc')
b"x\x9cKLJ\x06\x00\x02M\x01'"

Someone can review the patch and merge it?

----------
nosy: +flox
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 15:47:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 14:47:00 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1260802020.99.0.229353973069.issue2259@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: r.david.murray -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:03:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 15:03:34 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260803014.85.0.979494707784.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure there's any real issue here. The signal *does* get
propagated to the main thread, it only takes some time to do so. If you
want the program to be interruptible more quickly, just lower the
timeout you give to select().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:05:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 15:05:30 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260803130.55.0.484806427159.issue4757@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch lacks a test that TypeError is raised on unicode input,
otherwise it's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:08:39 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Dec 2009 15:08:39 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260803319.31.0.35352095221.issue1975@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I don't like the suggestion to lower the timeout to select().  Lots of
the rest of the world is pushing towards removing this kind of periodic
polling (generally with the goal of improving power consumption). 
Python should be going this way too (the recent introduction of
signal.set_wakeup_fd suggests that at least some Python developers are
convinced of this).

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:11:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 15:11:18 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1260803319.31.0.35352095221.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260803515.3360.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't like the suggestion to lower the timeout to select().  Lots of
> the rest of the world is pushing towards removing this kind of periodic
> polling (generally with the goal of improving power consumption). 

Yes, I'm aware of this. I was only suggesting the easiest solution to
the problem at hand :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:29:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 16:29:30 +0000
Subject: [issue1680159] Misleading exception from unicode.__contains__
Message-ID: <1260808170.33.0.2250438006.issue1680159@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r76831.  (I changed the test assertion to check
specifically for UnicodeDecodeError.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1680159>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:35:05 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 16:35:05 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260808505.83.0.985548254597.issue4757@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch from haypo updated for r76830 .

Additional tests for TypeError, and to check that bytearray objects are
accepted.

----------
Added file: http://bugs.python.org/file15555/issue4757_zlib_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:55:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 16:55:07 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260809707.03.0.643140493521.issue4757@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch produces a number of errors in test_tarfile, test_distutils,
test_gzip and test_xmlrpc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:04:29 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 17:04:29 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260810269.5.0.227644389156.issue4757@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Fixed.

And some "bytearray" tests improved in test_zlib.

----------
Added file: http://bugs.python.org/file15556/issue4757_zlib_bytes_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:10:42 2009
From: report at bugs.python.org (Venkateswaran)
Date: Mon, 14 Dec 2009 17:10:42 +0000
Subject: [issue7505] ctypes not converting None to Null in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>


New submission from Venkateswaran <wenkat.s at gmail.com>:

The attached code is failing to convert None to Null. It is successful 
if the int* is shifted towards the beginning of argument list. The bug 
is actually in 32/64 bit pointers as the code works on a 32 bit system.

The bug disappears if I reduce the number of arguments to less than 10.

I created the so using the command - "gcc  -shared -fPIC  -o libtest.so 
libtest.c", (gcc (Debian 4.3.2-1.1) 4.3.2) 

The c file is as follows:

libtest.c
#include <stdint.h>
#include <stdio.h>


int32_t where ( int32_t a, int32_t c, int32_t d, int32_t e, int32_t f, 
int32_t g, int32_t h, int32_t *b, int32_t i, int32_t j, int32_t k, 
int32_t l)
{
    printf("b = %p\n", (void *)b);
    printf("a = %d, c = %d, d = %d, e = %d, f = %d, g = %d, h = %d, i = 
%d, j = %d, k = %d,  l = %d", a,c,d,e,f,g,h,i,j,k,l);

    return 100;

} /* where() */

Python Code:
import ctypes

libtest = ctypes.CDLL('./libtest.so')
where = libtest.where
where.restype = ctypes.c_int
where.argtypes = [ 
                    ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,          
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,
                    ctypes.POINTER(ctypes.c_int32),
                    ctypes.c_int32, ctypes.c_int32, ctypes.c_int32, 
ctypes.c_int32,
                 ]


a = 7
b = None

status = where(a,a,a,a,a,a,a,b,a,a,a,a)

----------
assignee: theller
components: ctypes
files: test.py
messages: 96385
nosy: theller, wenkat_s
severity: normal
status: open
title: ctypes not converting None to Null in 64-bit system
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15557/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7505>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:00:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 18:00:19 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260813619.87.0.641318241747.issue4757@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:07:49 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 14 Dec 2009 18:07:49 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260814069.5.0.0844369468858.issue1975@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

The real, OS signal does not get propagated to the main thread.  Only
the python-level signal handler runs from the main thread.

Correctly written programs are supposed to let select block
indefinitely.  This allows them to have exactly 0 CPU usage, especially
important on laptops and other limited power devices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:12:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 18:12:34 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1260814354.09.0.263024465708.issue7119@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a doc patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15558/email_generate_mutates_message_docfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:13:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 18:13:19 +0000
Subject: [issue1680159] Misleading exception from unicode.__contains__
Message-ID: <1260814399.45.0.295419294341.issue1680159@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1680159>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:17:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 18:17:27 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1260814069.5.0.0844369468858.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260814682.3360.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The real, OS signal does not get propagated to the main thread.  Only
> the python-level signal handler runs from the main thread.

Well, the signals /are/ delivered as far as Python code is concerned. I
don't think Python makes any promise as to the delivery of signals at
the C level.
(actually, the best promise we may make is not to block signal delivery
at all, so that third-party libs or extensions relying on threaded
signal delivery don't break)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:24:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 18:24:47 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260815087.72.0.0402731676418.issue4757@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was committed to py3k and 3.1. Thank you!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:35:00 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 14 Dec 2009 18:35:00 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260815700.09.0.158850247427.issue1975@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

You forget that the original report is about ctrl-C.  Should we abandon
support of it for threaded programs?  Close as won't-fix?

We could also just block SIGINT, but why?  That means we don't support
python signal handlers in threaded programs (signals sent to the
process, not ones sent direct to threads), and IMO threads expecting a
specific signal should explicitly unblock it anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:48:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 18:48:19 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1260815700.09.0.158850247427.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260816535.3360.21.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You forget that the original report is about ctrl-C.  Should we abandon
> support of it for threaded programs?

We haven't abandoned support, have we? Where is the spec that is
currently broken?

Besides, as Jean-Paul pointed out, the user can now setup a file
descriptor on which a byte will be written out as soon as a signal gets
caught.

> Close as won't-fix?

It is one possibility indeed.
We could also add an API (or an optional argument to the existing APIs)
to block signals in threads created by Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:48:56 2009
From: report at bugs.python.org (Pete Hunt)
Date: Mon, 14 Dec 2009 18:48:56 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>


New submission from Pete Hunt <floydophone at gmail.com>:

BaseManager.__reduce__ references from_address, which, to my knowledge, 
has been eliminated from the package.

----------
components: Library (Lib)
messages: 96392
nosy: peterhunt
severity: normal
status: open
title: multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:52:19 2009
From: report at bugs.python.org (John Levon)
Date: Mon, 14 Dec 2009 18:52:19 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260816739.78.0.915128917198.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

The spec broken is here:

http://docs.python.org/library/signal.html

Namely:

# Some care must be taken if both signals and threads are used in the
same program. The fundamental thing to remember in using signals and
threads simultaneously is: always perform signal() operations in the
main thread of execution. Any thread can perform an alarm(),
getsignal(), pause(), setitimer() or getitimer(); only the main thread
can set a new signal handler, and the main thread will be the only one
to receive signals (this is enforced by the Python signal module, even
if the underlying thread implementation supports sending signals to
individual threads). This means that signals can?t be used as a means of
inter-thread communication. Use locks instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:03:30 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 19:03:30 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260817410.57.0.0454124927922.issue4770@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I agree, we need consistency between all functions of this package.

I've run a small script to check what happens for all 16 functions of
the binascii package when they receive unicode input...

See attached script (and sample output).

IMHO 4 functions should be fixed to raise the same TypeError:
 - a2b_hex
 - a2b_qp
 - unhexlify
 - rledecode_hqx 

Documentation says that the functions in `binary` module ? convert
between binary and various ASCII-encoded binary representations ?
So... it's all binary.

Implicit encoding should not happen, never.

----------
nosy: +flox
versions: +Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file15559/case_binascii.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:04:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 19:04:52 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1260816739.78.0.915128917198.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260817528.3360.30.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The spec broken is here:
> 
> http://docs.python.org/library/signal.html

I would argue it is not broken. This documentation page is about a
module of the standard library, it doesn't specify the underlying C
implementation. That "the main thread will be the only one to receive
signals" is true if you consider it from the Python code's point of
view: signal handlers are always called in the main thread, even if the
OS-level signal was delivered to (and caught by) another thread.

I don't have any strong view over whether the interpreter should,
theoretically, block signals in non-main threads. But, practically,
blocking signals apparently produced issues with readline (and possibly
other libs relying on signals), which is why they are not blocked today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:08:39 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 19:08:39 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1260817719.99.0.226026937352.issue4757@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15555/issue4757_zlib_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4757>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:10:55 2009
From: report at bugs.python.org (Marcin Stepnicki)
Date: Mon, 14 Dec 2009 19:10:55 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260817855.29.0.687167439575.issue1975@psf.upfronthosting.co.za>


Marcin Stepnicki <marcin.stepnicki at haibane.pl> added the comment:

> I don't have any strong view over whether the interpreter should,
> theoretically, block signals in non-main threads. But, practically,
> blocking signals apparently produced issues with readline (and possibly
> other libs relying on signals), which is why they are not blocked today.

I see your point of view, but the problem is that current behaviour is
inconsistent between different operating system. As there are many
people who brought up this issue, I think it should be at least
documented somewhere.

Regards,
Marcin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:12:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 19:12:23 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260817943.37.0.988883209289.issue1975@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:14:15 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Dec 2009 19:14:15 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260818055.46.0.874336668639.issue1975@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> > http://docs.python.org/library/signal.html

> I would argue it is not broken.

If it's not broken, then the docs are at least confusing.  They should
make clear whether they are talking about the underlying signal or the
Python signal handler.  This makes a difference for many applications
which deal with signals.  I would even say that due to the very tricky
nature of signals, the documentation *should* be discussing the way it
is implemented.  Without that information, it's very difficult to handle
some situations correctly.  This wouldn't necessarily mean that the
implementation would have to stay the same, either - just that the
implementation be documented for each version (of course, keeping it the
same would be preferable, for all the normal reasons).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:42:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 19:42:25 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1260819745.47.0.904562618524.issue7506@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 5862 and issue 3518.  One or more of these three tickets
could possibly be closed as duplicates.

----------
assignee:  -> jnoller
keywords: +easy
nosy: +jnoller, r.david.murray
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:42:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 19:42:35 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1260819755.92.0.829279271971.issue7506@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/issue7506>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:23:41 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 20:23:41 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260822221.89.0.89036898713.issue4770@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

This patch removes implicit encoding in binascii functions:
 - a2b_hex (=unhexlify)
 - a2b_qp
 - rledecode_hqx 

 * Tests module "test_binascii" is reviewed and simplified.
 * Fixes for "email", "pickle" and "quopri" modules to encode input.

All tests pass.

----------
keywords: +patch
Added file: http://bugs.python.org/file15560/issue4770_binascii_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:54:44 2009
From: report at bugs.python.org (David Watson)
Date: Mon, 14 Dec 2009 20:54:44 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1260824084.29.0.545343922223.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Hi, I'm afraid there may have been some duplication of effort
here - I set about reworking Heiko Wundram's original patch
(issue #1194378) without knowing about this one.  I don't have
unit tests yet either, but I saw this and thought I'd better post
what I had.  It includes the items on Kalman's to-do list.

This patch is based on Heiko's original code, but changes the
interface, dropping the special processing of SCM_RIGHTS, etc. (I
think the encoding/decoding would be better handled with separate
functions/classes), and adds source address (msg_name) support
and scatter/gather I/O via sendmsg() and a new recvmsg_into()
method, as well as fixing various bugs and limitations.

Comments/flames welcome too.  You'll see a few XXX comments in
the code.  One in particular refers to the msg_name value from
recvmsg() on a connected socket; I've said in the docstring that
it is "unspecified" in this case, but it might or might not
contain a valid address, depending on the OS.  These methods may
also need to be conditionally compiled if, say, CMSG_SPACE (or
sendmsg/recvmsg?) isn't available somewhere.

I didn't add a facility to receive into only part of a buffer in
recvmsg_into(), like the one in recv_into(), since memoryview
objects make it redundant AFAICT.

----------
nosy: +baikie
Added file: http://bugs.python.org/file15561/baikie-hwundram.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:05:18 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Dec 2009 21:05:18 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1260822221.89.0.89036898713.issue4770@psf.upfronthosting.co.za>
Message-ID: <4B26A886.6020308@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

flox wrote:
> 
> flox <laxyf at yahoo.fr> added the comment:
> 
> This patch removes implicit encoding in binascii functions:
>  - a2b_hex (=unhexlify)
>  - a2b_qp
>  - rledecode_hqx 
> 
>  * Tests module "test_binascii" is reviewed and simplified.
>  * Fixes for "email", "pickle" and "quopri" modules to encode input.
> 
> All tests pass.

Are you sure that this patch is correct (which RFC says
that quoted printable should use our raw-unicode-escape
codec ?):

Index: Lib/email/message.py
===================================================================
--- Lib/email/message.py	(revision 76839)
+++ Lib/email/message.py	(working copy)
@@ -198,6 +198,8 @@
             return None
         cte = self.get('content-transfer-encoding', '').lower()
         if cte == 'quoted-printable':
+            if isinstance(payload, str):
+                payload = payload.encode('raw-unicode-escape')
             return utils._qdecode(payload)
         elif cte == 'base64':
             try:

The patch also needs to fix the documentation and add a NEWS
entry.

Making these APIs strict in the sense that they don't accept
str-instances anymore needs to be mentioned very clearly.

We may even have to go through a deprecation process for them,
since they can easily cause perfectly working code to suddenly
fail.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:25:25 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 21:25:25 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260825925.49.0.753289103795.issue4770@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

> Are you sure that this patch is correct (which RFC says
> that quoted printable should use our raw-unicode-escape
> codec ?):

I am not sure of anything. It is an "educated guess" at the most.
Since 'base64' and 'x-uuencode' both use 'raw-unicode-escape'...

See longer excerpt below.


Index: Lib/email/message.py
===================================================================
--- Lib/email/message.py        (revision 76839)
+++ Lib/email/message.py        (working copy)
@@ -189,24 +189,26 @@
         elif not isinstance(self._payload, list):
             raise TypeError('Expected list, got %s' % type(self._payload))
         else:
             payload = self._payload[i]
         if not decode:
             return payload
         # Decoded payloads always return bytes.  XXX split this part
out into
         # a new method called .get_decoded_payload().
         if self.is_multipart():
             return None
         cte = self.get('content-transfer-encoding', '').lower()
         if cte == 'quoted-printable':
+            if isinstance(payload, str):
+                payload = payload.encode('raw-unicode-escape')
             return utils._qdecode(payload)
         elif cte == 'base64':
             try:
                 if isinstance(payload, str):
                     payload = payload.encode('raw-unicode-escape')
                 return base64.b64decode(payload)
                 #return utils._bdecode(payload)
             except binascii.Error:
                 # Incorrect padding
                 pass
         elif cte in ('x-uuencode', 'uuencode', 'uue', 'x-uue'):
             in_file = BytesIO(payload.encode('raw-unicode-escape'))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:40:44 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Dec 2009 21:40:44 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1260825925.49.0.753289103795.issue4770@psf.upfronthosting.co.za>
Message-ID: <4B26B0D9.7070204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

flox wrote:
> 
> flox <laxyf at yahoo.fr> added the comment:
> 
>> Are you sure that this patch is correct (which RFC says
>> that quoted printable should use our raw-unicode-escape
>> codec ?):
> 
> I am not sure of anything. It is an "educated guess" at the most.
> Since 'base64' and 'x-uuencode' both use 'raw-unicode-escape'...

Quoted printable as well as the other two transfer encodings should
be encodings that "fit" into the 7-bit ASCII default originally
assumed for email messages, so 'ascii' appears to be the more
natural choice.

The choice of 'raw-unicode-escape' will cause strange error
messages or hide errors, since it encodes non-ASCII code points
using '\xNN' which these codecs don't supports:

b''
>>> base64.b64decode('???'.encode('ascii'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:45:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 21:45:56 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260827156.18.0.966073116863.issue4770@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with Marc-Andr? that enforcing ASCII looks like the only
sensible solution. Perhaps Barry knows the purpose of using
"raw-unicode-escape" here, though?

----------
nosy: +barry, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:48:30 2009
From: report at bugs.python.org (Ben Gertzfield)
Date: Mon, 14 Dec 2009 21:48:30 +0000
Subject: [issue7507] pipes.quote does not correctly escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>


New submission from Ben Gertzfield <bgertzfield at gmail.com>:

The undocumented (but unit tested!) pipes.quote does not correctly 
escape '!', which cannot be passed to the shell outside of single-
quotes:

sh-3.2$ 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 pipes
>>> pipes.quote("omgshoes!")
'omgshoes!'

sh-3.2$ echo "omgshoes!"
sh: !": event not found

bash-3.2$ echo "omgshoes!"
bash: !": event not found

zsh-4.3.9% echo "omgshoes!"
dquote> 

This needs to be single-quoted for safety:

sh-3.2$ echo 'omgshoes!'
omgshoes!
bash-3.2$ echo 'omgshoes!'
omgshoes!
zsh-4.3.9% echo 'omgshoes!'
omgshoes!

----------
components: Library (Lib)
messages: 96405
nosy: bgertzfield, eric.smith, jjwiseman, tim_one
severity: normal
status: open
title: pipes.quote does not correctly escape !
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7507>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:51:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 21:51:56 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260827516.54.0.460460290936.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I said, a flexible solution would be for thread creation functions to
take an optional argument specifying whether to block signals or not.
(I don't mind the default value of the argument :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:55:13 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Dec 2009 21:55:13 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260827713.08.0.377529847041.issue4770@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The email interface ate part of the code snippet. Here's the complete
version:

>>> import base64
>>> base64.b64decode('???'.encode('raw-unicode-escape'))
b''
>>> base64.b64decode('???'.encode('ascii'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-2: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:55:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 21:55:40 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1260827740.49.0.661164409884.issue7502@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There doesn't seem to be an __eq__ or __cmp__ method in DocTestCase,
which implies that the issue is with unittest.TestCase (from which
DocTestCase inherits).

----------
nosy: +michael.foord, pitrou
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Mon Dec 14 22:57:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 21:57:56 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260827876.8.0.288293485362.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, a patch. Now we're talking :)

----------
resolution: wont fix -> 
stage:  -> patch review
status: closed -> open
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:00:14 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Dec 2009 22:00:14 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1260828014.14.0.112531178593.issue7502@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Or an interaction between TestCase and DocTestCase.  TestCase.__eq__ and
TestCase.__hash__ are both implemented in terms of the _testMethodName
attribute.  It looks like this is *always* "runTest" for a DocTestCase
instance.  It probably doesn't make sense to set a _testMethodName for
DocTestCase instances (maybe it doesn't even make sense for DocTestCase
to subclass TestCase, in fact).  So perhaps overriding comparison and
hashing to use the attributes that do make sense (_dt_test, maybe, I
don't know) would make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:06:54 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 14 Dec 2009 22:06:54 +0000
Subject: [issue7502] All DocTestCase instances compare and hash equal to each
	other
In-Reply-To: <1260757418.81.0.639344471031.issue7502@psf.upfronthosting.co.za>
Message-ID: <1260828414.64.0.197669110051.issue7502@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Agreed, defining __eq__ and __hash__ on DocTestCase sounds like the way
to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7502>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:09:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 22:09:05 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260828545.58.0.2311559831.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch doesn't apply against the SVN trunk (some parts are rejected).
I suppose it was done against 2.6 or earlier, but those versions are in
bug fixing-only mode (which excludes performance improvements), so
you'll have to regenerate it against the SVN trunk.

(for info about our SVN repository, see
http://www.python.org/dev/faq/#how-do-i-get-a-checkout-of-the-repository-read-only-and-read-write
)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:11:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 22:11:08 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260828668.36.0.298185187657.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, my bad, I hadn't seen that the patch is for 3.2. Sorry for the
confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:13:21 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 22:13:21 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260828801.94.0.408596481981.issue4770@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I perform a "grep" on the email package (with patch applied).
There's some places where 'raw-unicode-escape' is used.

I understand that all "payload.encode('raw-unicode-escape')" should be
changed to "payload.encode('ascii')" when the payload is processed by
another transfer encoding (line 202, 207 and 214).
The last one (when 'content-transfer-encoding' is not recognized) should
remain unchanged?

All other uses of 'raw-unicode-escape' seem correct.



Lib/email/base64mime.py:112:
        return a2b_base64(string.encode('raw-unicode-escape'))
Lib/email/header.py:111:
        word = bytes(word, 'raw-unicode-escape')
Lib/email/message.py:202:
        payload = payload.encode('raw-unicode-escape')
Lib/email/message.py:207:
        payload = payload.encode('raw-unicode-escape')
Lib/email/message.py:214:
        in_file = BytesIO(payload.encode('raw-unicode-escape'))
Lib/email/message.py:225:
        return payload.encode('raw-unicode-escape')
Lib/email/message.py:767:
        as_bytes = charset[2].encode('raw-unicode-escape')
Lib/email/utils.py:298:
        rawbytes = bytes(text, 'raw-unicode-escape')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:20:39 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 14 Dec 2009 22:20:39 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260829239.97.0.210967383149.issue1975@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

A better solution would be to block all signals by default, then unblock
specific ones you expect.  This avoids races (as undeliverable signals
are simply deferred.)

Note that readline is not threadsafe anyway, so it doesn't necessarily
need to allow calls from the non-main thread.  Maybe somebody is using
that way, dunno.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:40:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Dec 2009 22:40:55 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260830455.09.0.838654216464.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I confirm that the patch gives good speedups. It would be nice if there
was a comment explaining what extrabuf, extrastart and extrasize are.

In 3.x, a better but more involved approached would be to rewrite the
gzip module so as to take advantage of the standard IO classes
(especially BufferedReader / BufferedWriter), which are written in C and
are therefore much faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:04:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2009 23:04:57 +0000
Subject: [issue7498] test_multiprocessing test_rapid_restart fails if port
	9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1260831897.28.0.0259150720883.issue7498@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r76840 on trunk, r76842 for 2.6, r76843 for py3k, and
r76844 for 3.1.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7498>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:51:52 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 23:51:52 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260834712.01.0.238832932683.issue4770@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch updated:
 * Added documentation
 * Switched to "payload.encode('ascii')" in the "email.message" module

Note: there was no ambiguity on the first line of the documentation:
? [These functions] convert between binary and various ASCII-encoded
binary representations ?

So, it should only convert bytes in range(256) to bytes in range(128).

----------
Added file: http://bugs.python.org/file15562/issue4770_binascii_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:53:59 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 23:53:59 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260834839.53.0.0694563326347.issue4770@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15562/issue4770_binascii_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:54:16 2009
From: report at bugs.python.org (flox)
Date: Mon, 14 Dec 2009 23:54:16 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1260834856.62.0.228869663864.issue4770@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15563/issue4770_binascii_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Tue Dec 15 05:43:45 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2009 04:43:45 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"5.9. File Objects?
File objects are implemented using C?s stdio package and can be created
with the built-in open() function."

As I understand, the part about stdio is no longer true.
Also, as I understand, there is no longer a class <file> object.
Rather there are various io (or _io) classes returned by open depending
on the args, especially the mode. This should be made clear. Something like

"File objects are created by the built-in open function and others.
There are instances of various classes exposed in the io module. The
following discusses the methods common to various file objects."

Maybe even retitle the section "IO objects" and use 'io' instead of
'file' as the prefix for method names.

Maybe whoever wrote the new io system could check this section for accuracy.

----------
assignee: georg.brandl
components: Documentation
messages: 96419
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Update 'file object' doc
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:24:49 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:24:49 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 
2008 express installed using Python 2.6.4 64-bit (via buildout).

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1714, in main
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1695, in with_ei_usage
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1718, in <lambda>
  File "C:\Python25\lib\distutils\core.py", line 151, in setup
    dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
236, in run
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
452, in easy_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
501, in install_item
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
680, in install_eggs
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
957, in build_and_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
946, in run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in 
<lambda>
  File "setup.py", line 163, in <module>

  File "C:\Python25\lib\distutils\core.py", line 151, in setup
    dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\install_lib.py", line 
20, in run
  File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in 
build
    self.run_command('build_ext')
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in 
run
    self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in 
build_extensions
    self.build_extension(ext)
  File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in 
build_extension
    depends=ext.depends)
  File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
    if not self.initialized: self.initialize()
  File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in 
initialize
    self.__paths = self.get_msvc_paths("path")
  File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in 
get_msvc_paths
    % (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

----------
assignee: tarek
components: Distutils
messages: 96420
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:26:49 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:26:49 +0000
Subject: [issue7510] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858409.37.0.0719386096256.issue7510@psf.upfronthosting.co.za>
Message-ID: <1260858409.37.0.0719386096256.issue7510@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 
2008 express installed using Python 2.5.4 64-bit (via buildout).

See also: http://twistedmatrix.com/trac/ticket/3352

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1714, in main
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1695, in with_ei_usage
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1718, in <lambda>
  File "C:\Python25\lib\distutils\core.py", line 151, in setup
    dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
236, in run
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
452, in easy_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
501, in install_item
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
680, in install_eggs
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
957, in build_and_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
946, in run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in 
<lambda>
  File "setup.py", line 163, in <module>

  File "C:\Python25\lib\distutils\core.py", line 151, in setup
    dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\install_lib.py", line 
20, in run
  File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in 
build
    self.run_command('build_ext')
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
    cmd_obj.run()
  File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in 
run
    self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in 
build_extensions
    self.build_extension(ext)
  File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in 
build_extension
    depends=ext.depends)
  File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
    if not self.initialized: self.initialize()
  File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in 
initialize
    self.__paths = self.get_msvc_paths("path")
  File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in 
get_msvc_paths
    % (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

----------
assignee: tarek
components: Distutils
messages: 96421
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7510>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:27:58 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:27:58 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Win XP 64-bit
Python 2.6.4 64-bit

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1714, in main

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1695, in with_ei_usage

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1718, in <lambda>

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 236, in run

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 452, in easy_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 501, in install_item

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 680, in install_eggs

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 957, in build_and_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 946, in run_setup

  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 70, in 
run
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 31, in 
<lambda>
  File "setup.py", line 163, in <module>

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\install_lib.py", 
line 20, in run
  File "C:\Python26\lib\distutils\command\install_lib.py", line 113, in 
build
    self.run_command('build_ext')
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in 
run
    self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in 
build_extensions
    self.build_extension(ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in 
build_extension
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in 
compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in 
initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in 
query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

----------
assignee: tarek
components: Distutils
messages: 96422
nosy: srid, tarek
severity: normal
status: open
title: msvc9compiler.py: ValueError: [u'path']
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:28:35 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:28:35 +0000
Subject: [issue7509] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858289.28.0.0186938090611.issue7509@psf.upfronthosting.co.za>
Message-ID: <1260858515.85.0.683968779877.issue7509@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Duplicate of issue7510

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7509>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:37:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 Dec 2009 06:37:05 +0000
Subject: [issue7510] AttributeError: MSVCCompiler instance has no attribute
	'_MSVCCompiler__root'
In-Reply-To: <1260858409.37.0.0719386096256.issue7510@psf.upfronthosting.co.za>
Message-ID: <1260859025.45.0.993492597361.issue7510@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.5 is no longer maintained, except for security issues (which
this one is not). Closing as won't fix.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7510>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:39:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 Dec 2009 06:39:48 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260859188.86.0.049329059799.issue7511@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Most likely, the problem is that visual studio is not installed on your
system.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:42:24 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 15 Dec 2009 06:42:24 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260859344.02.0.583516606793.issue7511@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I have Visual C++ 2008 express edition installed.

Maybe it is a quirk of express edition as I was able to install pycrypto 
fine with the Visual Studio 2008 professional edition at work machine.

In any case, I believe this is a bug with distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:33:13 2009
From: report at bugs.python.org (Kuang-che Wu)
Date: Tue, 15 Dec 2009 07:33:13 +0000
Subject: [issue7512] shutil.copystat may fail EOPNOTSUPP
In-Reply-To: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>
Message-ID: <1260862393.85.0.15479395745.issue7512@psf.upfronthosting.co.za>


New submission from Kuang-che Wu <kcwu at csie.org>:

"flags" is only supported on certain OS. FreeBSD is one of them.
FreeBSD itself support chflags but not all of its file systems do.

On FreeBSD, copystat() will fail on zfs. The exception is OSError and
errno is EOPNOTSUPP. According to manpage chflags(2), the errno means
"The underlying file system does not support file flags"

If the file system doesn't support flags, we should not call
os.chflags() at first or should not raise exception.

In my patch, I just ignore EOPNOTSUPP exception.

----------
components: Library (Lib)
files: copystat.diff
keywords: patch
messages: 96427
nosy: kcwu
severity: normal
status: open
title: shutil.copystat may fail EOPNOTSUPP
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15564/copystat.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7512>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:42:23 2009
From: report at bugs.python.org (Andriy Pylypenko)
Date: Tue, 15 Dec 2009 07:42:23 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260862943.48.0.135573978274.issue1975@psf.upfronthosting.co.za>


Andriy Pylypenko <bambyster at gmail.com> added the comment:

Let me add my 2 cents. I understood the considerations about differences 
between Python code level interrupt handling and OS level interrupts. 

What I cannot get is why to preserve the handling of signals in the user 
threads on OSes like FreeBSD and Solaris. This functionality isn't used 
on Linux and Windows at all, as the interrupts on them are always 
delivered to the main thread. The patch simply assures the same behavior 
on the FreeBSD and Solaris, so why to keep things unpredictable when 
there is a way to solve the problem? Can anyone state what exactly 
purpose of not to make OS signal handling in Python predictable?

This bug report was created mainly because there is no easy Python code 
solution for this problem. The Python documentation clearly states that 
there is no user accessible Python functions that can modify per-thread 
signal mask, so it is currently impossible to solve the problem with 
just Python code. Modification of timeouts isn't vital solution in far 
too many real life situations.

BTW this patch is officially in the FreeBSD ports tree since Feb 27 2009 
and there is no complains on this patch since then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:54:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Dec 2009 10:54:24 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260874464.93.0.796305930326.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the history on this looks a bit complicated and I don't really
know the details, but witness the first sentences of the initial message
in issue960406:

?This is a patch which will correct the issues some people 
have with python's handling of signal handling in threads. It 
allows any thread to initially catch the signal mark it as 
triggered, allowing the main thread to later process it. (This 
is actually just restoring access to the functionality that was 
in Python 2.1)?

Apparently Python has been hesitating between both behaviours.

> The Python documentation clearly states that 
> there is no user accessible Python functions that can modify
> per-thread signal mask, so it is currently impossible to solve the
> problem with just Python code.

Well as I already said we could introduce this missing feature. Ideas
and patches welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:16:57 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 15 Dec 2009 11:16:57 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260875817.64.0.543467681263.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I have the same issue with the Express edition. You can work around it
by finding and executing vcvars32.bat or vcvars64.bat before running
setup.py. It would be nice if distutils took care of it though.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:22:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 15 Dec 2009 11:22:56 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1260876176.77.0.305925743065.issue3745@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory, this patch should not have been backported to Python 2.7. See issue

Could you please revert the change on trunk ? Thanks.

A much better solution would be to issue a -3 warning in case a Unicode
object is passed to the hash functions. However, this is major work to
get right, since the "s#" parser marker also accepts buffer interfaces.

----------
nosy: +lemburg
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:25:52 2009
From: report at bugs.python.org (Lev Shamardin)
Date: Tue, 15 Dec 2009 11:25:52 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1260876352.89.0.934720202151.issue5673@psf.upfronthosting.co.za>


Changes by Lev Shamardin <shamardin at gmail.com>:


----------
nosy: +abbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:28:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 15 Dec 2009 11:28:31 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260876511.63.0.476421676219.issue7511@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's what distutils does : it runs vcvarsall.bat and pass as the
argument the architecture.

Can you run:

$ vcvarsall.bat arch

(replace arch by x86 or x64)

and paste me the result ?  (it looks like the 'path' variable misses
from this file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:34:17 2009
From: report at bugs.python.org (Andriy Pylypenko)
Date: Tue, 15 Dec 2009 11:34:17 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260876857.36.0.853374848028.issue1975@psf.upfronthosting.co.za>


Andriy Pylypenko <bambyster at gmail.com> added the comment:

> Well as I already said we could introduce this missing feature. Ideas
> and patches welcome.

Well, this would be definitely a working solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:04:13 2009
From: report at bugs.python.org (ivank)
Date: Tue, 15 Dec 2009 12:04:13 +0000
Subject: [issue7513] many source files contaminated with form feed (\f)
	characters
In-Reply-To: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
Message-ID: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

In a checkout of Python 2.7 r76831, a large amount of files contain the
form feed character (\f, \x0C, octal \014)

$ grep --binary-files=without-match -P '\f' **/* | sort | uniq

build/scripts-2.7/smtpd.py:

Lib/base64.py:

Lib/email/base64mime.py:

Lib/email/charset.py:

Lib/email/encoders.py:

Lib/email/errors.py:

Lib/email/feedparser.py:

Lib/email/generator.py:

Lib/email/header.py:

Lib/email/__init__.py:

Lib/email/iterators.py:

Lib/email/message.py:

Lib/email/mime/audio.py:

Lib/email/mime/base.py:

Lib/email/mime/image.py:

Lib/email/mime/message.py:

Lib/email/mime/multipart.py:

Lib/email/mime/nonmultipart.py:

Lib/email/mime/text.py:

Lib/email/parser.py:

Lib/email/quoprimime.py:

Lib/email/test/test_email_codecs.py:

Lib/email/test/test_email_codecs_renamed.py:

Lib/email/test/test_email.py:

Lib/email/test/test_email_renamed.py:

Lib/email/test/test_email_torture.py:

Lib/email/utils.py:

Lib/smtpd.py:

Lib/test/test_base64.py:

Lib/test/test_isinstance.py:

Misc/python-mode.el:

Modules/_ctypes/cfield.c:

Modules/_ctypes/_ctypes.c:

Modules/_io/bufferedio.c:

Modules/_io/_iomodule.c:

Modules/puremodule.c:

Modules/_tkinter.c:

Tools/audiopy/audiopy:

Tools/audiopy/README:

Tools/i18n/msgfmt.py:

Tools/i18n/pygettext.py:

Tools/pynche/ChipViewer.py:

Tools/pynche/ColorDB.py:

Tools/pynche/DetailsViewer.py:

Tools/pynche/Main.py:

Tools/pynche/pyColorChooser.py:

Tools/pynche/PyncheWidget.py:

Tools/pynche/README:

Tools/pynche/StripViewer.py:

Tools/pynche/Switchboard.py:

Tools/pynche/TextViewer.py:

Tools/pynche/TypeinViewer.py:

Tools/world/README:

Tools/world/world:

----------
components: None
messages: 96434
nosy: ivank
severity: normal
status: open
title: many source files contaminated with form feed (\f) characters
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7513>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:13:09 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 15 Dec 2009 12:13:09 +0000
Subject: [issue7513] many source files contaminated with form feed (\f)
	characters
In-Reply-To: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
Message-ID: <1260879189.98.0.129198564258.issue7513@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

AFAIR, Barry likes these. Not sure exactly why ;-)

----------
nosy: +barry, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7513>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:16:34 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 15 Dec 2009 12:16:34 +0000
Subject: [issue7513] many source files contaminated with form feed (\f)
	characters
In-Reply-To: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
Message-ID: <1260879394.01.0.99607161645.issue7513@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Emacs navigation command forward-page and backward-page.  Python treats
them as whitespace, so what's the problem? :)

----------
priority:  -> low
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7513>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:04:18 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Dec 2009 13:04:18 +0000
Subject: [issue7513] many source files contaminated with form feed (\f)
	characters
In-Reply-To: <1260878653.08.0.0862176638007.issue7513@psf.upfronthosting.co.za>
Message-ID: <1260882258.69.0.353923465682.issue7513@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is also allowed by PEP8.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7513>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:36:38 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 15 Dec 2009 13:36:38 +0000
Subject: [issue7445] urllib2 (and urllib) should raise error for incomplete
	response
In-Reply-To: <1260032326.17.0.135874327566.issue7445@psf.upfronthosting.co.za>
Message-ID: <1260884198.38.0.757273407036.issue7445@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is working as designed.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7445>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:43:20 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 15 Dec 2009 13:43:20 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1260884600.48.0.777258573078.issue7490@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@Lennart: yes, I do think you should add a test for that case.  I
haven't yet decided whether this should go into 2.6.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Tue Dec 15 15:44:52 2009
From: report at bugs.python.org (Karen Tracey)
Date: Tue, 15 Dec 2009 14:44:52 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1260888292.81.0.862071767669.issue3745@psf.upfronthosting.co.za>


Changes by Karen Tracey <kmtracey at gmail.com>:


----------
nosy: +kmtracey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:16:40 2009
From: report at bugs.python.org (xdcdx)
Date: Tue, 15 Dec 2009 15:16:40 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260890200.87.0.966372402109.issue3588@psf.upfronthosting.co.za>


xdcdx <agentriot at gmail.com> added the comment:

This bug is still present in Python 2.6 and Python 3.0 included with
Snow Leopard.

Code:

/Library/Frameworks/Python.framework/Versions/3.0/bin/python
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))

returns:
  Python.framework/Versions/3.0/Python

and

/Library/Frameworks/Python.framework/Versions/2.6/bin/python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))

Returns:
  -u _PyMac_Error Python.framework/Versions/2.6/Python

However,

/usr/bin/python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))

returns the correct path:
   -u _PyMac_Error
/System/Library/Frameworks/Python.framework/Versions/2.6/Python

----------
nosy: +xdcdx
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:57:19 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 15:57:19 +0000
Subject: [issue7514] doc: documentation for "sys.flags" is obsolete.
In-Reply-To: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
Message-ID: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

Patch attached.

----------
assignee: georg.brandl
components: Documentation
files: py3k_doc_sys_flags.diff
keywords: patch
messages: 96441
nosy: flox, georg.brandl
severity: normal
status: open
title: doc: documentation for "sys.flags" is obsolete.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15565/py3k_doc_sys_flags.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7514>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:01:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Dec 2009 16:01:21 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260892881.9.0.0539720502557.issue3588@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
nosy: +ronaldoussoren, tarek
priority:  -> normal
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:08:54 2009
From: report at bugs.python.org (xdcdx)
Date: Tue, 15 Dec 2009 16:08:54 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260893334.54.0.552071151949.issue3588@psf.upfronthosting.co.za>


xdcdx <agentriot at gmail.com> added the comment:

Correction to my last message: the first two Python installations,
located at /Library/Frameworks/Python.framework/Versions/ did not come
with Snow Leopard, I installed them from MacPython packages. The Snow
Leopard version (/usr/bin/python) does not seem affected by the bug.

I just installed the latest MacPython stable packages (2.6.4 and 3.1.1),
and the relative path bug is still present. Here's the result for 3.1.1:

--$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))
-framework CoreFoundation Python.framework/Versions/3.1/Python

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:11:57 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Dec 2009 16:11:57 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1260893517.41.0.0176865745128.issue7306@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

True, that slipped by me - thanks. 
Updated the patch against r76850.

----------
Added file: http://bugs.python.org/file15566/winsound_test_skipping_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7306>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:35:59 2009
From: report at bugs.python.org (John Levon)
Date: Tue, 15 Dec 2009 16:35:59 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260894959.94.0.0646133918456.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

I still do not understand the objection you have to the simple patch
which restores old behaviour, works the same across all OSes, and
doesn't require new APIs. What is the objection?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:39:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Dec 2009 16:39:43 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260895183.93.0.228854157624.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The objection is that the "old behaviour" was changed to solve another
problem. We don't gain anything by switching back and forth between two
different behaviours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:49:37 2009
From: report at bugs.python.org (John Levon)
Date: Tue, 15 Dec 2009 16:49:37 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260895777.65.0.807045610623.issue1975@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

To quote Andriy in the first comment:

"It doesn't bring any visible changes to readline behavior either."

Are you saying this is not the case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:59:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Dec 2009 16:59:39 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1260896379.02.0.169073130045.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm just saying that I don't know, and I don't think an observation from
one user is enough since these issues are notoriously platform-specific.

If you want to revert the change made in issue960406, you should IMO
demonstrate that somehow this change wasn't needed.
But I don't know how this would be better than a more flexible API,
except of course that the patch for that API doesn't exist (but wouldn't
be difficult to produce by someone motivated).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:01:55 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:01:55 +0000
Subject: [issue7515] Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
In-Reply-To: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>
Message-ID: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

~ $ ./python Lib/test/regrtest.py --help
(...)
    lib2to3 -   Run the tests for 2to3 (They take a while.)
(...)

~ $ ./python Lib/test/regrtest.py -ulib2to3
Invalid -u/--use option: lib2to3
Use --help for usage

----------
components: Tests
messages: 96448
nosy: flox
severity: normal
status: open
title: Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7515>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:05:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Dec 2009 17:05:07 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260896707.06.0.229568847398.issue3588@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What do you use LINKFORSHARED for?

As a minor rant: the wholesale export of all settings in the main 
Makefile through distutils sucks big time. I have no idea whether or not 
LINKFORSHARED is meant to be a public API, and if it is what it should 
be used for.

The value of LINKFORSHARED is correct for building the framework, making 
sure that the value is useful outside of the build of Python itself 
would almost certainly require hacks, either in the makefile or by 
patching the Makefile during installation.

BTW. I have no idea what's the point of msg75511, it doesn't seem to be 
related to the original report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:13:38 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:13:38 +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: <1260897218.64.0.913351647678.issue7092@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:23:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Dec 2009 17:23:38 +0000
Subject: [issue7515] Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
In-Reply-To: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>
Message-ID: <1260897818.56.0.929977645023.issue7515@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I see no sign that the resource is actually used by the lib2to3 test
suite, though it looks like there would be an opportunity for it to do
so (tests that are currently unconditionally skipped by
Lib/test/test_lib2to3).

Either the resource should be deleted from the help section of regrtest,
or it should be added to the list of resources and used by test_lib2to3.
 I'll let the determination of which up to Benjamin.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7515>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:35:14 2009
From: report at bugs.python.org (=?utf-8?q?Ricardo_S=C3=A1nchez-S=C3=A1ez?=)
Date: Tue, 15 Dec 2009 17:35:14 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260898514.11.0.11959216535.issue3588@psf.upfronthosting.co.za>


Ricardo S?nchez-S?ez <agentriot at gmail.com> added the comment:

I am using it to tell CMake where are the Python Libraries for linking.

Here's a snippet from my FindPythonLibs.cmake (I am attaching the whole
file as well):

...
EXECUTE_PROCESS(COMMAND ${PYTHON_EXECUTABLE} -c "import
distutils.sysconfig\nprint
distutils.sysconfig.get_config_var('LINKFORSHARED')"
        OUTPUT_VARIABLE PYTHON_LDFLAGS_OUTPUT_VARIABLE
        ERROR_VARIABLE PYTHON_LDFLAGS_ERROR_VARIABLE
        RESULT_VARIABLE PYTHON_LDFLAGS_RETURN_VALUE
        )
...

Does anybody happen to know a better/more correct way for linking the
python libs?

----------
Added file: http://bugs.python.org/file15567/FindPythonLibs.cmake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:47:51 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:47:51 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

~ $ ./python -3 Lib/test/regrtest.py -j2 test_py3kwarn
./Lib/encodings/__init__.py:100: DeprecationWarning:
                         the 'hex' codec has been removed in Python 3.0
  level=0)
test_py3kwarn
test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag
1 test skipped:
    test_py3kwarn
1 skip unexpected on linux2:
    test_py3kwarn

----------
components: Tests
messages: 96452
nosy: flox
severity: normal
status: open
title: Flag "-3" is silently ignored when running "regrtest.py -j2"
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:50:29 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 17:50:29 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1260899429.49.0.973372663815.issue7516@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Minimal patch proposed.

----------
keywords: +patch
Added file: http://bugs.python.org/file15568/issue7516_regrtest_mp.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Tue Dec 15 19:56:19 2009
From: report at bugs.python.org (Patrick Stinson)
Date: Tue, 15 Dec 2009 18:56:19 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>


New submission from Patrick Stinson <patrickkidd at gmail.com>:

Tools/Freeze/freeze.py is still producing C code that expects the old-
style module initialization functions, causing link errors.

The simple example in Tools/Freeze/hello.py easily demonstrates this 
behavior.

----------
components: Library (Lib)
messages: 96454
nosy: patrickkidd
severity: normal
status: open
title: freeze.py not ported to python3
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:19:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Dec 2009 19:19:48 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The Python/pymath.c file currently defines substitutes for some C99 libm 
functions (e.g., log1p), for the benefit of platforms that don't implement 
those functions.
It's compiled into the main Python executable.

There are (at least) two problems with this approach:

(1) on a platform that doesn't have (for example) log1p, we end up 
exporting the symbol _log1p from the main Python executable.  At the very 
least, this should have a _Py prefix.  Moreover, since log1p is only 
needed by the math and cmath modules, and not by the Python interpreter 
itself, python.exe shouldn't really be exporting it in the first place.

(2) It may not work!  As an experiment, I tried adding a new function 
expm1_alt to pymath.c, declaring it in Include/pymath.h with PyAPI_FUNC, 
and using it in Modules/mathmodule.c; but the function ended up not being 
visible to the math module:  the math module failed to build, with an 
error message:

dlopen(build/lib.macosx-10.4-i386-2.7/math.so, 2): Symbol not found: 
_expm1_alt

When I moved the function to a different source file (I picked 
Objects/longobject.c, for no particularly good reason) the new function 
became visible and the build succeeded.

The reason for the above behaviour appears to be (I'm guessing a little 
bit) that on my platform (OS X 10.6), none of the functions from pymath.c 
is needed in the main python executable, so when creating python.exe the 
linker ignores *all* the symbols from pymath.c.  So while libpython2.7.a 
exports _expm1_alt, python.exe does not.

I'm not sure what the best way to reorganize this setup is.

----------
components: Build
messages: 96455
nosy: mark.dickinson
severity: normal
status: open
title: Some functions in pymath.c should be moved elsewhere.
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:20:14 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 15 Dec 2009 19:20:14 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <4B27E16A.3000909@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

flox wrote:
> 
> New submission from flox <laxyf at yahoo.fr>:
> 
> ~ $ ./python -3 Lib/test/regrtest.py -j2 test_py3kwarn
> ./Lib/encodings/__init__.py:100: DeprecationWarning:
>                          the 'hex' codec has been removed in Python 3.0
>   level=0)
> test_py3kwarn
> test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag
> 1 test skipped:
>     test_py3kwarn
> 1 skip unexpected on linux2:
>     test_py3kwarn

I'm not sure where you are getting that warning from: it doesn't
exist in Python 2.7 (trunk) and will likely never exist, since we're
going to add that codec back to 3.1. See issue 7475.

Still, even without it, you get the error:

Python/Dev-Python> ./python -3 Lib/test/regrtest.py -j2 test_py3kwarn
test_py3kwarn
test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag
1 test skipped:
    test_py3kwarn
1 skip unexpected on linux2:
    test_py3kwarn

The reason is simple: when starting secondary processes to run the
tests, regrtest.py doesn't pass along the Python interpreter flags
to the secondary Python executeables.

It also ignores the environment variables by forcing the -E
option.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:29:17 2009
From: report at bugs.python.org (grego87)
Date: Tue, 15 Dec 2009 19:29:17 +0000
Subject: [issue7519] CompileParser can't read files with BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>


New submission from grego87 <grego87 at gmail.com>:

If config.ini file is encoded with utf-8 with bom markers this code

import ConfigParser
config = ConfigParser.ConfigParser()
config.read("config.ini")
config.sections()

throws:

ConfigParser.MissingSectionHeaderError: File contains no section headers.
file: config.ini, line: 1
'\xef\xbb\xbf[section]\n'

ConfigParser should be able to read such files.

----------
components: Library (Lib), Unicode
files: config.ini
messages: 96457
nosy: grego87
severity: normal
status: open
title: CompileParser can't read files with BOM markers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15569/config.ini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7519>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:38:25 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Dec 2009 19:38:25 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260905905.7.0.908200248021.issue3588@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

python-config (or python3-config for python 3.x) is the best way to get 
this information in recent versions of python (IIRC 2.6 or newer)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:38:49 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 19:38:49 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1260905929.74.0.329268594648.issue7516@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

This issue (and the patch) is to warn the tester that the flags and
environment variables are ignored.

Sorry for the DeprecationWarning noise, it is some silly test on my sandbox.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:45:52 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 19:45:52 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260906352.69.0.0712533077578.issue7491@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Note: test_py3kwarn fails, probably since r76794.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:52:28 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Dec 2009 19:52:28 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260903379.83.0.360315644527.issue7517@psf.upfronthosting.co.za>
Message-ID: <1260906748.41.0.953558887251.issue7517@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Almost prioritized to low as there has been talk in the past of not even 
supporting frozen modules by default. The tool should either get fixed or 
removed depending on how people feel.

----------
nosy: +brett.cannon
priority:  -> normal
stage:  -> needs patch
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:53:44 2009
From: report at bugs.python.org (Patrick Stinson)
Date: Tue, 15 Dec 2009 19:53:44 +0000
Subject: [issue7517] freeze.py not ported to python3
In-Reply-To: <1260906748.41.0.953558887251.issue7517@psf.upfronthosting.co.za>
Message-ID: <94ef510912151153g39a55bc4l6430db9ff33345fa@mail.gmail.com>


Patrick Stinson <patrickkidd at gmail.com> added the comment:

Interesting. I found it incredibly useful. I would love to fix the port (if
I find the time, of course :().

On Tue, Dec 15, 2009 at 12:52 PM, Brett Cannon <report at bugs.python.org>wrote:

>
> Brett Cannon <brett at python.org> added the comment:
>
> Almost prioritized to low as there has been talk in the past of not even
> supporting frozen modules by default. The tool should either get fixed or
> removed depending on how people feel.
>
> ----------
> nosy: +brett.cannon
> priority:  -> normal
> stage:  -> needs patch
> type: compile error -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7517>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15570/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7517>
_______________________________________
-------------- next part --------------
Interesting. I found it incredibly useful. I would love to fix the port (if I find the time, of course :().<br><br><div class="gmail_quote">On Tue, Dec 15, 2009 at 12:52 PM, Brett Cannon <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>
Brett Cannon &lt;<a href="mailto:brett at python.org">brett at python.org</a>&gt; added the comment:<br>
<br>
Almost prioritized to low as there has been talk in the past of not even<br>
supporting frozen modules by default. The tool should either get fixed or<br>
removed depending on how people feel.<br>
<br>
----------<br>
nosy: +brett.cannon<br>
priority: ??-&gt; normal<br>
stage: ??-&gt; needs patch<br>
type: compile error -&gt; behavior<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/issue7517" target="_blank">http://bugs.python.org/issue7517</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Dec 15 20:57:27 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 15 Dec 2009 19:57:27 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1260907047.99.0.544939877402.issue7516@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Instead of just warning the user, wouldn't it be better to add proper
support for inheriting the env vars and other Python command line flags ?

Whether or not to use -E can be determined via the test module name.

The -3 flag and others can be queried via sys.flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Tue Dec 15 21:00:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Dec 2009 20:00:30 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1260907230.27.0.986456076944.issue7518@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Incidentally, the build failure described earlier can be fixed by creating python.exe with:

gcc -u _PyMac_Error -o python.exe Modules/python.o -ldl -Wl,-force_load,libpython2.7.a -framework CoreFoundation

instead of with:

gcc -u _PyMac_Error -o python.exe Modules/python.o libpython2.7.a -ldl -framework CoreFoundation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Tue Dec 15 22:16:08 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9sar_Izurieta?=)
Date: Tue, 15 Dec 2009 21:16:08 +0000
Subject: [issue7520] Incorrect handling of nested calss
In-Reply-To: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
Message-ID: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>


New submission from C?sar Izurieta <cesar at caih.org>:

I was using a function that has a nested urllib.quote. I need to double 
quote a value. When running this through the 2to3 tool, the nested call 
never got substituted.

Initial:    urllib.quote(urllib.quote(s))
2to3 ouput: urllib.parse.quote(urllib.quote(s))
Expected:   urllib.parse.quote(urllib.parse.quote(s))

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: doublequote.py
messages: 96465
nosy: cesarizu
severity: normal
status: open
title: Incorrect handling of nested calss
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15571/doublequote.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7520>
_______________________________________

From report at bugs.python.org  Tue Dec 15 22:33:14 2009
From: report at bugs.python.org (flox)
Date: Tue, 15 Dec 2009 21:33:14 +0000
Subject: [issue7520] Incorrect handling of nested calss
In-Reply-To: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
Message-ID: <1260912794.55.0.674447973255.issue7520@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

It seems to behave correctly on 2.7 and 3.1 (svn versions).

$ ./python Tools/scripts/2to3 ../doublequote.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored ../doublequote.py
--- ../doublequote.py (original)
+++ ../doublequote.py (refactored)
@@ -1,5 +1,5 @@
-import urllib
+import urllib.request, urllib.parse, urllib.error
 
 def doublequote(s):
-	return urllib.quote(urllib.quote(s))
+	return urllib.parse.quote(urllib.parse.quote(s))
 
RefactoringTool: Files that need to be modified:
RefactoringTool: ../doublequote.py

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7520>
_______________________________________

From report at bugs.python.org  Tue Dec 15 22:46:08 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9sar_Izurieta?=)
Date: Tue, 15 Dec 2009 21:46:08 +0000
Subject: [issue7520] Incorrect handling of nested calss
In-Reply-To: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
Message-ID: <1260913568.2.0.49574625186.issue7520@psf.upfronthosting.co.za>


C?sar Izurieta <cesar at caih.org> added the comment:

Thanks for testing this. I guess I'll separate those now. But it's good 
to know it is fixed in the latest version.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7520>
_______________________________________

From report at bugs.python.org  Tue Dec 15 23:02:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Dec 2009 22:02:57 +0000
Subject: [issue7520] Incorrect handling of nested calss
In-Reply-To: <1260911767.95.0.303023073707.issue7520@psf.upfronthosting.co.za>
Message-ID: <1260914577.55.0.344953912802.issue7520@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> 2to3 - does not translate urllib2 to urllib.request correctly for function/method argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7520>
_______________________________________

From report at bugs.python.org  Tue Dec 15 23:06:44 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Tue, 15 Dec 2009 22:06:44 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1260914804.79.0.240778692864.issue6922@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

It seems that on my Fedora 11 AMD X86_64, the problem still exists. In 
test_codecs.UTF32Test, test_handlers() seems to run forever, gobbling 
memory to 99+% and then activating swap until it fills up swap.

tested by 
  svn up -r 74869
  rm /tmp/pynexttest
  .python -Ebb -Lib/tests/regrtest.py -vvs test_codecs

disabling test_handlers() in UTF32Test allows the test to pass and it 
completes very fast. It is puzzling that UTF16Test test_handlers works 
with what looks like similar code in unidoceobject.c

~jim

----------
nosy: +jgsack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Tue Dec 15 23:13:37 2009
From: report at bugs.python.org (=?utf-8?q?Ricardo_S=C3=A1nchez-S=C3=A1ez?=)
Date: Tue, 15 Dec 2009 22:13:37 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260915217.23.0.188381175498.issue3588@psf.upfronthosting.co.za>


Ricardo S?nchez-S?ez <agentriot at gmail.com> added the comment:

Thank you! That's much more convenient.

So maybe then this bug report should be closed without a fix, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Tue Dec 15 23:19:15 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Tue, 15 Dec 2009 22:19:15 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1260915555.79.0.913362236911.issue6922@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

Clarification of my last message (msg96468):

The test_handler in the current revision (76850) also exhibits the same 
memory-gobbling behavior. I only refered to -r 74869 because that's where 
the test was introduced, ostensibly to verify the patch to 
unicodeobject.c. 

~jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Wed Dec 16 01:27:51 2009
From: report at bugs.python.org (John Millikin)
Date: Wed, 16 Dec 2009 00:27:51 +0000
Subject: [issue7521] PyEval_GetRestricted should be removed from C API
	reference
In-Reply-To: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
Message-ID: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

In
<http://docs.python.org/3.1/c-api/reflection.html#PyEval_GetRestricted>,
the PyEval_GetRestricted() procedure does not exist. HISTORY indicates
it was removed during the 3.0 development cycle. It ought to be removed
from the docs as well.

----------
assignee: georg.brandl
components: Documentation
messages: 96471
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: PyEval_GetRestricted should be removed from C API reference
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7521>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:14:26 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 16 Dec 2009 02:14: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: <1260929666.15.0.146320525614.issue2698@psf.upfronthosting.co.za>


Changes by Craig McQueen <ces-pub at mcqueen.id.au>:


----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:26:01 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 16 Dec 2009 02:26:01 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1260930361.91.0.559488814163.issue6377@psf.upfronthosting.co.za>


Changes by Craig McQueen <ces-pub at mcqueen.id.au>:


----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:55:03 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Wed, 16 Dec 2009 02:55:03 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1260932103.18.0.530720932221.issue7205@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

On my Fedora 11 AMD x86_64 system, it appears the deadlock still occurs 
(up to the limit of my patience, ie: several minutes). If I reduce to say 
3, I can get the test to succeed sometimes.

Observed in: trunk 
  -r 76850 (latest)
  -r 75818 (first occurrence of testThreading in test-bz2.py)

but not -r 75817

~jim

----------
nosy: +jgsack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:03:05 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Wed, 16 Dec 2009 03:03:05 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1260932585.41.0.756238005916.issue7396@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

Thanks, it seems to work now. 

My test method uses the command format
  ./python -Ebb Lib/test/regrtest.py -s test_calendar

Sorry for the delayed response, I discovered problems with 
  test_bz2
  test_codecs
which I wanted to confirm was real rather than my test procedure.

~jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:27:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Dec 2009 03:27:46 +0000
Subject: [issue7515] Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
In-Reply-To: <1260897818.56.0.929977645023.issue7515@psf.upfronthosting.co.za>
Message-ID: <1afaf6160912151927o37afa173v625dff6457940ef7@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Kill it.

2009/12/15 R. David Murray <report at bugs.python.org>:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> I see no sign that the resource is actually used by the lib2to3 test
> suite, though it looks like there would be an opportunity for it to do
> so (tests that are currently unconditionally skipped by
> Lib/test/test_lib2to3).
>
> Either the resource should be deleted from the help section of regrtest,
> or it should be added to the list of resources and used by test_lib2to3.
> ?I'll let the determination of which up to Benjamin.
>
> ----------
> assignee: ?-> benjamin.peterson
> nosy: +benjamin.peterson, r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7515>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7515>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:29:53 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Dec 2009 03:29:53 +0000
Subject: [issue7515] Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"
In-Reply-To: <1260896515.31.0.944958562968.issue7515@psf.upfronthosting.co.za>
Message-ID: <1260934193.45.0.891645385205.issue7515@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done in r76851.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7515>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:37:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Dec 2009 03:37:14 +0000
Subject: [issue7491] metaclass __cmp__ is ignored
In-Reply-To: <1260719927.85.0.160252441292.issue7491@psf.upfronthosting.co.za>
Message-ID: <1260934634.78.0.249995105533.issue7491@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76852.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7491>
_______________________________________

From report at bugs.python.org  Wed Dec 16 08:00:47 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Wed, 16 Dec 2009 07:00:47 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1260946847.69.0.913367221397.issue7396@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

Update: I was doing something wrong and getting false failures. 

I forgot to do ./configure and make after major revision-switches so the 
failures I was seeing in bz2 and codecs (and others, :-[ ) was bogus.

Repeating the main message, though:
 The regrtest patch seems ok

~jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________

From report at bugs.python.org  Wed Dec 16 08:06:51 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Wed, 16 Dec 2009 07:06:51 +0000
Subject: [issue7205] bz2file deadlock
In-Reply-To: <1256507754.86.0.545134749943.issue7205@psf.upfronthosting.co.za>
Message-ID: <1260947211.32.0.195917176799.issue7205@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

IMPORTANT Correction: Please disregard msg96472. 

I was forgetting to do .configure and make, and evidently getting bogus 
failures.

test_bz2 works fine now, ..sorry for the false alarm.

~jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7205>
_______________________________________

From report at bugs.python.org  Wed Dec 16 08:14:19 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Wed, 16 Dec 2009 07:14:19 +0000
Subject: [issue6922] Interpreter hangs up while trying to decode invalid utf32
	stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1260947659.63.0.344138722725.issue6922@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

IMPORTANT Correction: Please disregard msg 96468 & 96470.

I was forgetting to do ./configure and make, and evidently getting bogus 
failures.

test_codecs works fine now, ..sorry for the false alarm.

~jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________

From report at bugs.python.org  Wed Dec 16 08:52:42 2009
From: report at bugs.python.org (Leo)
Date: Wed, 16 Dec 2009 07:52:42 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>


New submission from Leo <dontsendleospam at gmail.com>:

The following code should just work:

import random
random.choice(set(range(5)))

instead the output is TypeError:

TypeError: 'set' object does not support indexing

The algorithm in random.choice requires a sequence, but the semantics of
choice do not, and should not, require a sequence. 

The code should be changed to convert the input to a sequence instead.

Cheers,
Leo.

----------
components: Library (Lib)
messages: 96480
nosy: lleeoo
severity: normal
status: open
title: random.choice should accept a set as input
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:51:24 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 16 Dec 2009 10:51:24 +0000
Subject: [issue6654] Add "path" to the xmrlpc dispatcher method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1260960684.81.0.10089884443.issue6654@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed revision 76855 to py3k

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:00:39 2009
From: report at bugs.python.org (lekma)
Date: Wed, 16 Dec 2009 11:00:39 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

It would be nice to have those.
See http://udrepper.livejournal.com/20407.html for background.

----------
components: Library (Lib)
messages: 96482
nosy: lekma
severity: normal
status: open
title: add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:57:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 16 Dec 2009 11:57:05 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1260964625.98.0.628064150141.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think we have two issues here:

First, the default install of VS Express does not support 64-bit tools,
so distutils cannot work with a 64-bit Python install. I verified that
it _does_ work with a 32-bit Python install.


Second, it is possible to install 64-bit tools from the SDK
(See:http://www.mathworks.com/support/solutions/en/data/1-6IJJ3L/index.html?solution=1-6IJJ3L),
but then some paths are broken in the vcvarsall.bat script:

The script is looking for bin\amd64\vcvarsamd64.bat, the actual path is
bin\vcvarsamd64.bat. The attached diff solves the problem for me, but
someone should verify that the paths are indeed broken when doing the
SDK install as described above.

----------
keywords: +patch
Added file: http://bugs.python.org/file15572/vcvars.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:31:35 2009
From: report at bugs.python.org (lekma)
Date: Wed, 16 Dec 2009 12:31:35 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1260966695.76.0.589213483613.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

First attempt, against trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file15573/Issue7523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:43:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Dec 2009 12:43:57 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260967437.24.0.461236102337.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch to add expm1.  Rather than putting the code in pymath.c, 
which is the wrong place (see issue #7518), I've added a new file 
Modules/_math.c for this;  log1p, atanh, etc. should also eventually be 
moved from pymath.c into this file.

I'm fairly confident that the maths and numerics are okay, but less 
confident about my changes to the build structure;  if anyone has a chance 
to test this patch, especially on Windows, I'd welcome feedback.  I've 
tested it on OS X, and will test on Linux.

----------
Added file: http://bugs.python.org/file15574/expm1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:50:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Dec 2009 12:50:58 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1260967858.06.0.720611778482.issue7522@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This would be a new feature, so would have to wait for Python 2.7 / 3.2  
(2.6 is only receiving bugfixes).

----------
assignee:  -> rhettinger
nosy: +mark.dickinson, rhettinger
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Wed Dec 16 14:02:43 2009
From: report at bugs.python.org (Nir Aides)
Date: Wed, 16 Dec 2009 13:02:43 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1260968563.94.0.947814596468.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Right, using the io module makes GzipFile as fast as zcat.

I submit a new patch this time for Python 2.7, however, it is not a 
module rewrite, but again minimal refactoring.

GzipFile is now derived of io.BufferedRandom, and as result the 
functionality of GzipFile changed since it used to behave differently 
than io classes. For example write() did not return number of bytes 
written, etc... Also, I hacked it a little to make it work with a raw 
stream which is either readable or writable but not both. If it is 
unacceptable, or if you prefer a module rewrite, I don't mind discussing 
and evolving this further.

----------
Added file: http://bugs.python.org/file15575/gzip_7471_io_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Wed Dec 16 15:26:41 2009
From: report at bugs.python.org (Gnep)
Date: Wed, 16 Dec 2009 14:26:41 +0000
Subject: [issue7524] Freeze bug with xml.dom
In-Reply-To: <1260973601.45.0.672751383374.issue7524@psf.upfronthosting.co.za>
Message-ID: <1260973601.45.0.672751383374.issue7524@psf.upfronthosting.co.za>


New submission from Gnep <jass.zhao at gmail.com>:

I'm using python 2.4.3 on centos5.3.

A simple py script contains only one line of?

[karen at gnep:~/test]$ cat dom.py
from xml.dom import minidom

Then freeze this script and run the binary:

[karen at gnep:~/test]$ ./dom
Traceback (most recent call last):
  File "dom.py", line 1, in ?
    from xml.dom import minidom
ImportError: No module named dom

----------
components: Demos and Tools
messages: 96488
nosy: Gnep
severity: normal
status: open
title: Freeze bug with xml.dom
type: compile error
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7524>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:09:24 2009
From: report at bugs.python.org (xiscu)
Date: Wed, 16 Dec 2009 15:09:24 +0000
Subject: [issue7525] Yield example doesn't work as is explained in the
	documentation
In-Reply-To: <1260976164.25.0.0113295033016.issue7525@psf.upfronthosting.co.za>
Message-ID: <1260976164.25.0.0113295033016.issue7525@psf.upfronthosting.co.za>


New submission from xiscu <xiscu at email.de>:

In the documentation the is:

...
>>>generator.throw(TypeError, "spam")
TypeError('spam',)
>>> generator.close()
Don't forget to clean up when 'close()' is called.
...

I'm getting:
>>>generator.throw(TypeError, "spam")
TypeError('spam',)
>>> generator.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: generator ignored GeneratorExit
...

My proposal here is yield_example_1.py

Thanks

----------
assignee: georg.brandl
components: Documentation
files: yield_example_1.py
messages: 96489
nosy: georg.brandl, xiscu
severity: normal
status: open
title: Yield example doesn't work as is explained in the documentation
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file15576/yield_example_1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7525>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:26:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Dec 2009 15:26:16 +0000
Subject: [issue7396] regrtest single: iterator not subscriptable
In-Reply-To: <1259211015.26.0.0435309499535.issue7396@psf.upfronthosting.co.za>
Message-ID: <1260977176.62.0.851453210459.issue7396@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for testing.  Note that you don't need to use -s to run a single
test.  You can specify a list of tests to run on the regrtest command
line, which can be just one test.  -s for running all the tests one at a
time so that you restart the interpreter between each one (ie: when
using -s you issue the regrtest -s command multiple times...)

Committed to trunk in r76856 and py3k in r76857.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7396>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:43:19 2009
From: report at bugs.python.org (kurt)
Date: Wed, 16 Dec 2009 16:43:19 +0000
Subject: [issue7526] tkinter menubutton underline behaviour varies between
	tkinter * and tkinter.ttk *
In-Reply-To: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>
Message-ID: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>


New submission from kurt <kurt.forrester.fec at gmail.com>:

I am using the Menubutton to provide an accelerator effect via the
underline option.

When I import the basic widget via from tkinter import * the widget
performs as expected (F_ile) is activated on pressing Alt+F and the menu
is presented.

Conversely when using the ttk widget via "from tkinter.ttk import *" the
Alt+F key combination does not activate the Menubutton widget. In
addition to this pressing F10 does not activate the menubar.

This is on Ubuntu Karmic, Python 3.1.1+ (r311:74480, Nov  2 2009,
14:49:22) [GCC 4.4.1] on linux2

By commenting out the import of the Menubutton at the top of the script
you can hopefully see the behaviour I have described. This
ApplicationMenu class is called in another script (self.root.MenuBar =
ApplicationMenu(self.root)).

----------
components: Tkinter
files: __init__.py
messages: 96491
nosy: kurtforrester
severity: normal
status: open
title: tkinter menubutton underline behaviour varies between tkinter * and tkinter.ttk *
versions: Python 3.1
Added file: http://bugs.python.org/file15577/__init__.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7526>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:57:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Dec 2009 17:57:27 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1260986247.55.0.210640254886.issue7522@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The underlying data structure for sets doesn't lend itself to an
efficient method of random selection.  It is best for the programmer to
explictly convert to a sequence and then make the random selection (that
way the conversion cost isn't hidden). 

If you don't mind the inefficiency of an implicit conversion to a list,
you can use "random.sample(s, 1)[0]".  If only an arbitrary element is
needed, use "x=next(iter(s))" to non-destructively fetch the first element.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:14:52 2009
From: report at bugs.python.org (Forest Bond)
Date: Wed, 16 Dec 2009 19:14:52 +0000
Subject: [issue7527] Standard Library documentation fails to mention that
	string.Formatter, etc. are new in Python 2.6
In-Reply-To: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
Message-ID: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>


New submission from Forest Bond <forest at alittletooquiet.net>:

This page:

  http://docs.python.org/library/string.html

... should mention that the Formatter class and any associated functions
are new in Python 2.6.

----------
assignee: georg.brandl
components: Documentation
messages: 96493
nosy: forest_atq, georg.brandl
severity: normal
status: open
title: Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7527>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:18:11 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Dec 2009 19:18:11 +0000
Subject: [issue7527] Standard Library documentation fails to mention that
	string.Formatter, etc. are new in Python 2.6
In-Reply-To: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
Message-ID: <1260991091.2.0.0340012283698.issue7527@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

8.1.2 does start with "Starting in Python 2.6", although I suppose there
could be a versionadded tag.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7527>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:22:04 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Dec 2009 19:22:04 +0000
Subject: [issue7521] PyEval_GetRestricted should be removed from C API
	reference
In-Reply-To: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
Message-ID: <1260991324.05.0.0223229651908.issue7521@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7521>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:23:11 2009
From: report at bugs.python.org (Forest Bond)
Date: Wed, 16 Dec 2009 19:23:11 +0000
Subject: [issue7527] Standard Library documentation fails to mention that
	string.Formatter, etc. are new in Python 2.6
In-Reply-To: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
Message-ID: <1260991391.64.0.448703028536.issue7527@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Ah, I didn't see it there.  Oh well, do what seems right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7527>
_______________________________________

From report at bugs.python.org  Wed Dec 16 21:21:22 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Dec 2009 20:21:22 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1260994882.26.0.870424904497.issue3588@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To be honest: I don't know.

Tarek: do you think LINKFORSHARED should contain a value that works 
outside of Python's build environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Wed Dec 16 21:40:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Dec 2009 20:40:36 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1260996036.32.0.672014686165.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I committed the patch for expm1 in r76861 (trunk) and r76863 (py3k), with 
one small change:  instead of using 2 * exp(x/2) * sinh(x/2), expm1 is now 
computed using a method due to Kahan that involves only exp and log.  This 
seems a little safer, and guards against problems on platforms with a 
naive implementation of sinh.  (I *hope* no such platforms exist, but 
suspect that's wishful thinking. :-)

Thanks to Eric Smith for testing the build system changes on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Wed Dec 16 22:30:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 16 Dec 2009 21:30:22 +0000
Subject: [issue7524] Freeze bug with xml.dom
In-Reply-To: <1260973601.45.0.672751383374.issue7524@psf.upfronthosting.co.za>
Message-ID: <1260999022.04.0.616020279947.issue7524@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python 2.4 is no longer support. Unless you can reproduce the bug for
2.6, it should be closed as "won't fix".

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7524>
_______________________________________

From report at bugs.python.org  Wed Dec 16 23:17:06 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 16 Dec 2009 22:17:06 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1261001826.94.0.901265120774.issue7518@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

In general those functions has to be part of, lets call it "python
runtime/portable interface" . With current build system you may create a
build-in module lets call it mathport and to add some functions .
To the list a will add function atan2 from math module. I don't know why
the test cases for cmath pass on platforms with non-expected behaviour
of atan2-may be build boots lack those platforms. To me is expected for
all platforms on which "tanh preserves the sign of zero" configure test
case fail atan2 to fail too and cmath functions that use atan2 to fail.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Wed Dec 16 23:31:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Dec 2009 22:31:20 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1261002680.78.0.818995611941.issue7518@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For the recently added expm1 function (see issue #3366), I've put the 
substitute code in a new file Modules/_math.c, that's linked into math.so.  
I plan to move the other substitute libm functions from pymath.c into this 
file, and to link _math.c into the cmath module as well as the math 
module.

Roumen, I'm not sure I understand your comments about atan2.  Is there 
some link between atan2 and tanh that I'm not aware of?  Which platforms 
have unexpected behaviour for atan2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Thu Dec 17 00:41:41 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 16 Dec 2009 23:41:41 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1261006901.95.0.963371180163.issue3745@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

What about inconsistent module build - as is reported some platform
build sha256 module that support  unicode but most it is not build if
openssl is version 0.8+. Same for sha512 module.
If unicode for hashlib is not acceptable for trunk than why is not build
always sha{256|512}  without to check for openssl version number ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Thu Dec 17 01:16:53 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 17 Dec 2009 00:16:53 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1261009013.38.0.271319715145.issue7518@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

May be is good to add depends=['_math.h'], for modules in setup.py.

About atan2 - lets see comments in mathmodule and configure test. The
cmath test case pass on freebsd as buildbot is for for 7.2. What about
freebsd 6.2 ?
Also I don't think that python cmath tests will pass with MSVC before
8.0. It is based on my tests in the past with different MSVC runtimes.
In my notes for msvc 7.0.2600 result of 2.*atan2(-0,1.4142135623730951)
is 0(zero) instead -0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Thu Dec 17 01:44:40 2009
From: report at bugs.python.org (Russell Owen)
Date: Thu, 17 Dec 2009 00:44:40 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1261010680.75.0.676649420891.issue2624@psf.upfronthosting.co.za>


Changes by Russell Owen <reowen at users.sourceforge.net>:


----------
nosy: +reowen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2624>
_______________________________________

From report at bugs.python.org  Thu Dec 17 03:26:36 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Thu, 17 Dec 2009 02:26:36 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1261016796.99.0.894581889458.issue7108@psf.upfronthosting.co.za>


James G. sack (jim) <jgsack at users.sourceforge.net> added the comment:

test_commands test_getstatus also fails on linux with SELinux enabled

On gnu/linux, info ls reports:
"""
    Following the file mode bits is a single character that specifies
     whether an alternate access method such as an access control list
     applies to the file.  When the character following the file mode
     bits is a space, there is no alternate access method.  When it is
     a printing character, then there is such a method.

     GNU `ls' uses a `.' character to indicate a file with an SELinux
     security context, but no other alternate access method.

     A file with any other combination of alternate access methods is
     marked with a `+' character.
"""

So it sounds like the previous patch could be further generalized to (say)
"""
-                  \+?          # It may have ACLs.
+                  [.+@]?       # It may have alt access (SELinux, ACLs 
or metadata ('@' OS X).
"""

~jim

----------
nosy: +jgsack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7108>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:24:53 2009
From: report at bugs.python.org (lekma)
Date: Thu, 17 Dec 2009 07:24:53 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261034693.67.0.63898852806.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

better patch (mainly test refactoring).
still against trunk.

should I provide one against py3k?

----------
components: +IO
Added file: http://bugs.python.org/file15578/Issue7523_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:35:37 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 17 Dec 2009 08:35:37 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

When I ported gmpy to Python 3.x, I began to use
PyLong_AsLongAndOverflow frequently. I found the code to slightly faster
and cleaner than using PyLong_AsLong and checking for overflow. I had
several code fragments that looked like:

#if PY_MAJOR_VERSION == 2
    if(PyInt_Check(b)) {
        temp = PyInt_AS_LONG(b));
        Do stuff with temp.
    }
#endif
    if(PyLong_Check(b)) {
#if PY_MAJOR_VERSION == 3
        temp = PyLong_AsLongAndOverflow(b, &overflow);
        if(overflow) {
#else
        temp = PyLong_AsLong(b);
        if(PyErr_Occurred()) {
            PyErr_Clear();
#endif
            Convert b to an mpz.
        } else {
            Do stuff with temp.
        }
    }

I wanted to use the PyLong_AsLongAndOverflow method with Python 2.x so I
extracted the code for PyLong_AsLongAndOverflow, tweeked it to accept
either PyInt or PyLong, and called it PyIntOrLong_AsLongAndOverflow. I
also defined PyIntOrLong_Check.

The same code fragment now looks like:

    if(PyIntOrLong_Check(b)) {
        temp = PyIntOrLong_AsLongAndOverflow(b, &overflow);
        if(overflow) {
            Convert b to an mpz.
        } else {
            Do stuff with temp.
        }
    }

Is it possible to include a py3intcompat.c file with Python 2.7 that
provides this function (and possibly others) for extension authors to
include with their extension? A previous example is pymemcompat.h which
was made available in the Misc directory.

I'm specifically not in favor of adding it to the Python 2.7 API but
just in providing a file for extension authors to use. I've attached a
initial version that compiles successfully with Python 2.4+.

I'm willing to add additional functions, documentation, etc.

----------
components: Extension Modules
messages: 96505
nosy: casevh
severity: normal
status: open
title: Provide PyLong_AsLongAndOverflow compatibility to Python 2.x
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:36:38 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 17 Dec 2009 08:36:38 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261038998.77.0.348982510745.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Attached py3intcompat.c

----------
Added file: http://bugs.python.org/file15579/py3intcompat.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:53:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 08:53:37 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1261040017.28.0.0309314211423.issue7518@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So the configure test for tanh(-0.0) is purely informational:  it doesn't 
affect the behaviour of the built Python in any way.  I agree that the 
test is imperfect, in that if atan2 is also non-conformant on the given 
platform then the sign issue with tanh may go undetected, but all that 
happens in that case is that we get a bogus 'preserves sign of -0 ... yes' 
message in the configure output.

The wrapper for atan2 in Modules/mathmodules.c is a separate issue; it 
should ensure that we get the right behaviour for atan2 on all platforms,
including msvc 7.0.  I can't immediately see any reason why it wouldn't be 
working as intended.

> I don't think that python cmath tests will pass with MSVC before
8.0.

Which test(s) do you think will fail?

> May be is good to add depends=['_math.h'], for modules in setup.py.

Good point---thanks!  Done in r76865 (trunk), r76867 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Thu Dec 17 10:05:04 2009
From: report at bugs.python.org (Chris Withers)
Date: Thu, 17 Dec 2009 09:05:04 +0000
Subject: [issue7529] StreamHandler does not live in logging.Handlers
In-Reply-To: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
Message-ID: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

http://docs.python.org/library/logging.html#module-logging.handlers

...explains that StreamHandler lives in logging but then the class docs
say logging.handlers.

Georg, if this isn't trivial for you to fix, re-assign it to me and I'll
make the changes when I get a chance :-)

cheers,

Chris

----------
assignee: georg.brandl
components: Documentation
messages: 96508
nosy: cjw296, georg.brandl
severity: normal
status: open
title: StreamHandler does not live in logging.Handlers
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 10:09:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 09:09:18 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1261040958.22.0.93344381204.issue7497@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The configure test for enabled POSIX semaphores is now failing for me on 
OS X 10.6:  the test produces

sem_open: Permission denied

----------
assignee:  -> mark.dickinson
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Thu Dec 17 11:11:09 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Dec 2009 10:11:09 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1261044669.09.0.602312991973.issue3588@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I agree with Ronald: making sure all variables in Makefile provide
values that can work in any environment just because distutils offers an
API to read them would be a major pain.

What is planned is to remove sysconfig from distutils, and have it in
the stdlib, with a private module built when ./configure is called, that
would contain these variables. 

And maybe we could filter out some variables in this process to keep
only the ones that can be used by code in all environments.

IOW, if python-config provides what you need, LINKFORSHARED could be
filtered out so the API cannot return it.

----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:29:01 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 11:29:01 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261049341.79.0.0158090318817.issue7381@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch updated to backport r51536 in trunk.
It makes "python -3" happier (do not compare None >= 0).

----------
Added file: http://bugs.python.org/file15580/issue7381_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:29:38 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 11:29:38 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261049378.01.0.596650598919.issue7381@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15581/issue7381_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:29:58 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 11:29:58 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261049398.43.0.329443569573.issue7381@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15447/issue7381_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:30:02 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 11:30:02 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261049402.06.0.690403781095.issue7381@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15446/issue7381.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Thu Dec 17 13:40:49 2009
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Thu, 17 Dec 2009 12:40:49 +0000
Subject: [issue7530] doc of multiprocessing.managers is wrong (server_forever)
In-Reply-To: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
Message-ID: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>


New submission from Stefan Schwarzburg <stefan.schwarzburg at googlemail.com>:

The documentation of multiprocessing.managers.BaseManager 
(http://docs.python.org/library/multiprocessing.html#module-multiprocessing.managers)
refers to a method "serve_forever". This method is only available at the
server object inside BaseManager (e.g.
manager.get_server().serve_forever() ).

I would rephrase the text to:
"Once created one should call start() or get_server().serve_forever()" 

instead of the current phrase:
"Once created one should call start() or serve_forever()" 

The method description for "serve_forever()" should be removed from
BaseManager, instead there should be an additional section about the
server object returned by get_server().

----------
assignee: georg.brandl
components: Documentation
messages: 96512
nosy: georg.brandl, schwarz
severity: normal
status: open
title: doc of multiprocessing.managers is wrong (server_forever)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7530>
_______________________________________

From report at bugs.python.org  Thu Dec 17 13:44:35 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Dec 2009 12:44:35 +0000
Subject: [issue7529] StreamHandler does not live in logging.Handlers
In-Reply-To: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
Message-ID: <1261053875.32.0.0997478750404.issue7529@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 14:13:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Dec 2009 13:13:27 +0000
Subject: [issue7530] doc of multiprocessing.managers is wrong (server_forever)
In-Reply-To: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
Message-ID: <1261055607.28.0.0199967586368.issue7530@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7530>
_______________________________________

From report at bugs.python.org  Thu Dec 17 14:50:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Dec 2009 13:50:47 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261057847.5.0.702772987427.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A couple of things:
- the test shouldn't be marked as Linux-specific since perhaps these
constants will be supported by other systems some day
- when importing fcntl, bear in mind that some systems don't have this
module (e.g. Windows), so you should catch and silence the ImportError

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:32:21 2009
From: report at bugs.python.org (John Gardner)
Date: Thu, 17 Dec 2009 14:32:21 +0000
Subject: [issue7531] datetime.timedelta doc has incorrect output
In-Reply-To: <1261060341.46.0.00177327866162.issue7531@psf.upfronthosting.co.za>
Message-ID: <1261060341.46.0.00177327866162.issue7531@psf.upfronthosting.co.za>


New submission from John Gardner <python.20.huxoll at spamgourmet.com>:

The output example for timedelta in datetime package has the wrong 
output for the supplied commands.

For example:
>>> ten_years, ten_years.days // 365
(datetime.timedelta(3650), 10)
should be:
>>> ten_years, ten_years.days 
(datetime.timedelta(3650), 3650)
(or perhaps, days changed to years.

It's very misleading to have these strange numbers as output.

Also, the comments to the right don't seem to be relevant.

----------
assignee: georg.brandl
components: Documentation
messages: 96514
nosy: georg.brandl, huxoll
severity: normal
status: open
title: datetime.timedelta doc has incorrect output
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7531>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:37:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 14:37:29 +0000
Subject: [issue7531] datetime.timedelta doc has incorrect output
In-Reply-To: <1261060341.46.0.00177327866162.issue7531@psf.upfronthosting.co.za>
Message-ID: <1261060649.96.0.102835190977.issue7531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Perhaps you're misreading the '//'?  It's a division operator, not the
start of a comment.

The example works fine for me:

dickinsm at alberti:~> python2.6
Python 2.6.2 (r262:71600, Aug 26 2009, 09:40:44)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> year = timedelta(days=365)
>>> ten_years = 10 * year
>>> ten_years, ten_years.days // 365
(datetime.timedelta(3650), 10)

----------
nosy: +mark.dickinson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7531>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:54:00 2009
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Dec 2009 14:54:00 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1261061640.18.0.225026668136.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I needed a new Windows VM image anyway, so I can now confirm that the
paths of a fresh VS Express + SDK 64-bit tools install are broken as
described above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:55:03 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 17 Dec 2009 14:55:03 +0000
Subject: [issue7529] StreamHandler does not live in logging.Handlers
In-Reply-To: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
Message-ID: <1261061703.17.0.595492600609.issue7529@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fixed in trunk (r76869). I had to add a .. currentmodule::logging to the
file, even though this is the first currentmodule directive in the file.
Is this a Sphinx glitch? Shouldn't the current module be set by the
module directive until changed via a currentmodule directive? Marking as
pending and assigning to Georg to confirm.

----------
assignee: vinay.sajip -> georg.brandl
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:08:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 15:08:07 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261062487.35.0.75048278253.issue7528@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm specifically not in favor of adding it to the Python 2.7 API.

Out of curiosity, why not?  It seems like a reasonable addition to me.

I'd continue to call it simply PyLong_AsLongAndOverflow, though.  I note
that in 2.x, PyLong_AsLong accepts both ints and longs, so it wouldn't
seem unreasonable for PyLong_AsLongAndOverflow to do so too.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:43:01 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 17 Dec 2009 16:43:01 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261068181.73.0.645131347278.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I don't want it to be a 2.7-only feature. I'm trying to maintain 
compatibility with 2.4 and later for gmpy. I would be in favor with 
adding it to 2.7 as long as we could still provide a standalone version 
for earlier releases of Python.

I hadn't realized that PyLong_AsLong accepts PyInt also. Given that, 
the name PyLong_AsLongAndOverflow is fine (and easier)!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:54:10 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 16:54:10 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>


New submission from flox <laxyf at yahoo.fr>:

See attached example.

The Classic class should behave like the New-style class.

----------
components: Interpreter Core
files: case_slice.py
messages: 96520
nosy: flox
severity: normal
status: open
title: Extended slicing with classic class behaves strangely
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15582/case_slice.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Thu Dec 17 18:15:52 2009
From: report at bugs.python.org (iamraprap)
Date: Thu, 17 Dec 2009 17:15:52 +0000
Subject: [issue7533] unable to install pycurl in 2.6.4
In-Reply-To: <1261070152.74.0.648717964415.issue7533@psf.upfronthosting.co.za>
Message-ID: <1261070152.74.0.648717964415.issue7533@psf.upfronthosting.co.za>


New submission from iamraprap <rapsys_eacit at yahoo.com>:

first i tried using easy_install pycurl, also set a path to CURL_DIR and
i had error:
   File "setup.py", line 69, in <module>
    assert os.path.isdir(CURL_DIR), "please check CURL_DIR in setup.py"
AssertionError: please check CURL_DIR in setup.py

second attempt, downloaded the 7.19.7 pycurl and built the libcurl.lib
too... but upon installing, i had error again:

[C:\src\build\pycurl\7.19.7]setup.py install
Using curl directory: C:\src\build\pycurl\7.19.7
running install
running build
running build_py
running build_ext
building 'pycurl' extension
error: Unable to find vcvarsall.bat 

please help... :(

----------
components: Build
messages: 96521
nosy: iamraprap
severity: normal
status: open
title: unable to install pycurl in 2.6.4
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7533>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:35:41 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Dec 2009 18:35:41 +0000
Subject: [issue7533] unable to install pycurl in 2.6.4
In-Reply-To: <1261070152.74.0.648717964415.issue7533@psf.upfronthosting.co.za>
Message-ID: <1261074941.9.0.0628762485306.issue7533@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is not a Python error. It simply looks like you didn't set the 
CURL_DIR variable in the setup.py file that came w/ pycurl. If you can't 
figure out how to set the variable then I would ask the pycurl developers 
how to fix this.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7533>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:42:57 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Thu, 17 Dec 2009 18:42:57 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>


New submission from Marcos Donolo <mdonolo at vt.edu>:

I am not getting the expected result for the ** operator on windows,
python 2.6
I do...
a=float('nan')
b=a*a
then b is nan which is right but if I do 
b = a**2 I get.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: (33, 'Domain error')

If I do a**2 on ubuntu, python 2.6 I get nan again.

----------
components: Interpreter Core
messages: 96523
nosy: mdonolo at vt.edu, tim_one
severity: normal
status: open
title: float('nan')**2 != nan.  float('nan')**2 error 33 on windows
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:44:27 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Dec 2009 18:44:27 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261075467.62.0.79534807546.issue7534@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mark.dickinson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:52:15 2009
From: report at bugs.python.org (Leonardo Rochael Almeida)
Date: Thu, 17 Dec 2009 18:52:15 +0000
Subject: [issue7535] logging: Filters on Loggers can't actually filter
	messages on lower levels of the logging hierarchy
In-Reply-To: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>
Message-ID: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>


New submission from Leonardo Rochael Almeida <leorochael at gmail.com>:

A filter added to, say, logging.getLogger('a').addFilter() never gets
the chance to filter messages logged into logging.getLogger('a.b').

On logging.Logger.handle() the current logger filters are called to
check if the message should be processed or not, but the logger parent
filters are not consulted (and this is ok, IMHO, more generic filters
shouldn't clobber messages of more specific loggers).

However, if none of the current filters block the message,
Logger.handle() then calls Logger.callHandlers(), which calls the
handlers of the current logger and of all the parent loggers as long as
each logger in the hierarchy allows the message to propagate. This is
done without consulting the parent loggers filters.

This means parent handlers get called to process log records even if the
parent logger filters would have otherwise blocked them.

Attached is a very crude patch that allows the parent loggers to filter
events before handling them. I'd prefer to simply call the "handle()" 
or "callHandler()" method of the parent loggers recursively, but
couldn't find a way to do this while still preserving the method
signatures AND properly reporting when no handler could be found.

My preference would be to have callHandlers() do the filtering AND
return a number of handlers invoked, including the parent handlers, so
that handle() could report if no handlers could be found.

----------
components: Library (Lib)
files: logging-allow-parent-filtering.diff
keywords: patch
messages: 96524
nosy: leorochael
severity: normal
status: open
title: logging: Filters on Loggers can't actually filter messages on lower levels of the logging hierarchy
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15583/logging-allow-parent-filtering.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7535>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:20:17 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 17 Dec 2009 19:20:17 +0000
Subject: [issue7535] logging: Filters on Loggers can't actually filter
	messages on lower levels of the logging hierarchy
In-Reply-To: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>
Message-ID: <1261077617.61.0.295014465553.issue7535@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This behaviour is by design. Messages logged to logger 'a.b' are not
passed to logger 'a' - they are passed to *the handlers* of logger 'a'
(and so on up until a false value is seen for the logger's 'propagate'
attribute). In this respect, filtering works in the same way as levels
do - for example if logger 'a' has a level of WARNING and logger 'a.b'
has a level of DEBUG, then DEBUG events logged to 'a.b' will still show
up in the logs.

Closing, as it's not a bug, and implementing the alternative would not
be backwards compatible.

----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7535>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:22:03 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 19:22:03 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261077723.85.0.595016860679.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yep.  There's not much consistency in inf/nan handling across platforms, 
though the situation is slowly getting better.  math.pow makes an effort 
to handle these special cases correctly (for some value of correctly), and 
it would probably make some sense to have the builtin pow behave the same 
way.

Would you be interested in contributing a fix?

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:27:47 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Thu, 17 Dec 2009 19:27:47 +0000
Subject: [issue7536] float('inf')**2 != inf
In-Reply-To: <1261078067.84.0.65935543936.issue7536@psf.upfronthosting.co.za>
Message-ID: <1261078067.84.0.65935543936.issue7536@psf.upfronthosting.co.za>


New submission from Marcos Donolo <mdonolo at vt.edu>:

The ** operator produces an error when it gets inf as an argument.
if I try.
>>>a=float('inf')
>>>a*a 
inf
-but if I try 
>>>a**2 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: (34, 'Result too large')
I should get inf too.

----------
components: Interpreter Core
messages: 96527
nosy: mdonolo, tim_one
severity: normal
status: open
title: float('inf')**2 != inf
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7536>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:32:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 19:32:35 +0000
Subject: [issue7536] float('inf')**2 != inf
In-Reply-To: <1261078067.84.0.65935543936.issue7536@psf.upfronthosting.co.za>
Message-ID: <1261078355.03.0.381198623862.issue7536@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is essentially the same issue as issue7534, but for infinities 
instead of nans.  I'm closing this and folding the issue into that one.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
status: open -> closed
superseder:  -> float('nan')**2 != nan.  float('nan')**2 error 33 on windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7536>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:33:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 19:33:29 +0000
Subject: [issue7534] float('nan')**2 != nan. float('inf')**2 != inf.
	float('nan')**2 error 33 on windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261078409.94.0.0201989317141.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closed 7536 as a duplicate of this issue.

----------
title: float('nan')**2 != nan.  float('nan')**2 error 33 on windows -> float('nan')**2 != nan.  float('inf')**2 != inf.  float('nan')**2 error 33 on windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:35:20 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Thu, 17 Dec 2009 19:35:20 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261077723.85.0.595016860679.issue7534@psf.upfronthosting.co.za>
Message-ID: <33a5fc8a0912171135g71307027l88413abc1a758d09@mail.gmail.com>


Marcos Donolo <mdonolo at vt.edu> added the comment:

I will give it a shot.

On Thu, Dec 17, 2009 at 11:22 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Yep.  There's not much consistency in inf/nan handling across platforms,
> though the situation is slowly getting better.  math.pow makes an effort
> to handle these special cases correctly (for some value of correctly), and
> it would probably make some sense to have the builtin pow behave the same
> way.
>
> Would you be interested in contributing a fix?
>
> ----------
> stage:  -> needs patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7534>
> _______________________________________
>

----------
title: float('nan')**2 != nan.  float('inf')**2 != inf.  float('nan')**2 error 33 on windows -> float('nan')**2 != nan. float('nan')**2 error 33 on windows
Added file: http://bugs.python.org/file15584/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________
-------------- next part --------------
I will give it a shot.<br><br><div class="gmail_quote">On Thu, Dec 17, 2009 at 11:22 AM, Mark Dickinson <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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
Yep. ??There&#39;s not much consistency in inf/nan handling across platforms,<br>
though the situation is slowly getting better. ??math.pow makes an effort<br>
to handle these special cases correctly (for some value of correctly), and<br>
it would probably make some sense to have the builtin pow behave the same<br>
way.<br>
<br>
Would you be interested in contributing a fix?<br>
<br>
----------<br>
stage: ??-&gt; needs patch<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/issue7534" target="_blank">http://bugs.python.org/issue7534</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Thu Dec 17 20:39:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 19:39:32 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261078772.19.0.928337357849.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Great!  For math.pow, see the function math_pow in Modules/mathmodule.c;  
some sort of (careful!) cut-and-paste job from there to float_pow in 
Objects/floatobject.c might do the trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:52:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Dec 2009 19:52:38 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261079558.88.0.875113447798.issue7534@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Thu Dec 17 21:36:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 20:36:52 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261082212.04.0.19696566525.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  This doesn't look like something that's easy to fix without affecting existing correct code;  given 
that the behaviour has been around for a while (I'm not sure exactly how long), and that the issue is gone 
in 3.x, I suspect it may not be worth trying.

Analysis:  for classic classes, the ceval loop calls PySequence_GetSlice, which corrects the negative 
indices by adding the length of the sequence  (as described in the docs) and then calls the 
tp_as_sequence->sq_slice slot on the type.  That ends up calling instance_slice (in 
Objects/classobject.c), which discovers that the class doesn't implement __getslice__ and so passes the 
adjusted slice on to the __getitem__ method.

I'm not sure how this could be changed to get the correct behaviour:  PySequence_GetSlice would somehow 
need to know that it was going to end up calling __getitem__ rather than __getslice__.

Raymond, any thoughts?

----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Thu Dec 17 21:42:17 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 20:42:17 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261082537.67.0.165392309217.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Issue #974635 looks like the same thing.  That issue was closed as a 
duplicate of issue #723806, though to my eyes #723806 doesn't look quite 
the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Thu Dec 17 22:02:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 21:02:07 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261083727.3.0.57477021448.issue7442@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm failing to reproduce this (with py3k) on OS X:

Python 3.2a0 (py3k:76866:76867, Dec 17 2009, 09:19:26) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> from decimal import *
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> format(Decimal('1000'), 'n')
'1.000'

The locale command, from the same Terminal prompt, gives me:

LANG="en_IE.UTF-8"
LC_COLLATE="en_IE.UTF-8"
LC_CTYPE="en_IE.UTF-8"
LC_MESSAGES="en_IE.UTF-8"
LC_MONETARY="en_IE.UTF-8"
LC_NUMERIC="en_IE.UTF-8"
LC_TIME="en_IE.UTF-8"
LC_ALL=

Just to be clear, is is true that you still get the same result without 
involving Decimal at all?  That is, am I correct in assuming that:

>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> locale.localeconv()

also gives you that ValueError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Thu Dec 17 22:07:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Dec 2009 21:07:02 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261084022.67.0.6998694189.issue7442@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What are the multibyte strings that mbstowcs is failing to convert?
On my machine, the separators come out as plain ASCII '.' (for thousands) 
and ',' (for the decimal point).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Thu Dec 17 23:03:14 2009
From: report at bugs.python.org (flox)
Date: Thu, 17 Dec 2009 22:03:14 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261087394.06.0.716048717324.issue7532@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Mark,

Thank you for your analysis.

I looked at similar implementation of tp_as_sequence->sq_slice slots in
"stringobject.c" (and tuple, list).
I've added extra controls before the _PySlice_FromIndices call to let it
behave like new-style classes.

I have updated the tests.
It should be safe for 2.7, no?

----------
keywords: +patch
Added file: http://bugs.python.org/file15585/issue7532_classic_getitem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Thu Dec 17 23:07:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Dec 2009 22:07:15 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261087635.24.0.417328515487.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the new patch. The problem with inheriting from
BufferedRandom, though, is that if you call e.g. write() on a read-only
gzipfile, it will appear to succeed because the bytes are buffered
internally.

I think the solution would be to use delegation rather than inheritance.
Something like:

    def __init__(self, ...)
        if 'w' in mode:
           self.buf = BufferedWriter(...)
        for meth in ('read', 'write', etc.):
            setattr(self, meth, getattr(self.buf, meth))

It would also be nice to add some tests for the issues I mentioned
earlier (check that IOError is raised when reading a write-only file,
and vice-versa).

By the way, we can't apply this approach to 2.x since
BufferedWriter/BufferedRandom won't accept unicode arguments for write()
and friends, and that would break compatibility. For 3.x it is fine though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Thu Dec 17 23:23:34 2009
From: report at bugs.python.org (Nir Aides)
Date: Thu, 17 Dec 2009 22:23:34 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261088614.89.0.825931852555.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

How about using the first patch with the slicing optimization and 
additionally enhancing GzipFile with the methods required to make it 
play nice as a raw stream to an io.BufferedReader object (readable(), 
writable(), readinto(), etc...).

This way we still get the 350% speed up and keep it fully backward 
compatible, and if someone needs the extra performance they can feed it 
into an io.BufferedReader object thus:

g = gzip.GzipFile(...)
r = io.BufferedReader(g)
for line in r:
    ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Thu Dec 17 23:33:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Dec 2009 22:33:39 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1261088614.89.0.825931852555.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261089259.3355.36.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How about using the first patch with the slicing optimization and 
> additionally enhancing GzipFile with the methods required to make it 
> play nice as a raw stream to an io.BufferedReader object (readable(), 
> writable(), readinto(), etc...).

That's fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Thu Dec 17 23:59:52 2009
From: report at bugs.python.org (Leo)
Date: Thu, 17 Dec 2009 22:59:52 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1261090792.01.0.598784788483.issue7522@psf.upfronthosting.co.za>


Leo <dontsendleospam at gmail.com> added the comment:

Thanks for the suggestions "random.sample(s, 1)[0]" and 
"x=next(iter(s))". 

A counterpoint: isn't this a classic example of where polymorphism 
enables a more elegant, simple, and clear (dare I say Pythonic) 
approach? The complexity of allowing sets as inputs, even with a naive 
implementation, is still O(n) even in the worst case vs. O(1) for 
arrays. Isn't documenting that distinction good enough?

Thanks,
Leo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 00:01:07 2009
From: report at bugs.python.org (Leonardo Rochael Almeida)
Date: Thu, 17 Dec 2009 23:01:07 +0000
Subject: [issue7535] logging: Filters on Loggers can't actually filter
	messages on lower levels of the logging hierarchy
In-Reply-To: <1261075935.27.0.779288069051.issue7535@psf.upfronthosting.co.za>
Message-ID: <1261090867.91.0.497119576598.issue7535@psf.upfronthosting.co.za>


Leonardo Rochael Almeida <leorochael at gmail.com> added the comment:

At the very least this is a documentation bug. By reading the std docs
on the logging module [1] one gets the impression that if a log record
gets to a certain logger, even if percolated from more specific loggers,
then the filters to that logger should be involved and even get the
chance to change the log record.

[1] http://docs.python.org/library/logging.html

This is reinforced by the documentation and the implementation of the
logging.Filter class, which is supposed to filter-out messages of more
specific loggers, but which would never actually filter out anything if
applied to a Logger of the same "name" (as opposed to a Handler, since
filter handlers do get called for log records of more specific loggers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7535>
_______________________________________

From report at bugs.python.org  Fri Dec 18 01:18:02 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 00:18:02 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261095482.97.0.790598995107.issue7532@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Patch augmented with extensive tests:
 * Classic class or New-style class
 * with or without __getslice__

----------
Added file: http://bugs.python.org/file15586/issue7532_classic_getitem_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Fri Dec 18 01:19:28 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 00:19:28 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261095568.18.0.411610950778.issue7532@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15585/issue7532_classic_getitem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Fri Dec 18 01:20:37 2009
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 18 Dec 2009 00:20:37 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1261095637.26.0.815826204659.issue5819@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I am not sure that this guy's idea is good, but I think that he deserves
more attention.  In comments elsewhere on the web, I noticed that people
thought the PYTHONUSERBASE site-packages directory could contain .pth
files which would serve the same purpose as his proposed environment
variable.  However, .pth files are not recursive; a .pth file in one
directory does not cause .pth files to be processed in the directories
named by its contents.

I agree with ianb that this is a poor way to mimic virtualenv.  There is
a difference between user additions -- which should affect *all* python
code that he uses -- and separate Python installations.

There might be other reasons for multiple user site-packages
directories.  For example, Python lacks Perl's architecture awareness. 
Perl can load from
  lib/
  lib/5.10.0/
  lib/5.10.0/linux-x86
  lib/5.10.0/linux-x86/auto
and a few other combinations.

Python also lacks a PERL5OPT equivalent.  I am forced to use the
PYTHONUSERBASE mechanism to simulate that behavior (which I use to turn
on code coverage everywhere during testing) but I only get to set that once.

----------
nosy: +cdunn2001

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Fri Dec 18 01:36:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Dec 2009 00:36:00 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261096560.36.0.577282923004.issue7442@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can reproduce it on a Fedora (fc6) Linux box. It's not a decimal
problem, but a plain locale problem:

>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, 'fi_FI')
'fi_FI'
>>> locale.localeconv()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/python/py3k/Lib/locale.py", line 111, in localeconv
    d = _localeconv()
ValueError: Cannot convert byte to string
>>> 

Here's the contents of the struct lconv as returned by localeconv():

((gdb) p *l
$1 = {decimal_point = 0xb7b54020 ",", thousands_sep = 0xb7b54022 "?",
grouping = 0xb7b54024 "\003\003", 
  int_curr_symbol = 0x998858 "", currency_symbol = 0x998858 "",
mon_decimal_point = 0x998858 "", mon_thousands_sep = 0x998858 "", 
  mon_grouping = 0x998858 "", positive_sign = 0x998858 "", negative_sign
= 0x998858 "", int_frac_digits = 127 '\177', 
  frac_digits = 127 '\177', p_cs_precedes = 127 '\177', p_sep_by_space =
127 '\177', n_cs_precedes = 127 '\177', 
  n_sep_by_space = 127 '\177', p_sign_posn = 127 '\177', n_sign_posn =
127 '\177', int_p_cs_precedes = 127 '\177', 
  int_p_sep_by_space = 127 '\177', int_n_cs_precedes = 127 '\177',
int_n_sep_by_space = 127 '\177', int_p_sign_posn = 127 '\177', 
  int_n_sign_posn = 127 '\177'}

The problem is thousands_sep:
(gdb) p l->thousands_sep
$2 = 0xb7b54022 "?"
(gdb) p (unsigned char)l->thousands_sep[0]
$3 = 160 '?'

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Fri Dec 18 01:48:17 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Dec 2009 00:48:17 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261097297.86.0.499232742923.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I apologize (again) Jason, for taking forever to move forward on this.

With patch 16 on XP, I get this error on test_platform:

======================================================================
ERROR: test_architecture_via_symlink (__main__.PlatformTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_platform.py", line 22, in
test_architecture_via_symlink
    os.symlink(real, link)
NotImplementedError: CreateSymbolicLinkW not found

----------------------------------------------------------------------
Ran 18 tests in 0.047s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_platform.py", line 204, in <module>
    test_main()
  File "Lib/test/test_platform.py", line 200, in test_main
    PlatformTest
  File "c:\home\eric\python\py3k\lib\test\support.py", line 919, in
run_unittest
    _run_suite(suite)
  File "c:\home\eric\python\py3k\lib\test\support.py", line 902, in
_run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_platform.py", line 22, in
test_architecture_via_symlink
    os.symlink(real, link)
NotImplementedError: CreateSymbolicLinkW not found

I'll try to spend some time tracking it down over the weekend, but feel
free to look it over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Dec 18 03:49:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Dec 2009 02:49:54 +0000
Subject: [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1261104594.68.0.67580092897.issue5093@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r76871.

----------
nosy: +benjamin.peterson, collinwinter
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5093>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:42:15 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Fri, 18 Dec 2009 03:42:15 +0000
Subject: [issue7537] test_format
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>


New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:

With -r 76870, on Fedora 11, amd x80_64, regrtest of test_format fails 
when the -j  option is combined with the -v option. It happens whether 
testing everything or just the one test.

  ./python -Ebb Lib/test/regrtest -j3 -vv 
or
  ./python -Ebb Lib/test/regrtest -j3 -vv test_format

The error report is like
"""
FAILED (errors=1)
test test_format failed -- Traceback (most recent call last):
  File "/home/jbase/checkouts/py/py32/Lib/test/test_format.py", line 
221, in test_format
    testformat("%r", "\u0374", "'\u0374'")   # printable
  File "/home/jbase/checkouts/py/py32/Lib/test/test_format.py", line 20, 
in testformat
    (formatstr, args, output), end=' ')
UnicodeEncodeError: 'ascii' codec can't encode character '\u0374' in 
position 8: ordinal not in range(128)
1 test failed:
    test_format
"""

~jim

----------
components: Tests
messages: 96547
nosy: jgsack
severity: normal
status: open
title: test_format
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 07:52:16 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Fri, 18 Dec 2009 06:52:16 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261119136.0.0.483172512704.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I uploaded a patch to add PyLong_AsLongAndOverflow. It was made against
the 2.7a1 source. "make test", gmpy's test suite, and mpmath's test
suite all pass.

Let me know if there is anything else I can do.

----------
keywords: +patch
Added file: http://bugs.python.org/file15587/longobject.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:29:51 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Fri, 18 Dec 2009 07:29:51 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261121391.34.0.340983564569.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Uploaded a new version of py3intcompat.c. It should be save to include
with any version of Python, included 2.7 with PyLong_AsLongAndOverflow
added.

The file includes basic documentation on use.

----------
Added file: http://bugs.python.org/file15588/py3intcompat-v2.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:53:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Dec 2009 07:53:00 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261122780.81.0.389006455156.issue7537@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can duplicate this on Fedora Core 6, x86, r76872. I simplified the
command line down to:

./python Lib/test/regrtest.py -j1 -v test_format

(and any value for j >= 1 causes the error).

----------
nosy: +eric.smith
title: test_format -> test_format fails with -j combined with -v

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:53:01 2009
From: report at bugs.python.org (lekma)
Date: Fri, 18 Dec 2009 07:53:01 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261122781.79.0.382089245616.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

> - when importing fcntl, bear in mind that some systems don't have this
> module (e.g. Windows), so you should catch and silence the ImportError

would something like the following be ok?:

try:
    import fcntl
except ImportError:
    fcntl = False

and then:

if hasattr(socket, "SOCK_CLOEXEC") and fcntl:
    tests.append(CloexecLinuxConstantTest)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:34:19 2009
From: report at bugs.python.org (River Tarnell)
Date: Fri, 18 Dec 2009 08:34:19 +0000
Subject: [issue7538] HP-UX 11.11 GCC build fails to build modules
In-Reply-To: <1261125259.67.0.0629730876932.issue7538@psf.upfronthosting.co.za>
Message-ID: <1261125259.67.0.0629730876932.issue7538@psf.upfronthosting.co.za>


New submission from River Tarnell <river at flyingparchment.org.uk>:

2.6.4 fails to build on HP-UX 11.11 using GCC, when linking modules:

building '_struct' extension
gcc -pthread -shared build/temp.hp-ux-B.11.11-9000-785-2.6/home/river/
Python-2.6.4/Modules/_struct.o -L/opt/rt/lib -L/usr/local/lib -
lpython2.6 -o build/lib.hp-ux-B.11.11-9000-785-2.6/_struct.sl
/usr/ccs/bin/ld: Can't find library: "python2.6"
collect2: ld returned 1 exit status

(This happens for all modules.)

The problem is that libpython2.6.sl is in the root directory, but -L. 
is not passed to gcc, so the linker can't find the library.

----------
components: Build
messages: 96552
nosy: rtarnell
severity: normal
status: open
title: HP-UX 11.11 GCC build fails to build modules
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7538>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:40:13 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 08:40:13 +0000
Subject: [issue7458] crash in str.rfind() with an invalid start value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1261125613.43.0.84597182083.issue7458@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

I proposed a patch which solve this issue and improve performance of
str.rfind. See issue 7462.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7458>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:47:25 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 18 Dec 2009 08:47:25 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261126045.75.0.415929758486.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Submitted combined patch for Python 2.7. 
If its good i'll send one for Python 3.2.

----------
Added file: http://bugs.python.org/file15589/gzip_7471_py27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:48:46 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 18 Dec 2009 08:48:46 +0000
Subject: [issue7535] logging: Filters on Loggers can't actually filter
	messages on lower levels of the logging hierarchy
In-Reply-To: <1261090867.91.0.497119576598.issue7535@psf.upfronthosting.co.za>
Message-ID: <636480.32762.qm@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Leonardo Rochael Almeida  added the comment:

> 
> At the very least this is a documentation bug. By reading the std docs
> on the logging module [1] one gets the impression that if a log record
> gets to a certain logger, even if percolated from more specific loggers,
> then the filters to that logger should be involved and even get the
> chance to change the log record.
> 
> [1] http://docs.python.org/library/logging.html
> 
> This is reinforced by the documentation and the implementation of the
> logging.Filter class, which is supposed to filter-out messages of more
> specific loggers, but which would never actually filter out anything if
> applied to a Logger of the same "name" (as opposed to a Handler, since
> filter handlers do get called for log records of more specific loggers).
> 

Can you say more specifically which part of this document you think is misleading? For example, the Filter documentation says "Filters can be used by Handlers and Loggers for
more sophisticated filtering than is provided by levels." Now this documentation does also mention how the default Filter implementation works, which does refer to loggers and their children - but that's just a specific implementation of a Filter which allows through some part of the logger namespace hierarchy. (It just looks at the logger name to decide whether to let an event through or not.) It's not a statement about how Filters work in general.

If you can confirm which parts of the logging documentation you think need to be changed (feel free to suggest alternative wording or additional wording) I'll certainly try to make those parts clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7535>
_______________________________________

From report at bugs.python.org  Fri Dec 18 10:38:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 18 Dec 2009 09:38:05 +0000
Subject: [issue7442] decimal.py: format failure with locale specifier
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261129085.9.0.318928155831.issue7442@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, it's a problem in _localemodule.c. This situation always
occurs when LC_NUMERIC is something like ISO8859-15, LC_CTYPE
is UTF-8 AND the decimal point or separator are in the range
128-255. Then mbstowcs tries to decode the character according
to LC_CTYPE and finds that the character is not valid UTF-8:


static PyObject*mbstowcs
str2uni(const char* s)
{
#ifdef HAVE_BROKEN_MBSTOWCS
    size_t needed = strlen(s);
#else
    size_t needed = mbstowcs(NULL, s, 0);
#endif


I can't see a portable way to fix this except:

block threads
set temporary LC_CTYPE
call mbstowcs
restore LC_CTYPE
unblock threads


I don't think this issue is important enough to do that. What
I do in cdecimal is raise an error "Invalid separator or
unsupported combination of LC_NUMERIC and LC_CTYPE".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Fri Dec 18 10:47:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 18 Dec 2009 09:47:05 +0000
Subject: [issue7442] _localemodule.c: str2uni() with different LC_NUMERIC and
	LC_CTYPE
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261129625.74.0.553331625972.issue7442@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Changed title (was: decimal.py: format failure with locale specifier)

----------
title: decimal.py: format failure with locale specifier -> _localemodule.c: str2uni() with different LC_NUMERIC and LC_CTYPE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:09:08 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2009 11:09:08 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261134548.84.0.102939608155.issue7537@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is because in -j mode stdout is a pipe, and so python defaults to
ascii for the output encoding.  I'm not sure what the best way is to fix
this.

----------
nosy: +pitrou, r.david.murray
priority:  -> low
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:11:19 2009
From: report at bugs.python.org (kurt)
Date: Fri, 18 Dec 2009 11:11:19 +0000
Subject: [issue7526] tkinter menubutton underline behaviour varies between
	tkinter * and tkinter.ttk *
In-Reply-To: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>
Message-ID: <1261134679.78.0.642632677316.issue7526@psf.upfronthosting.co.za>


Changes by kurt <kurt.forrester.fec at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7526>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:14:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2009 11:14:51 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261134891.0.0.875459853365.issue7523@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It would be better to use test skipping: (eg: @unittest.SkipUnless
before the test class).

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:55:39 2009
From: report at bugs.python.org (Marius Gedminas)
Date: Fri, 18 Dec 2009 11:55:39 +0000
Subject: [issue7539] unicode exceptions terminate pdb.pm() loop
In-Reply-To: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
Message-ID: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>


New submission from Marius Gedminas <marius at gedmin.as>:

$ python2.6
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.
>>> None()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable
>>> import pdb; pdb.pm()
> <stdin>(1)<module>()
(Pdb) raise Exception(u'\xff')
*** Exception: Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/pdb.py", line 1239, in pm
    post_mortem(sys.last_traceback)
  File "/usr/lib/python2.6/pdb.py", line 1236, in post_mortem
    p.interaction(None, t)
  File "/usr/lib/python2.6/pdb.py", line 194, in interaction
    self.cmdloop()
  File "/usr/lib/python2.6/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/usr/lib/python2.6/pdb.py", line 261, in onecmd
    return cmd.Cmd.onecmd(self, line)
  File "/usr/lib/python2.6/cmd.py", line 218, in onecmd
    return self.default(line)
  File "/usr/lib/python2.6/pdb.py", line 226, in default
    print >>self.stdout, '***', exc_type_name + ':', v
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in 
position 0: ordinal not in range(128)
>>> 

Note that the post-mortem loop is terminated (if you do pdb.set_trace() 
instead of pdb.pm(), that doesn't happen).

This is rather irritating then you're trying to post-mortem debug a 
failed test with expensive setup, when leaving the postmortem pdb 
session exits the process.

Python 3.1 is not affected.  I don't have 2.7 handy.

----------
components: Library (Lib), Unicode
messages: 96560
nosy: mgedmin
severity: normal
status: open
title: unicode exceptions terminate pdb.pm() loop
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7539>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:56:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 11:56:49 +0000
Subject: [issue7539] unicode exceptions terminate pdb.pm() loop
In-Reply-To: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
Message-ID: <1261137409.31.0.474509089027.issue7539@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/issue7539>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:39:26 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 13:39:26 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261143566.28.0.701942289697.issue7537@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Maybe the "sys.stdout.write" method can be wrapped in a decorator or a
context manager?

See example of decorator attached.

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file15590/issue7537_tolerant_stdout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:54:39 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 18 Dec 2009 13:54:39 +0000
Subject: [issue7394] sqlite3: some OperationalError exceptions should be
	ProgrammingError (PEP 249)
In-Reply-To: <1259167159.55.0.802533140683.issue7394@psf.upfronthosting.co.za>
Message-ID: <1261144479.68.0.709365492559.issue7394@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

The error code SQLITE_ERROR from SQLite is used for "runtime errors".
These can either be caused by the programmer (table does not exist, SQL
contains errors) or they can be other problems like constraint
violations etc.

To differentiate these we would need to parse the error message returned
by sqlite3_errmsg(). This is a path I don't want to go: it's hard to get
this right across current and future SQLite versions.

So I'm closing this issue as wontfix.

----------
assignee:  -> ghaering
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7394>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:24:46 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 18 Dec 2009 14:24:46 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1261146286.48.0.969526010601.issue7478@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks!

I've integrated this into pysqlite
(http://code.google.com/p/pysqlite/source/detail?r=6455981b3283b26c147d949a9031a0d74ea7ffe8)
and will soon push updates to the version in Python core.

In my opinion this changes is not critical enough to warrant pushing it
into Python 2.6. Do you agree?

----------
assignee:  -> ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7478>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:28:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Dec 2009 14:28:31 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1261146511.37.0.0713292316887.issue7478@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be backported to Python 2.6, like any bug fix (and especially
when it's about a crasher).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7478>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:36:03 2009
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 18 Dec 2009 14:36:03 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261146963.31.0.484960944275.issue7471@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

In the test, should you verify that the correct data comes back from
io.BufferedReader? After the r.close() on line 90 of test_gzip.py,
adding something like "self.assertEqual("".join(lines), data1*50)" would
do the trick. 
Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:01:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Dec 2009 15:01:25 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261148485.64.0.869043669117.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Two things:
- since it implements common IO operations, the GzipFile class could
inherit io.BufferedIOBase. It would also alleviate the need to
reimplement readinto(): BufferedIOBase has a default implementation
which should be sufficient.
- rather than `type(data) is memoryview`, the preferred idiom is
`isinstance(data, memoryview)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:11:56 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 15:11:56 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261149116.68.0.855481813678.issue7537@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15590/issue7537_tolerant_stdout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:12:35 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 15:12:35 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261149155.63.0.138618273461.issue7537@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15591/issue7537_tolerant_stdout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:24:02 2009
From: report at bugs.python.org (Till Maas)
Date: Fri, 18 Dec 2009 15:24:02 +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: <1261149842.32.0.235270861363.issue7540@psf.upfronthosting.co.za>


New submission from Till Maas <opensource at till.name>:

When I try to reuse a urllib2.Request object with different post data,
the data itself is updated, but the content length is not. Here is a
simple script to reproduce it on Python 2.5 on Fedora 10 and 2.6 on Arch
Linux:

#!/usr/bin/python
# vim: fileencoding=utf8 
# test with:  echo | socat - tcp4-listen:1111,fork
# Demonstrates bad content length of second request, which should be 2
import urllib2
req = urllib2.Request('http://localhost:1111')
req.add_data("1")
urllib2.urlopen(req)
req.add_data("10")
urllib2.urlopen(req)

----------
components: Library (Lib)
messages: 96567
nosy: till
severity: normal
status: open
title: urllib2 request does not update content length after new add_data
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:41:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 15:41:38 +0000
Subject: [issue7342] str(datetime_obj) doesn't include microseconds if their
	value is 0
In-Reply-To: <1258495371.1.0.197938868538.issue7342@psf.upfronthosting.co.za>
Message-ID: <1261150898.1.0.618799144858.issue7342@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done in r76874 (release26-maint), r76875 (py3k), r76876 (release31-maint).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7342>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:28:08 2009
From: report at bugs.python.org (Robin)
Date: Fri, 18 Dec 2009 16:28:08 +0000
Subject: [issue7541] python-config --ldflags doesn't pick up libpython2.5.a
In-Reply-To: <1261153688.5.0.917977427633.issue7541@psf.upfronthosting.co.za>
Message-ID: <1261153688.5.0.917977427633.issue7541@psf.upfronthosting.co.za>


New submission from Robin <robince at gmail.com>:

Using my python.org install:
robin-mbp:~ robince$ which python-config
/Library/Frameworks/Python.framework/Versions/2.5/bin/python-config
robin-mbp:~ robince$ python-config --ldflags
-L/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
-ldl -lpython2.5

But if I build a C file with python embedded, the above linker flags
result it in it embedding the system python. Obviously the -lpython2.5
is picking up the system one in preference to the one on the -L path.

>From Ronald Oussoren on pythonmac-sig:

The easiest workaround is to open a terminal window and execute the 
following commands:

  cd 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config
  ln -s libpython2.5.a libpython2.5.dylib

This will ensure that the OSX linker knows that libpython is a shared 
library and links to this library. By default the OSX linker searches 
for a .dylib on the entire linker path and only then looks for .a files.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 96569
nosy: robince, ronaldoussoren
severity: normal
status: open
title: python-config --ldflags doesn't pick up libpython2.5.a
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7541>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:51:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 16:51:34 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1261155094.88.0.996005906952.issue7310@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file15348/issue7310.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7310>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:54:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 16:54:31 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1261155271.8.0.893246824422.issue7310@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch, I added the _Environ() around the dict in the repr and
improved the tests.

----------
Added file: http://bugs.python.org/file15592/issue7310.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7310>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:02:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Dec 2009 17:02:43 +0000
Subject: [issue1087] py3k os.popen result is not iterable, patch attached
In-Reply-To: <1194531480.0.0.141906660951.issue1087@psf.upfronthosting.co.za>
Message-ID: <1261155763.56.0.777200063973.issue1087@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does anybody know why _wrap_close wraps TextIOWrapper rather than
inherit it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:04:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Dec 2009 17:04:45 +0000
Subject: [issue1087] py3k os.popen result is not iterable, patch attached
In-Reply-To: <1194531480.0.0.141906660951.issue1087@psf.upfronthosting.co.za>
Message-ID: <1261155885.55.0.230241033061.issue1087@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, I hadn't seen this bug is closed. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1087>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:51:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 17:51:51 +0000
Subject: [issue7493] doc: patch for py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261158711.85.0.281172576563.issue7493@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:49:48 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 18:49:48 +0000
Subject: [issue7493] doc: patch for py3k/Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261162188.25.0.440977943574.issue7493@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15542/py3k_doc_faq_design.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:55:04 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 18:55:04 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261162504.25.0.23240328577.issue7493@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

Updated patch with suggestions of Ezio.

----------
title: doc: patch for py3k/Doc/faq/design.rst -> doc: patch for Doc/faq/design.rst
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15593/doc_faq_design.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:55:29 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 18:55:29 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261162529.6.0.593480183889.issue7493@psf.upfronthosting.co.za>


Changes by flox <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15594/doc_faq_design_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:03:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Dec 2009 19:03:41 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1261163021.73.0.18680339393.issue3588@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:07:22 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Fri, 18 Dec 2009 19:07:22 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261079558.97.0.132454315146.issue7534@psf.upfronthosting.co.za>
Message-ID: <33a5fc8a0912181107s36240943le4bc0608f59e7b79@mail.gmail.com>


Marcos Donolo <mdonolo at vt.edu> added the comment:

Ok, I have patch ready. how do we go about putting it in?
thanks.
marcos

On Thu, Dec 17, 2009 at 11:52 AM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Changes by Ezio Melotti <ezio.melotti at gmail.com>:
>
>
> ----------
> nosy: +ezio.melotti
> versions: +Python 3.1
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7534>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15595/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________
-------------- next part --------------
Ok, I have patch ready. how do we go about putting it in?<br>thanks.<br>marcos<br><br><div class="gmail_quote">On Thu, Dec 17, 2009 at 11:52 AM, Ezio Melotti <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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Changes by Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt;:<br>
<br>
<br>
----------<br>
</div>nosy: +ezio.melotti<br>
versions: +Python 3.1<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/issue7534" target="_blank">http://bugs.python.org/issue7534</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Dec 18 20:08:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Dec 2009 19:08:42 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1261163322.72.0.320040707614.issue7511@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

OK so bin\vcvars64.bat would be an alternative location to look at for
win32-64.

Your diff says "amd64", shouldn't it be testing for "x86_64", "amd64"
and "x64" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:09:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 19:09:35 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261163375.66.0.153296802559.issue7534@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Just upload it here clicking on 'Browse' next to the 'File' field and
then click on 'Submit Changes'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:19:32 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Dec 2009 19:19:32 +0000
Subject: [issue7440] distutils shows incorrect Python version in MSI installers
In-Reply-To: <1259999364.02.0.642066187222.issue7440@psf.upfronthosting.co.za>
Message-ID: <1261163972.67.0.00885877318947.issue7440@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The patch looks good to me. I am putting Martin on the noselist so he
can validate this.

Notice that this Dialog has been changed in trunk, so this need to be
fixed only in the 2.6 branch.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7440>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:21:45 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Dec 2009 19:21:45 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1261164105.23.0.871583094148.issue4359@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am closing this since Fedora has fixed the issue on their side.

On a side note: I am working on this new sysconfig module, in a branch
called tarek_sysconfig

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:38:19 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Dec 2009 19:38:19 +0000
Subject: [issue7412] distutils install race condition
In-Reply-To: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
Message-ID: <1261165099.0.0.774722050979.issue7412@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As you said, this race condition can happen even if you copy the file in
some temp dir, then move them to python. That would reduce the window,
but not remove it.

The best way to avoid it is to stop any running Python process when 
updates occurs I guess, or work on some kind of protected import statement. 

Now I am not sure about potential breakages during installation at
Distutils' level since it just copies files to site-packages only once
everything is built. The only breakage I have in mind is when there's
some kind of I/O error when copying files on the disk.

So I agree that it would be better to save any file that is about to be
overriden when the install command starts to copy files, so it can
rollback if a problem occurs.

----------
priority:  -> low
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7412>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:54:25 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Fri, 18 Dec 2009 19:54:25 +0000
Subject: [issue7542] segfault on cPickle.loads("0.")
In-Reply-To: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>
Message-ID: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

cPickle in Python 2.6.4 segfaults when trying to load the string "0.". 
pickle throws an error.  cPickle should at the least not segfault.

$ python
Python 2.6.4 (r264:75706, Nov  2 2009, 14:44:17) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, cPickle
>>> pickle.loads("0.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/pickle.py", line 1374, in loads
    return Unpickler(file).load()
  File "/usr/lib/python2.6/pickle.py", line 858, in load
    dispatch[key](self)
  File "/usr/lib/python2.6/pickle.py", line 1138, in load_pop
    del self.stack[-1]
IndexError: list assignment index out of range
>>> cPickle.loads("0.")
Segmentation fault (core dumped)

----------
components: Library (Lib)
messages: 96580
nosy: afoglia
severity: normal
status: open
title: segfault on cPickle.loads("0.")
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7542>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:59:44 2009
From: report at bugs.python.org (flox)
Date: Fri, 18 Dec 2009 19:59:44 +0000
Subject: [issue7542] segfault on cPickle.loads("0.")
In-Reply-To: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>
Message-ID: <1261166384.04.0.427552523948.issue7542@psf.upfronthosting.co.za>


flox <laxyf at yahoo.fr> added the comment:

On 3.1, 3.2 same issue:

>>> pickle.loads(b'0')
Segmentation fault

----------
nosy: +flox
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7542>
_______________________________________

From report at bugs.python.org  Fri Dec 18 21:00:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Dec 2009 20:00:14 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1261166414.95.0.519925091212.issue7417@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Georg, I'm a bit lost in the different suggestions. Your take? Do you
have any preference? Or should we simply copy the docstring from _pyio's
open() function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7417>
_______________________________________

From report at bugs.python.org  Fri Dec 18 21:12:35 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Dec 2009 20:12:35 +0000
Subject: [issue7542] segfault on cPickle.loads("0.")
In-Reply-To: <1261166041.47.0.835794497653.issue7542@psf.upfronthosting.co.za>
Message-ID: <1261167155.8.0.0456756726377.issue7542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is a duplicate of issue 7455.

----------
nosy: +eric.smith
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7542>
_______________________________________

From report at bugs.python.org  Fri Dec 18 21:25:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Dec 2009 20:25:14 +0000
Subject: [issue7392] cPickle test failure on release26-maint branch
In-Reply-To: <1259085941.32.0.227872963702.issue7392@psf.upfronthosting.co.za>
Message-ID: <1261167914.22.0.645230623652.issue7392@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Backported in r76877, thanks for the report.

----------
assignee:  -> ezio.melotti
keywords: +26backport
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7392>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:29:38 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Dec 2009 21:29:38 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261171778.59.0.19159507205.issue7455@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The patch works correctly on 2.7.

It should be applied on trunk, and backported to other branches, too.

(issue7542 is marked as duplicate of this one)

----------
nosy: +flox
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:29:53 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Dec 2009 21:29:53 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261171793.37.0.625764529818.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:48:31 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 18 Dec 2009 21:48:31 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261172911.06.0.315759349746.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15596/issue7455_silence_py3k_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:58:08 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Fri, 18 Dec 2009 21:58:08 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261173488.17.0.335845311559.issue7534@psf.upfronthosting.co.za>


Changes by Marcos Donolo <mdonolo at vt.edu>:


Added file: http://bugs.python.org/file15597/floatobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:59:16 2009
From: report at bugs.python.org (Marcos Donolo)
Date: Fri, 18 Dec 2009 21:59:16 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261173556.92.0.271445678641.issue7534@psf.upfronthosting.co.za>


Marcos Donolo <mdonolo at vt.edu> added the comment:

I had to handle nans and infs in different places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:06:46 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:06:46 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Currently, Python's opcodes are defined as preprocessor #defines.  This means that they are 
invisible to the debugger.

I'm attaching:
  (i) a simple script (fixup-opcode-header.py) which converts Include/opcode.h to use an 
anonymous enum for the values
  (ii) a diff containing the results of running the script on trunk's Include/opcode.h
  (iii) a patch that converts usage of "int opcode" to "enum Py_Opcode opcode" in a few 
places

(Is the usage of an anonymous enum acceptable on all compilers that Python supports?  Is it 
going to generate equal machinecode on all compilers, relative to an int?)

With this patch, if I break into PyEval_EvalFrameEx in gdb, the debugger is able to emit 
symbolic values for "opcode":
(gdb) p opcode
$2 = LOAD_CONST

----------
components: Interpreter Core
messages: 96587
nosy: dmalcolm
severity: normal
status: open
title: RFE: introduce "enum Py_Opcode"
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:07:51 2009
From: report at bugs.python.org (Julien Danjou)
Date: Fri, 18 Dec 2009 23:07:51 +0000
Subject: [issue1644818] Allow importing built-in submodules
Message-ID: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>


Julien Danjou <julien at danjou.info> added the comment:

Is there to chance to see this *bug* fixed someday?

----------
nosy: +jd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:07:58 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:07:58 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177678.12.0.384928689148.issue7543@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file15598/fixup-opcode-header.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:09:55 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:09:55 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177795.54.0.892025528318.issue7543@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file15599/opcode.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:10:44 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:10:44 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177844.25.0.910861519974.issue7543@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15600/opcode.h.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:12:38 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:12:38 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261177958.99.0.094361397695.issue7543@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file15601/use-opcode-enum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:21:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Dec 2009 23:21:11 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261178471.83.0.759885760924.issue7543@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What do you mean with "anonymous enum"?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:22:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Dec 2009 23:22:29 +0000
Subject: [issue1644818] Allow importing built-in submodules
In-Reply-To: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
Message-ID: <4B2C0EB2.3070301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is there to chance to see this *bug* fixed someday?

Please ask on python-dev. I may be willing to revive my five-for-one offer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:30:22 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:30:22 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261179022.24.0.434398870493.issue7543@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Ooops, sorry; in an earlier version of this work, I was generating an 
enum of the form:
  enum {
  };
i.e. without an identifier (an anonymous enum) 

which I later changed to:
  enum Py_Opcode {
  };

Mea culpa; I forgot to update the text for this bug when I made that 
change.
Sorry about being confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:48:11 2009
From: report at bugs.python.org (John Millikin)
Date: Fri, 18 Dec 2009 23:48:11 +0000
Subject: [issue7521] PyEval_GetRestricted should be removed from C API
	reference
In-Reply-To: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
Message-ID: <1261180091.93.0.712346888927.issue7521@psf.upfronthosting.co.za>


John Millikin <jmillikin at gmail.com> added the comment:

Ditto Py_GetBuildNumber() <
http://docs.python.org/3.1/c-api/init.html#Py_GetBuildNumber > -- only
mentioned in docs and HISTORY, nothing in the headers or source. Appears
to have been removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7521>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:50:14 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 18 Dec 2009 23:50:14 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261180214.33.0.110353366939.issue7543@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file15602/diff-in-generated-assembler-for-ceval.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:50:49 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 18 Dec 2009 23:50:49 +0000
Subject: [issue1644818] Allow importing built-in submodules
Message-ID: <1261180249.94.0.887938038672.issue1644818@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:12:39 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 00:12:39 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261181559.12.0.674819557592.issue7455@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I moved the test to test.pickletester, so that it can be used for
all 3 tests:
 test_pickle
 test_cpickle
 test_xpickle

(and backported a test which was only on py3k)

----------
Added file: http://bugs.python.org/file15603/issue7455_cpickle_load_pop.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:13:02 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 00:13:02 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261181582.01.0.950811141453.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15604/issue7455_cpickle_load_pop_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:13:10 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 00:13:10 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261181590.66.0.577787486694.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15596/issue7455_silence_py3k_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:13:42 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 00:13:42 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261181622.81.0.959714613447.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15605/issue7455_silence_py3k_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Sat Dec 19 02:42:10 2009
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sat, 19 Dec 2009 01:42:10 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1261186930.57.0.232415611217.issue4359@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Hey tarek, the main thrust of this bug for me was storing the data in an
inappropriate format and not having an API to get at it; things that I
think the sysconfig branch will address.  Does it make sense to have a
bug to track that progress?  Does it make sense for that bug to be this
one or a new one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Sat Dec 19 09:06:08 2009
From: report at bugs.python.org (Andrey Chichak)
Date: Sat, 19 Dec 2009 08:06:08 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1261209968.92.0.839626570621.issue7504@psf.upfronthosting.co.za>


Andrey Chichak <chch at kit.tomsk.ru> added the comment:

Remake for patch due the requirements of 
http://www.python.org/dev/patches/

----------
Added file: http://bugs.python.org/file15606/Cookie_multi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Sat Dec 19 09:31:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 19 Dec 2009 08:31:12 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1261211472.33.0.242396513412.issue7504@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For this kind of report you should provide more information. Is this an 
enhancement to the Cookie object? Why is it needed?
Do you really propose that users directly use the _multi attribute 
directly (the leading _ suggest an internal attribute)?
Also, some documentation update is necessary (in Doc/library/cookie.rst)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:23:32 2009
From: report at bugs.python.org (Andrey Chichak)
Date: Sat, 19 Dec 2009 09:23:32 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1261214612.42.0.27562672334.issue7504@psf.upfronthosting.co.za>


Andrey Chichak <chch at kit.tomsk.ru> added the comment:

This is fix for rare problem. If I set 2 cookies:
sid=pub.GHoBitAWLt, path="/"
sid=cab.S97jUfeihM, path="/cab"
All browsers in Cookie header send for any URL '/cab*':
sid=cab.S97jUfeihM; sid=pub.GHoBitAWLt
Current implementation always returns Cookie['sid']=pub.GHoBitAWLt - wrong!
My patch resolve this problem and Cookie['sid'] returns first (nearest/deepest in path) cookie value, 
and also collects all same name cookies in dict Cookie._multi .

Name (_multi) may be wrong, and may be any other :o) .

Also I can update documentation, but my English is not so good ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:58:47 2009
From: report at bugs.python.org (lekma)
Date: Sat, 19 Dec 2009 09:58:47 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261216727.02.0.209577867471.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

> It would be better to use test skipping: (eg: @unittest.SkipUnless
> before the test class).

I didn't know about this feature, thanks for the tip.

Now I wonder if it would be better to do it this way:
@unittest.SkipUnless(hasattr(socket, "SOCK_CLOEXEC") and fcntl,
"SOCK_CLOEXEC not defined OR module fcntl not available")

or this way:
@unittest.SkipUnless(hasattr(socket, "SOCK_CLOEXEC"), "SOCK_CLOEXEC not
defined")
@unittest.SkipUnless(fcntl, "module fcntl not available")

the second option seems better to me (obvious reason why the test was
skipped), what do you guys think? (it doesn't really matter, I know, but
while we're here...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:23:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 11:23:28 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1261221808.78.0.509206897811.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added erf and erfc in r76879 (trunk), r76880 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:24:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 11:24:29 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1261221869.77.0.899257849019.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Oops.  That's r76878 (trunk) and r76879 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3366>
_______________________________________

From report at bugs.python.org  Sat Dec 19 13:03:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 12:03:26 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1261224206.82.0.7229089453.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Interesting solution!  While the patch itself looks fine to me, I'm not 
sure I like this solution much.  It's fine to use this trick for list or 
tuple, but implementing it for all old-style classes at once seems a bit 
dangerous.

With this patch, it seems to me that the rule describing exactly what 
__getitem__ receives (for an old-style class implementing __getitem__ but 
not __getslice__) becomes rather complicated, and can no longer be deduced 
from the documentation.

I'd say leave the current behaviour as it is, and remind people that they 
should be using new-style classes wherever possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7532>
_______________________________________

From report at bugs.python.org  Sat Dec 19 13:49:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Dec 2009 12:49:33 +0000
Subject: [issue7544] multiprocessing.Pool(): Fatal Python error:
	PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Using my fuzzer (Fusil) on Python trunk, I got sometimes errors on
multiprocessing.Pool():

   Fatal Python error: PyEval_AcquireThread: NULL new thread state

I'm sorry but I don't have example script to reproduce the bug. I
suppose that the error depends on the system load. I have the error on
an Intel Core2 Quad Core Q9300 (CPU able to run 4 processes/threads at
the time same).

How can I get more information on the bug? How can I reproduce it?

----------
components: Extension Modules
messages: 96602
nosy: haypo
severity: normal
status: open
title: multiprocessing.Pool(): Fatal Python error: PyEval_AcquireThread: NULL new thread state
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:03:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 14:03:43 +0000
Subject: [issue7482] Improve ZeroDivisionError message for float and complex
	object
In-Reply-To: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
Message-ID: <1261231423.74.0.919698884009.issue7482@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So if we're going to change the error messages, it would be nice if the 
new error messages were grammatical English.  'complex division by zero' 
is fine, but e.g.  'float modulo by zero' doesn't really make sense.

Actually I'd be fine with 'float division by zero' for this, since there's 
an implicit division involved in computing a remainder.  Or perhaps 
something more verbose, like 'right-hand argument to modulo operation is 
zero'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7482>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:08:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 14:08:53 +0000
Subject: [issue7482] Improve ZeroDivisionError message for float and complex
	object
In-Reply-To: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
Message-ID: <1261231733.59.0.660215705855.issue7482@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

No, I don't think you should add tests for the error messages;  there 
should already be tests for the type of error, and that's enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7482>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:11:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 14:11:12 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261231872.64.0.020835145523.issue7534@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:20:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 14:20:33 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261232433.86.0.0244638674187.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for this;  I'll take a look.

Looks like we need some tests for this, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 16:20:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 15:20:15 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261236015.47.0.556853405672.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a set of testcases (patch against trunk) for float pow, based on 
Annex F of the C99 specification.

----------
keywords: +patch
Added file: http://bugs.python.org/file15607/float_pow_testcases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 16:59:11 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 19 Dec 2009 15:59:11 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello,
It seems there is an important difference between the doc of the IO
module, and its implementation so far (until todcay trunk revision 76805)

"buffering is an optional integer used to set the buffering policy. By
default full buffering is on. Pass 0 to switch buffering off (only
allowed in binary mode), 1 to set line buffering, and an integer > 1 for
full buffering."
--> actually full buffering only occurs if a negative buffering
parameter is given, else it seems th current value i kept as the buffer
size - eg. if we give "3", buffering will be 3 bytes...
This seems a fine behaviour to me, so this implementation could just be
documented as is.

-----------
Only case of full buffering in the C iomodule :
    if (buffering < 0) {
        buffering = DEFAULT_BUFFER_SIZE;
#ifdef HAVE_STRUCT_STAT_ST_BLKSIZE
        {
            struct stat st;
            long fileno;
            PyObject *res = PyObject_CallMethod(raw, "fileno", NULL);
            if (res == NULL)
                goto error;

            fileno = PyInt_AsLong(res);
            Py_DECREF(res);
            if (fileno == -1 && PyErr_Occurred())
                goto error;

            if (fstat(fileno, &st) >= 0)
                buffering = st.st_blksize;
        }
#endif
    }

----------
assignee: georg.brandl
components: Documentation, IO
messages: 96607
nosy: georg.brandl, pakal
severity: normal
status: open
title: IO buffering behaviour not properly documented
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:08:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:08:56 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261238936.99.0.195938779495.issue7545@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"Full buffering" means exactly what you discovered it means - enable a
buffer of a given number of bytes (3, 4096 or anything else). I'm not
sure what you thought it meant? That the file was buffered in its
entirety, regardless of its size?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:09:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Dec 2009 16:09:06 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261238946.47.0.628160829303.issue7523@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I lean toward the second way, myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:26:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:26:08 +0000
Subject: [issue7544] multiprocessing.Pool(): Fatal Python error:
	PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1261239968.3.0.677667478927.issue7544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Enable core dumps (`ulimit -c unlimited`) and re-run your tests. The
fatal Python error will leave a core file so that you can find out the
context.

You can also try a debug build of Python which may give you more
information, assuming it can reproduce the bug.

(as for how to reproduce the bug, it's your task to find it out :-))

----------
nosy: +jnoller, pitrou
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:32:39 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Dec 2009 16:32:39 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1261240359.36.0.374093484459.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ok, I created a new diff that considers all 64-bit values for 'arch'.
I think x64 cannot occur (See: PLAT_TO_VCVARS). Also, I use the
existence of bin\amd64\vcvarsamd64.bat as a test for VS Professional,
so in that case the new code is never executed.

Could someone confirm that VS Professional always has that file?

----------
Added file: http://bugs.python.org/file15608/vcvars2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:33:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:33:54 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261240434.66.0.712271171311.issue7543@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The assembler diff shows that at one point the compiler produced
slightly less good code after the change. I don't know what the impact
is in terms of performance but it shows we should be cautious with this
change.

Are you doing anything specific which requires this change?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:37:09 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Dec 2009 16:37:09 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1261240629.79.0.269819473008.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

'ValueError' should be 'DistutilsPlatformError' in the diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:44:05 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Dec 2009 16:44:05 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

would it be possible to add .asm to the extensions? I attach a diff that
I have tested with VS Express.

----------
files: vcasm.diff
keywords: patch
messages: 96614
nosy: skrah
severity: normal
status: open
title: msvc9compiler.py: add .asm extension
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15609/vcasm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7546>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:45:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:45:04 +0000
Subject: [issue7547] test_timeout should skip, not fail,
	when the remote host is not available
In-Reply-To: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>
Message-ID: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_timeout uses www.python.org as a Guinea pig for its socket tests.
Unfortunately sometimes www.python.org is down, which gives the
following kind of failures (seen on a buildbot recently):

test test_timeout failed -- Traceback (most recent call last):
  File "C:\buildslave\3.x.moore-windows\build\lib\test\test_timeout.py",
line 133, in testRecvTimeout
    self.sock.connect(self.addr_remote)
socket.error: [Errno 10060] A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to respond

test_timeout should catch the error and simply skip the test with an
appropriate message.

There's a similar problem with test_smtpnet which uses gmail as its
remote SMTP-SSL provider.

----------
components: Tests
messages: 96615
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_timeout should skip, not fail, when the remote host is not available
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/issue7547>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:46:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 16:46:47 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1261241207.83.0.792396208318.issue7546@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils
nosy: +tarek
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7546>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:12:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:12:06 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261242726.76.0.778810398945.issue7545@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The docs have a different wording, which I suggest copying to the docstring:

   *buffering* is an optional integer used to set the buffering policy.  By
   default full buffering is on.  Pass 0 to switch buffering off (only
allowed
   in binary mode), 1 to set line buffering, and an integer > 1 to
indicate the
   size of the buffer.

But now the question remains what the default is -- "full buffering" is
only meaningful with a specified buffer size.  The implementation seems
to default to line buffering.

----------
assignee: georg.brandl -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:19:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:19:49 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1261243189.95.0.395391812393.issue7508@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Maybe Antoine wants (!) to look at it.

----------
assignee: georg.brandl -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:31:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:31:02 +0000
Subject: [issue7527] Standard Library documentation fails to mention that
	string.Formatter, etc. are new in Python 2.6
In-Reply-To: <1260990891.99.0.271858942367.issue7527@psf.upfronthosting.co.za>
Message-ID: <1261243862.2.0.527765074119.issue7527@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I changed the prose into a versionadded tag in r76882.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7527>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:36:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:36:22 +0000
Subject: [issue7521] PyEval_GetRestricted should be removed from C API
	reference
In-Reply-To: <1260923271.26.0.677511613973.issue7521@psf.upfronthosting.co.za>
Message-ID: <1261244182.8.0.326913496144.issue7521@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r76883, r76884, r76885.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7521>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:37:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 17:37:41 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261244261.96.0.0426197766183.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There were two incorrect tests in float_pow_testcases.patch:

+            self.assertEqualAndEqualSign(pow_op(-INF, -0.5), -0.0)
+            self.assertEqualAndEqualSign(pow_op(-INF, -2.0), -0.0)

these should both have had 0.0 in place of -0.0.  Here are corrected and 
slightly expanded tests;  I've also fixed an incorrect doctest (0**nan 
should be nan, not 0) in Lib/test/ieee754.txt.

----------
Added file: http://bugs.python.org/file15610/float_pow_testcases2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:38:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:38:53 +0000
Subject: [issue7529] StreamHandler does not live in logging.Handlers
In-Reply-To: <1261040703.92.0.519271037741.issue7529@psf.upfronthosting.co.za>
Message-ID: <1261244333.59.0.129729741931.issue7529@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, I cannot reproduce the problem here (with a checkout before your
commit); as you say the module should be set by the module directive.  I
guess it's a Sphinx bug; I will investigate that.  Closing this issue,
since it's not in Python.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:39:18 2009
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 19 Dec 2009 17:39:18 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261244358.61.0.242117502656.issue7543@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Are you doing anything specific which requires this change?
No.  I was looking for ways of making CPython easier to debug, and I experimented with 
this.  It didn't help with debuggability as much as I hoped.

Given that CPython's performance is known to be sensitive to changes in the opcode dispatch 
code, I'd be happy to drop this RFE; I haven't done actual performance measurements on it 
yet (if it shows no measurable impact, would it be acceptable?)

I wanted to at least capture the script and patch in the issue tracker for reference 
(perhaps of interest to unladen-swallow?)

Thanks; feel free to close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:46:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:46:54 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261244814.23.0.888583711926.issue7493@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed in r76886, r76887.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:49:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 17:49:20 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1261244960.1.0.869736331874.issue7508@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In which part/filename of the doc can I find this extract?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:51:51 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:51:51 +0000
Subject: [issue7495] doc: patch for py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261245111.31.0.737238333376.issue7495@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r76888. Thanks!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:53:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 17:53:11 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1261245191.34.0.445634284961.issue7508@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Okay, I've found it. IMO this section should simply be removed, since
the `file` type doesn't exist anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:58:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 17:58:19 +0000
Subject: [issue7499] doc: patch for py3k/Doc/faq/library.rst
In-Reply-To: <1260740484.19.0.91493820793.issue7499@psf.upfronthosting.co.za>
Message-ID: <1261245499.03.0.309723618648.issue7499@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied with a few edits in r76889.  Note that the notation for number
ranges with "mismatching" brackets is actually correct.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7499>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:00:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:00:19 +0000
Subject: [issue7500] doc: add warnings for FAQ which may not be accurate
In-Reply-To: <1260741167.1.0.029992508259.issue7500@psf.upfronthosting.co.za>
Message-ID: <1261245619.14.0.59423311396.issue7500@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied (minus the warning) in r76890.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7500>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:01:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 18:01:09 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1261245669.45.0.832058496481.issue7508@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note: one issue is that io.rst is currently some kind of technical
reference about base classes and stuff, it is unreadable for anyone
looking for simple information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:03:46 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 19 Dec 2009 18:03:46 +0000
Subject: [issue1644818] Allow importing built-in submodules
Message-ID: <1261245826.06.0.717117926975.issue1644818@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/issue1644818>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:07:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 18:07:17 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261242726.76.0.778810398945.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261246078.3339.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But now the question remains what the default is -- "full buffering" is
> only meaningful with a specified buffer size.  The implementation seems
> to default to line buffering.

"full" buffering actually uses a default or custom buffer size when you
don't specify it. 4096 or 8192 usually (yes there's a heuristic :-)).

"full" buffering is the default for binary streams, as well as for text
streams which aren't a tty. text streams which are tty default to line
buffering.

(I admit full buffering is a confusing name; what could we use instead?
fixed-size buffering? chunk buffering?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:08:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:08:09 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1261246089.43.0.0833110546262.issue7119@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good. (I'm a bit unsure about the syntax "ie: blah" and "eg:
blah" though.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7119>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:09:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:09:29 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1261246169.78.0.391433316252.issue7475@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I also seem to recall that adding .transform()/.untransform() was
already accepted at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:09:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:09:41 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1261246181.26.0.697360494545.issue7475@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:16:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:16:38 +0000
Subject: [issue7479] os.lchmod is not present
In-Reply-To: <1260534820.94.0.148252550457.issue7479@psf.upfronthosting.co.za>
Message-ID: <1261246598.2.0.204380810652.issue7479@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added such a note in r76891.

----------
resolution: invalid -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7479>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:18:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:18:39 +0000
Subject: [issue7485] Error in FAQ entry '4.25 Why doesn't Python have a "with"
	statement for attribute assignments?'
In-Reply-To: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
Message-ID: <1261246719.35.0.319283111876.issue7485@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Where can I find this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7485>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:20:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:20:27 +0000
Subject: [issue7480] trite documentation issue.
In-Reply-To: <1260554940.07.0.376480280758.issue7480@psf.upfronthosting.co.za>
Message-ID: <1261246827.78.0.901807210539.issue7480@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Agreed, removed in r76892.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7480>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:23:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 18:23:36 +0000
Subject: [issue7508] Update 'file object' doc
In-Reply-To: <1260852224.61.0.450781946067.issue7508@psf.upfronthosting.co.za>
Message-ID: <1261247016.85.0.182085879503.issue7508@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've removed it in r76893. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7508>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:23:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:23:39 +0000
Subject: [issue7380] uuid.UUID.bytes gives a bytearray() instead of bytes
In-Reply-To: <1258979633.13.0.798699674887.issue7380@psf.upfronthosting.co.za>
Message-ID: <1261247019.08.0.0317702629807.issue7380@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r76895.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7380>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:28:52 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 19 Dec 2009 18:28:52 +0000
Subject: [issue7485] Error in FAQ entry '4.25 Why doesn't Python have a "with"
	statement for attribute assignments?'
In-Reply-To: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
Message-ID: <1261247332.34.0.335921672328.issue7485@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's in the last sentence of this section:

http://www.python.org/doc/faq/general/#why-doesn-t-python-have-a-with-statement-for-attribute-assignments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7485>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:32:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Dec 2009 18:32:17 +0000
Subject: [issue7525] Yield example doesn't work as is explained in the
	documentation
In-Reply-To: <1260976164.25.0.0113295033016.issue7525@psf.upfronthosting.co.za>
Message-ID: <1261247537.53.0.458371060617.issue7525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This only happens in Python 2.5, where GeneratorExit inherits from
Exception.  In 2.6, it inherits from BaseException and is therefore not
caught by the except clause.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7525>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:49:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 18:49:36 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261248576.45.0.415756423195.issue7545@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a possible patch for the Doc. I suppose the docstrings need
updating too?

----------
keywords: +patch
Added file: http://bugs.python.org/file15611/io-open-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 20:13:08 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Dec 2009 19:13:08 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1261249988.09.0.23829855952.issue4120@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

With the latest Python3.1 svn version of msvc9compiler.py, I get a
"can't use a string pattern on a bytes-like object" error. The
attached diff fixes the error.

----------
nosy: +skrah
versions: +Python 3.1 -Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file15612/3.1-byte-string.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Sat Dec 19 20:26:13 2009
From: report at bugs.python.org (Mark Florisson)
Date: Sat, 19 Dec 2009 19:26:13 +0000
Subject: [issue7548] If a generator raises TypeError when being unpacked,
	an unrelated error message is shown
In-Reply-To: <1261250773.36.0.925954913531.issue7548@psf.upfronthosting.co.za>
Message-ID: <1261250773.36.0.925954913531.issue7548@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

>>> list(*('boo' for x in [1]))
['b', 'o', 'o']
>>> list(*(range('error') for x in [1])) # notice the erroneous error 
message
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type object argument after * must be a sequence, not 
generator
>>> list(*[range('error') for x in [1]])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range() integer end argument expected, got str.
>>> list(*(int('error') for x in [1])) # does work correctly for 
ValueError
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <genexpr>
ValueError: invalid literal for int() with base 10: 'error'

----------
components: Interpreter Core
messages: 96642
nosy: eggy
severity: normal
status: open
title: If a generator raises TypeError when being unpacked, an unrelated error message is shown
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7548>
_______________________________________

From report at bugs.python.org  Sat Dec 19 20:31:34 2009
From: report at bugs.python.org (Nir Aides)
Date: Sat, 19 Dec 2009 19:31:34 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261251094.35.0.443976640676.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

isatty() and __iter__() of io.BufferedIOBase raise on closed file and 
__enter__() raises ValueError with different (generic) message. 

Should we keep the original GzipFile methods or prefer the implementation 
of io.BufferedIOBase?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:38:36 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 19 Dec 2009 20:38:36 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261255116.77.0.37711346911.issue7545@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Yep, I knew "full buffering" didn't mean "fill my RAM until crash" :p 
The only visible problem was the interpretation of positive/negative
buffering value, which wasn't the same in doc and in code. But the patch
seems to fix up the plot prettily well B-)
Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:40:02 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 20:40:02 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261255202.66.0.250793802785.issue7493@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Commit r76886 on Python 2.7 is fine.

But the patch is not merged completly on branches/py3k.

I prepared a new patch against py3k to fix what is missing.

----------
status: closed -> open
Added file: http://bugs.python.org/file15613/doc_faq_design_py3k_missing.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:48:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 20:48:52 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261255732.48.0.999592270843.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay;  I had to rework Marcos' patch a bit to get all the tests to pass.  
Here's the result.

I propose making these changes only in 2.7 and 3.2, not in 2.6 or 3.1;  
it's just possible that there's code out there that relies on some of 
the current behaviour;  I don't want to risk breaking that code in a 
bugfix release.  Does this seem reasonable?

It's possible I should be putting the tests in test_pow rather than 
test_float.

----------
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15614/float_pow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:10:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:10:18 +0000
Subject: [issue7545] IO buffering behaviour not properly documented
In-Reply-To: <1261238351.34.0.64888213085.issue7545@psf.upfronthosting.co.za>
Message-ID: <1261257018.92.0.812540057458.issue7545@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, fixed in a lot of revisions.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7545>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:16:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:16:30 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261257390.26.0.365941713279.issue7493@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I saw two small things:
- dict.has_key is still used instead of `in`
- Pyrex is mentioned, but not Cython (http://www.cython.org/); Cython is
probably much more active than Pyrex, though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:18:32 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 21:18:32 +0000
Subject: [issue7495] doc: patch for py3k/Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261257512.01.0.125038759959.issue7495@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

There's a syntax error in the string formatting example.

See additional patch.

I will consider backporting some parts of the patch to Py2.

----------
status: closed -> open
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15615/doc_faq_programming_fix_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:19:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:19:49 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1261251094.35.0.443976640676.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261257631.3339.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> isatty() and __iter__() of io.BufferedIOBase raise on closed file and 
> __enter__() raises ValueError with different (generic) message. 
> 
> Should we keep the original GzipFile methods or prefer the implementation 
> of io.BufferedIOBase?

It's fine to use the BufferedIOBase implementation. There's no reason to
call isatty() on or iterate over a closed file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:30:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:30:18 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1261257390.26.0.365941713279.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261258259.3339.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I saw two small things:
> - dict.has_key is still used instead of `in`

Florent pointed to me that it's not true. I was watching a stale
version, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:33:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:33:30 +0000
Subject: [issue7543] RFE: introduce "enum Py_Opcode"
In-Reply-To: <1261177606.42.0.69169668441.issue7543@psf.upfronthosting.co.za>
Message-ID: <1261258410.44.0.0593036760219.issue7543@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, I think when you debug CPython the biggest hurdle is not to lookup
the signification of opcodes :-)
Thanks, closing.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7543>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:33:45 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 19 Dec 2009 21:33:45 +0000
Subject: [issue7495] doc: patch for Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261258425.48.0.546775487664.issue7495@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: doc: patch for py3k/Doc/faq/programming.rst -> doc: patch for Doc/faq/programming.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:40:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Dec 2009 21:40:37 +0000
Subject: [issue7442] _localemodule.c: str2uni() with different LC_NUMERIC and
	LC_CTYPE
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1261258837.94.0.779256393853.issue7442@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Sat Dec 19 23:39:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Dec 2009 22:39:18 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261262358.07.0.658077433741.issue7528@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patches!

I'll look at the 2.7 PyLong_AsLongAndOverflow patch, and (assuming it 
looks good) apply it.

For the py3intcompat.c, it would be good to have some sort of consensus 
about this;  perhaps it should be discussed on python-dev.  One problem is 
deciding where to put the files---if there might eventually be many such 
files, there should be a reasonable plan.  Those files might also need to 
be divided into helper files for 3-to-2 translation and for 2-to-3 
translation.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Sun Dec 20 00:38:35 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Dec 2009 23:38:35 +0000
Subject: [issue7388] Documentation: capitalizations of the word 'python'
	needed when used as a name
In-Reply-To: <1259055832.84.0.933127183577.issue7388@psf.upfronthosting.co.za>
Message-ID: <1261265915.66.0.347534833404.issue7388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done in r76904 (trunk), r76905 (release26-maint), r76906 (py3k), r76907
(release31-maint), thanks for the report (there were a few more, I fixed
those too).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7388>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:05:23 2009
From: report at bugs.python.org (John Wells)
Date: Sun, 20 Dec 2009 00:05:23 +0000
Subject: [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>


New submission from John Wells <johnx.ca at gmail.com>:

I installed 2.6.4 x86 on Win7 x64. My Python app runs fine, but I get
daily errors in the event app log:

SOURCE: SideBySide
EVENT ID: 33
MESSAGE: Activation context generation failed for
"C:\WinUtils\Python26\Lib\distutils\command\wininst-8_d.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0"
could not be found. Please use sxstrace.exe for detailed diagnosis. 

I'm not a developer, but Google suggests to me that the reference to
"Microsoft.VC80.DebugCRT" indicates that some part of Python 2.6.4 was
linked to the debug version of the VC++ 2005 DLLs. Apparently this
shouldn't have been done, since the debug DLLs can't be redistributed.

Or is there some other fix for this?

----------
components: Windows
messages: 96655
nosy: jw113
severity: normal
status: open
title: 2.6.4 Win32 linked to debug DLLs?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:15:00 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Dec 2009 00:15:00 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261268100.18.0.80505071495.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This attached patch addresses the issue Eric mentioned - I don't know
how I missed this before. I will attempt to run the tests on XP again
with this change, but have not yet done so.

----------
Added file: http://bugs.python.org/file15616/windows symlink draft 17.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:19:50 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 00:19:50 +0000
Subject: [issue7495] doc: patch for Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261268390.66.0.0807092043367.issue7495@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch backported to trunk.
It fixes typos and recommend best practices 'somestring'.format(...),
and '0o777' and '22 // 3'...

----------
Added file: http://bugs.python.org/file15617/doc_faq_programming.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:22:49 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 00:22:49 +0000
Subject: [issue7495] doc: patch for Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261268569.18.0.996356427307.issue7495@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15615/doc_faq_programming_fix_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:23:25 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 00:23:25 +0000
Subject: [issue7495] doc: patch for Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261268605.01.0.160798527275.issue7495@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15618/doc_faq_programming_py3k_updated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:09:04 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Dec 2009 01:09:04 +0000
Subject: [issue7544] multiprocessing.Pool(): Fatal Python error:
	PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261239968.3.0.677667478927.issue7544@psf.upfronthosting.co.za>
Message-ID: <200912200209.08411.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Use a core dump: good idea!

haypo> Using my fuzzer (Fusil) on Python trunk, I got sometimes 
haypo> errors on multiprocessing.Pool():
haypo> 
haypo>    Fatal Python error: PyEval_AcquireThread: NULL new thread state

I read the source code of the thread module. This error means that 
PyThreadState_New() returns NULL which occurs if malloc() failed. I hit this 
error using my fuzzer because the fuzzer limits the total memory to something 
around 100 MB using setrlimit().

Said differently: in low memory condition, creating a new thread may exit the 
whole Python process if a memory allocation fail.

--

Sometimes, I get another error, similar to the "NULL new thread state" error:

   Fatal Python error: Couldn't create autoTLSkey mapping

I guess that the reason is the same: memory allocation failed. It should be 
the malloc() in find_key() (Python/thread.c).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sun Dec 20 07:06:01 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 20 Dec 2009 06:06:01 +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: <1261289161.76.0.942884618182.issue7291@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed and Committed revision 76908 in the trunk.

----------
keywords:  -needs review
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:22:11 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 20 Dec 2009 07:22:11 +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: <1261293731.49.0.203123969302.issue7291@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed through reversions r76908, r76909, r76910, r76911

Thanks for the patch, Tatsuhiro Tsujikawa.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:33:01 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 20 Dec 2009 07:33:01 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261294381.5.0.136512231811.issue7471@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file15589/gzip_7471_py27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:34:46 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 20 Dec 2009 07:34:46 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261294486.18.0.15061039623.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

uploaded updated patch for Python 2.7.

----------
Added file: http://bugs.python.org/file15619/gzip_7471_py27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:35:34 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 20 Dec 2009 07:35:34 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1261294534.38.0.769480276567.issue7471@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Uploaded patch for Python 3.2.

----------
Added file: http://bugs.python.org/file15620/gzip_7471_py32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7471>
_______________________________________

From report at bugs.python.org  Sun Dec 20 09:12:13 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Dec 2009 08:12:13 +0000
Subject: [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1261296733.58.0.229205840958.issue7549@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

wininst*.exe is the binary that gets patched into the zip file when you
build a windows installer out of your Python package. wininst-8_d.exe is
the debug version of that, so it's not surprising that it is linked with
the debug CRT.

What is really puzzling here is that something is trying to execute it
on your system. That should never happen.

I guess you are right that the file shouldn't have been shipped; if the
messages bother you, just delete it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________

From report at bugs.python.org  Sun Dec 20 09:30:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Dec 2009 08:30:56 +0000
Subject: [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1261297856.17.0.219416804847.issue7549@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now removed these files from my build directory, so they won't
get included in future releases.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________

From report at bugs.python.org  Sun Dec 20 10:18:34 2009
From: report at bugs.python.org (lekma)
Date: Sun, 20 Dec 2009 09:18:34 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1261300714.11.0.935563816416.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

this one addresses Antoines's comments (with the help of R. David Murray).

----------
Added file: http://bugs.python.org/file15621/Issue7523_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Sun Dec 20 10:21:53 2009
From: report at bugs.python.org (lekma)
Date: Sun, 20 Dec 2009 09:21:53 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261300913.82.0.95122211918.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

Is there any chance that this will make it in?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 10:29:03 2009
From: report at bugs.python.org (John Wells)
Date: Sun, 20 Dec 2009 09:29:03 +0000
Subject: [issue7549] 2.6.4 Win32 linked to debug DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <1261301343.96.0.168061525155.issue7549@psf.upfronthosting.co.za>


John Wells <johnx.ca at gmail.com> added the comment:

Thanks for the quick follow-up. 

You're right -- given your explanation of what wininst-8_d.exe is, the
interesting question now is why it is running. I get two errors every
day, in the early hours of the morning. Before I delete this file, I
will see if ProcessMonitor will provide an answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7549>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:20:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 10:20:10 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261304410.57.0.703693049728.issue7528@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The longobject.diff patch looks fine, modulo some whitespace nits.  (Older 
C source files use width-8 tabs for indentation.)

Are you interested in adding documentation and tests (the latter in the 
test_capi module)?

One thing about the patch struck me as odd:  the use of nb_int means that 
PyLong_AsLongAndOverflow will happily accept floats, Decimal instances, 
etc.  Ideally, this would be nb_index instead, but I guess it has to stay 
nb_int for now, for consistency with PyLong_AsLong.  py3k also uses nb_int 
here and in various other PyLong_As*** functions;  I think these should be 
changed, but that's another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:31:14 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 10:31:14 +0000
Subject: [issue7550] PyLong_As* methods should not call nb_int.
In-Reply-To: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
Message-ID: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The following C-API functions:

PyLong_AsLongAndOverflow
PyLong_AsUnsignedLongMask
PyLong_AsLongLong
PyLong_AsUnsignedLongLongMask

call nb_int for inputs that don't satisfy PyLong_Check.  They thus accept 
floats, Decimal instances, etc.  They should probably call nb_index 
instead (or perhaps accept only instances of int).

The uses of these functions within the Python source should be checked, to 
see what consequences (if any) this change would have for Python 
semantics; it's possible that some of these consequences would fall under 
the moratorium (PEP 3003).  In any case, this change probably requires a 
1-release deprecation period.

----------
components: Interpreter Core
messages: 96670
nosy: mark.dickinson
severity: normal
status: open
title: PyLong_As* methods should not call nb_int.
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7550>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:33:12 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 10:33:12 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261305192.67.0.0565043401668.issue7376@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15392/issue7376_usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:36:04 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 10:36:04 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261305364.7.0.0872372975345.issue7376@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Minor update: replaced '{}' by '{0}' for compatibility with 2.6.

Ready for review and merge.

----------
Added file: http://bugs.python.org/file15622/issue7376_usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:36:48 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 10:36:48 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261305408.99.0.17080704676.issue7376@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:37:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 10:37:05 +0000
Subject: [issue7550] PyLong_As* methods should not call nb_int.
In-Reply-To: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
Message-ID: <1261305425.99.0.192296621832.issue7550@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Since PyLong_AsLong goes through PyLong_AsLongAndOverflow, this change 
would also affect calls to PyLong_AsLong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7550>
_______________________________________

From report at bugs.python.org  Sun Dec 20 12:47:48 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 11:47:48 +0000
Subject: [issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown
	encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1261309668.94.0.581807847316.issue7441@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thank you for your report.
See #6501 about the Fatal Error
See #6058 for the feature request (cp65001 on windows).

----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7441>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:06:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:06:16 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261317976.72.0.0796436824767.issue7033@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since it's a new CAPI I think it should probably be discussed briefly on
python-dev.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:08:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Dec 2009 14:08:09 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261318089.3.0.907580722783.issue7033@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since it's a new CAPI I think it should probably be discussed briefly on
> python-dev.

So do I.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:09:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:09:11 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261318151.68.0.0388719901091.issue7033@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also, what about tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:09:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 14:09:53 +0000
Subject: [issue7550] PyLong_As* methods should not call nb_int.
In-Reply-To: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
Message-ID: <1261318193.95.0.565152788308.issue7550@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just as an experiment, I removed the calls to nb_int and ran the test-
suite.  The only test failures were in test_ctypes, test_getargs2, and 
test_math.

The test_math failure was from math.factorial depending on PyLong_AsLong 
to convert floats;  I've fixed this in r76916 (trunk) and r76917 (py3k).

One consequence of not having PyLong_AsLong automatically call nb_int 
would be that math.factorial(decimal.Decimal('-0.53')) is no longer valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7550>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:13:37 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Dec 2009 14:13:37 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261318417.43.0.488956960411.issue7033@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Funnily, I already did ask on python-dev, and only got one (+1) answer
from Brett.  I was going to add it some time when I have more cycles for
Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:14:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:14:51 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261318491.04.0.719019471578.issue7033@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, I'd say that counts as a brief discussion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:21:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Dec 2009 14:21:35 +0000
Subject: [issue7495] doc: patch for Doc/faq/programming.rst
In-Reply-To: <1260731907.1.0.727952495517.issue7495@psf.upfronthosting.co.za>
Message-ID: <1261318895.66.0.162038641452.issue7495@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r76920 and r76922.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7495>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:23:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Dec 2009 14:23:22 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261319002.84.0.212767347349.issue7033@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One nitpick: Python/errors.c uses tabs for indentation, your patch
should as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:25:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Dec 2009 14:25:38 +0000
Subject: [issue7493] doc: patch for Doc/faq/design.rst
In-Reply-To: <1260731119.97.0.226497507074.issue7493@psf.upfronthosting.co.za>
Message-ID: <1261319138.12.0.859544571833.issue7493@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r76923.

For future patches, please use notes sparingly, and warnings even more
so.  Not every sentences starting with "Note that..." needs to be a
Note.  Also, Notes should contain whole sentences (i.e. the first word
is uppercased).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7493>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:26:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:26:16 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261319176.07.0.404332940082.issue7376@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:26:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:26:39 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261319199.37.0.92322940686.issue7376@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:27:34 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 14:27:34 +0000
Subject: [issue4380] Deepcopy of functools.partial gives wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1261319254.78.0.0685816280399.issue4380@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4380>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:28:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Dec 2009 14:28:54 +0000
Subject: [issue7485] Error in FAQ entry '4.25 Why doesn't Python have a "with"
	statement for attribute assignments?'
In-Reply-To: <1260620197.76.0.962971657783.issue7485@psf.upfronthosting.co.za>
Message-ID: <1261319334.3.0.328711717147.issue7485@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This sentence has already been removed from the version of the FAQ that
is now in the source tree:
http://docs.python.org/dev/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7485>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:37:35 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 14:37:35 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1261319855.87.0.400528135911.issue6501@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch to prevent crash when PYTHONIOENCODING is invalid:

~ $ PYTHONIOENCODING= ./python 
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Abandon

----------
keywords: +patch
nosy: +flox
versions: +Python 3.2
Added file: http://bugs.python.org/file15623/issue6501_PYTHONIOENCODING_crash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:51:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 14:51:25 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261320685.69.0.563167168855.issue7376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch results in this type of usage message:

usage: /home/rdmurray/python/trunk/Lib/doctest.py [-v] file ...

which while technically correct isn't the way I called it.  It would be
better to at least use basename on argv[0].  (I wonder if there's some
way for a module to know it was called via -m...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:21:13 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 15:21:13 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261322473.79.0.381583524211.issue7381@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Committed to r76925 (trunk) and r76926 (py3k).

Thank you Georg.

I see small remaining inconsistencies in the docstring.
Either we agree with implicit "import subprocess" or "from subprocess
import *", but we should not mix both.

See additional patches:
 * issue7381_v3.diff
 * issue7381_py3k_v3.diff

----------
Added file: http://bugs.python.org/file15624/issue7381_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:21:43 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 15:21:43 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261322503.1.0.0986876739723.issue7381@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15625/issue7381_py3k_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:24:42 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Dec 2009 15:24:42 +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: <1261322682.42.0.681506637035.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Short summary from a discussion on #python-dev:
- verb form: ?This function is built in.?
- adjective form: ?``str`` is a built-in function?
- noun form (not mainstream English, but usual in programming contexts):
?``repr`` is a builtin?, ?prefer the builtins?.

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5341>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:31:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 15:31:52 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1261323112.42.0.13480309219.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  That's unfortunate:  for argument type in 'bBHiIlkKn', an attempt to 
pass a float results in a DeprecationWarning.  For type 'L', there's no 
DeprecationWarning, and the float is silently truncated.  So for type 'L' 
I guess we still have to go through a round of DeprecationWarning.

I'm not sure what 'h' does;  there don't appear to be any tests for it, 
currently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:41:36 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Dec 2009 15:41:36 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1261323696.4.0.80118287685.issue7351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your patch need to include an alias (BadZipfile = BadZipFile) to
preserve compatibility with old pickles, as explains msg95477.

Cheers

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:42:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Dec 2009 15:42:20 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1261323740.11.0.954841859496.issue7351@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

While the mismatched casing is unfortunate, I don't think changing it
for the sake of aesthetics is a good deal given that many existing
programs will have to be converted to the new spelling.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:05:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 16:05:35 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1261325135.16.0.33560601939.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

'h' also produces a DeprecationWarning;  I just added the missing tests 
for it in r76930 (trunk) and r76931 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:33:51 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 20 Dec 2009 16:33:51 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261326831.83.0.796881440111.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I will work on documentation and test case patches.

Per comments on python-dev, there doesn't appear to be interest in
distributing forward compatibility files. I will update the bug report
with a slightly revised version of py3intcompat.c and just leave it at that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:36:50 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 16:36:50 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261327010.09.0.595730443353.issue7376@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Variant which gives different usage messages:

~ $ ./python -m doctest
usage: doctest [-v] file ...

~ $ ./python Lib/doctest.py
usage: Lib/doctest.py [-v] file ...

----------
Added file: http://bugs.python.org/file15626/issue7376_usage_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:39:52 2009
From: report at bugs.python.org (Andreas Jung)
Date: Sun, 20 Dec 2009 16:39:52 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode() a
	unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>


New submission from Andreas Jung <ajung at users.sourceforge.net>:

We encountered a pretty bizarre behavior of Python 2.4.6 while decoding a 600MB long unicode string 
'data':

Python 2.4.6 (8GB RAM, 64 bit)

(Pdb) type(data)
<type 'unicode'>

(Pdb) len(data)
601794657

(Pdb) data2=data.encode('utf-8')
*** SystemError: Negative size passed to PyString_FromStringAndSize

Assuming that this has something to do with a 512MB limit:

(Pdb) data2=data[:512*1024*1024].encode('utf-8')
*** SystemError: Negative size passed to PyString_FromStringAndSize

Same bug...now with 512MB - 1 byte:

(Pdb) data2=data[:(256*1024*1024)-1].encode('utf-8')
OverflowError

Cross-check on a different Linux box (4GB RAM, 4 GB Swap, 64 bit)

ajung at blackmoon:~> python2.4
Python 2.4.5 (#1, Jun  9 2008, 10:35:12) 
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> data = u'x'*601794657
>>> data2= data.encode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

Where is this different behavior coming from?

----------
messages: 96695
nosy: ajung
severity: normal
status: open
title: SystemError/MemoryError/OverflowErrors on encode() a unicode string
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:48:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 16:48:40 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261327720.22.0.613621614845.issue7376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I has already adjusted the patch, in a slightly different fashion, but
to much the same effect.  Checked in to trunk in r76935.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:09:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 17:09:07 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode() a
	unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261328947.34.0.931534632965.issue7551@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is the first machine also a Linux machine?  Perhaps the difference is that 
the first machine has a wide-unicode build (i.e., it uses UCS4 internally) 
and the other doesn't?

Unfortunately there's not much that the python-devs can do about this 
unless the problem is still present in Python 2.6:  Python 2.4 is now more 
than 5 years old and is no longer maintained, while Python 2.5 is only 
receiving security fixes at this stage.  Can you reproduce the problem 
with Python 2.6?

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:19:16 2009
From: report at bugs.python.org (Andreas Jung)
Date: Sun, 20 Dec 2009 17:19:16 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode() a
	unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261329556.36.0.0024473496065.issue7551@psf.upfronthosting.co.za>


Andreas Jung <ajung at users.sourceforge.net> added the comment:

Both systems are Linux system running a narrow Python build.

The problem does not occur with Python 2.5 or 2.6.

Unfortunately this error occurs with Zope 2 which is tied (at least with 
versions prior to Zope 2.12 to Python 2.4).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:36:49 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 20 Dec 2009 17:36:49 +0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1261330609.51.0.256494417787.issue1286@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I reviewed the patches attached.
- The patch to add Context Manager support for fileinput.py seems good.
It has docs too.

This discussion did not conclude on the need for Context Manager for
StringIO. With py3k having it, it should be good for py2.7 to provide
the support too. The attached patch seems good enough, Docs can be added
further.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:38:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2009 17:38:33 +0000
Subject: [issue7376] "python -m doctest" results in FAIL: Doctest:
	__main__.DebugRunner
In-Reply-To: <1258912633.73.0.334320263097.issue7376@psf.upfronthosting.co.za>
Message-ID: <1261330713.21.0.882128695161.issue7376@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug doesn't exist on 2.6, so I'm not backporting.  Ported to py3k in
r76937 and backported to 3.1 in r76938.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7376>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:41:40 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 17:41: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: <1261330900.74.0.964415568222.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Many fixes of modules and packages outside Lib/test

Dev notes:
 * for bsddb and dbhash the warning message should include "module" to
be ignored by "test_support.import_module"
 * patch for mailbox is copied from Lib/cgi.py
 * other fixes are trivial

----------
keywords: +patch
Added file: http://bugs.python.org/file15627/issue7092_lib_many_fixes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:46:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 17:46:40 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode() a
	unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261331200.96.0.262015712179.issue7551@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, the signature of PyUnicode_Encode in Python 2.4 (see 
Objects/unicodeobject.c) is:

PyObject *PyUnicode_Encode(const Py_UNICODE *s,
			   int size,
			   const char *encoding,
			   const char *errors)

which looks like it might be relevant to the problems you're seeing.  In 
2.6, the size has type Py_ssize_t instead, which should be a 64-bit type 
on 64-bit Linux.

Closing this, since it's out of date for current Python.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:47:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Dec 2009 17:47:11 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1261331231.51.0.40573946908.issue6501@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, this might prevent the crash but how does the system behave
afterwards? Do the standard streams use utf-8 by default?
At the minimum, we should still output a warning on stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:49:05 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 17:49:05 +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: <1261331345.83.0.788114060569.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch for the compiler package and astgen.py tool.

Basically:
  def __init__(self, (left, right), lineno=None):

==>

  def __init__(self, leftright, lineno=None):

----------
Added file: http://bugs.python.org/file15628/issue7092_compiler.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:59:48 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 20 Dec 2009 17:59:48 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1261331988.26.0.442062507526.issue1673007@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Having a HEAD request for urllib2 might be a good idea. I shall use this
patch to add the functionality.

But, having a history support in the urllib2 module is not a good idea
IMO. It is best left to the clients which might use urllib2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:01:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Dec 2009 18:01:58 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1261332118.39.0.624593250918.issue1673007@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1 for HEAD

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:02:33 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:02: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: <1261332153.4.0.876809359069.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch for pprint: when keys are not the same type, "-3" emits warnings.

Partial backport from Py3k.

----------
Added file: http://bugs.python.org/file15629/issue7092_pprint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:14:43 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Dec 2009 18:14:43 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1261332883.85.0.210026907798.issue1673007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If you know you want an HEAD request, it means you already know it
will be an HTTP request, so why not directly use httplib or httplib2
instead of urllib?

Aside: s/sended/sent/

Cheers

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:15:45 2009
From: report at bugs.python.org (JP St. Pierre)
Date: Sun, 20 Dec 2009 18:15:45 +0000
Subject: [issue7552] uploading fails on long passwords
In-Reply-To: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>
Message-ID: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>


New submission from JP St. Pierre <jstpierre at mecheye.net>:

Uploading a file to PyPI fails when a user has a long password, as
base64.encodestring linewraps data. Either replace '\n' with '', or use
base64.standard_b64encode

----------
assignee: tarek
components: Distutils
messages: 96709
nosy: magcius, tarek
severity: normal
status: open
title: uploading fails on long passwords
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7552>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:27:00 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:27:00 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

This test do not test "true division" contrary to what is claimed.

    for zero in ["huge / 0", "huge / 0L", "mhuge / 0", "mhuge / 0L"]:
        self.assertRaises(ZeroDivisionError, eval, zero, namespace)

Because it uses the module "unittest" to eval the expression.
And __future__.division is not active in unittest module.

Other tests were OK.

----------
components: Tests
messages: 96710
nosy: flox
priority: low
severity: normal
status: open
title: test_long_future is faulty
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:29:21 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:29:21 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261333761.47.0.974992041653.issue7553@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch which fixes the tests: call the "eval" in the module.

----------
keywords: +patch
Added file: http://bugs.python.org/file15630/issue7553_test_long_future.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:32:59 2009
From: report at bugs.python.org (JP St. Pierre)
Date: Sun, 20 Dec 2009 18:32:59 +0000
Subject: [issue7552] uploading fails on long passwords
In-Reply-To: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>
Message-ID: <1261333979.95.0.711734018888.issue7552@psf.upfronthosting.co.za>


JP St. Pierre <jstpierre at mecheye.net> added the comment:

This patch should fix the bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file15631/auth_7552.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7552>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:34:25 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:34:25 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261334065.18.0.808320145194.issue7553@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:42:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Dec 2009 18:42:16 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode() a
	unicode string
In-Reply-To: <1261327192.12.0.403194301804.issue7551@psf.upfronthosting.co.za>
Message-ID: <1261334536.41.0.59747454419.issue7551@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Just to support Mark's decision: Python 2.4 is no longer maintained; you
are on your own with any problems you encounter with it. So closing it
as "won't fix" would also have been appropriate.

The same holds for 2.5, unless you can demonstrate this to cause
security issues (e.g. crashing the Python interpreter).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:46:10 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 18:46:10 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261334770.04.0.598974367357.issue7553@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removed 2.6 from the todolist. Not worth the effort.

"with self.assertRaises(...):" construct is not supported in 2.6.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:50:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Dec 2009 18:50:38 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261335038.94.0.829351264514.issue7553@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

eval() inherits the flags of the module it is used in.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:01:31 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 19:01:31 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261335691.67.0.019960143049.issue7553@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Let me show the issue:

~ $ cat bar.py
def apply_(func, args=(), kw={}):
    return func(*args, **kw)

~ $ cat foo.py
from __future__ import division
import bar

def test():
    assert eval('1/2') == .5
    assert apply(eval, ('1/2',)) == .5

    # This test yield AssertionError
    assert bar.apply_(eval, ('1/2',)) == .5

test()

~ $ ./python foo.py
Traceback (most recent call last):
  File "foo.py", line 11, in <module>
    test()
  File "foo.py", line 9, in test
    assert bar.apply_(eval, ('1/2',)) == .5
AssertionError


Then replace "foo.py" by "test_long_future.py"
and "bar.py" by "Lib/unittest/case.py" ...

----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:29:58 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Dec 2009 19:29:58 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261337398.52.0.792599789828.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I created a comprehensive set of tests to check all the possibilities
that I listed in msg96319 and updated the patch for Object/exceptions.c.
Without patch all the test_*_with_overridden__str__ and
test_builtin_exceptions fail, both on 2.6 and on trunk, with the patch
all the tests pass.
The code in exceptions.c now does the equivalent of unicode(e.__str__())
instead of unicode(str(e)). If e.__str__() returns a non-ascii unicode
string, unicode() now shows the message instead of raising an error.

----------
Added file: http://bugs.python.org/file15632/issue6108-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:37:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 19:37:59 +0000
Subject: [issue7554] Some tests in test_cmath should use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

These tests do not pass the right arguments to rAssertAlmostEqual.
They should use assertAlmostEqual instead.

(around line 123)

        self.rAssertAlmostEqual(cmath.pi, pi_expected, 9,
            "cmath.pi is %s; should be %s" % (cmath.pi, pi_expected))
        self.rAssertAlmostEqual(cmath.e,  e_expected, 9,
            "cmath.e is %s; should be %s" % (cmath.e, e_expected))

----------
components: Tests
messages: 96718
nosy: flox
severity: normal
status: open
title: Some tests in test_cmath should use rAssertAlmostEqual incorrectly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:38:12 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 19:38:12 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261337892.02.0.750910288773.issue7554@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: Some tests in test_cmath should use rAssertAlmostEqual incorrectly -> Some tests in test_cmath use rAssertAlmostEqual incorrectly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:41:36 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 19:41:36 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261338096.43.0.573829981988.issue7554@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I've done a review of this test file, and removed code duplication
between function "almostEqualF" and method "rAssertAlmostEqual".

(and changed some syntax to make "-3" happy)

----------
keywords: +patch
Added file: http://bugs.python.org/file15633/issue7554_cmath.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:59:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 19:59:33 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261339173.69.0.478014114669.issue7554@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  Fixed in r76941 (trunk) and r76942 (release26-maint)  (with 
tweaks in the following two revisions).

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:00:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 20:00:25 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261339225.17.0.83539578315.issue7554@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops;  I didn't see your patch until too late.

----------
assignee:  -> mark.dickinson
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:27:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 20:27:22 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261340842.98.0.989191669206.issue7554@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

test_math changes applied in r76945 (trunk), and backported to release26-
maint in r76946 for good measure.  For the sake of ease of maintenance, I 
used code that matched the existing py3k code, rather than the exact code 
Florent provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:41:04 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Dec 2009 20:41:04 +0000
Subject: [issue7554] Some tests in test_cmath use rAssertAlmostEqual
	incorrectly
In-Reply-To: <1261337879.76.0.460831338952.issue7554@psf.upfronthosting.co.za>
Message-ID: <1261341664.99.0.711245258124.issue7554@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied the test_cmath part of the patch in r76948 (trunk) and r76950 
(py3k).  I was too lazy to backport to the maintenance releases, mostly 
because that would have involved replacing all the '{}'s in format strings 
with numbered versions. ('{0}' ...)

Thanks again, Florent!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7554>
_______________________________________

From report at bugs.python.org  Sun Dec 20 23:55:35 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 22:55:35 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261349735.99.0.180137463722.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Additional test cases for rfind.

----------
Added file: http://bugs.python.org/file15634/issue7462_string_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:08:15 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:08:15 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261350495.75.0.37335951836.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Bench results show the benefit.

And attached patch for stringbench tool.

----------
Added file: http://bugs.python.org/file15635/stringbench_rfind.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:08:35 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:08:35 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261350515.45.0.315893770386.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15636/bench_rfind_algorithms.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:26:08 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:26:08 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261351568.51.0.133863866299.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

There's a typo in the patch for stringbench.

Updated patch (with rindex tests, too).

----------
Added file: http://bugs.python.org/file15637/stringbench_rfind_rindex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:26:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:26:18 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261351578.55.0.701685119123.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15635/stringbench_rfind.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:55:09 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:55:09 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261353309.81.0.156257413711.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Updated benchmarks.

 str    unicode
 (ms)   (ms)

 ========== late match, 100 characters
                s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s)
 32.89  15.65   rfind (classic)
 32.81  15.63   rindex (classic)
 11.77  13.27   rfind (fastsearch)
 11.78  13.40   rindex (fastsearch)

 ========== late match, two characters
 4.34   2.36    ("C"+"AB"*300).rfind("CA") (classic)
 4.44   2.36    ("C"+"AB"*300).rindex("CA") (classic)
 2.10   2.31    ("C"+"AB"*300).rfind("CA") (fastsearch)
 2.10   2.32    ("C"+"AB"*300).rindex("CA") (fastsearch)

 ========== no match, two characters
 14.12  13.46   ("AB"*1000).rfind("BC") (classic)
 7.67   8.26    ("AB"*1000).rfind("BC") (fastsearch)

----------
stage:  -> patch review
Added file: http://bugs.python.org/file15638/bench_rfind_algorithms_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:55:43 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 20 Dec 2009 23:55:43 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261353343.97.0.501428328444.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15636/bench_rfind_algorithms.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 01:08:47 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Dec 2009 00:08:47 +0000
Subject: [issue7552] uploading fails on long passwords
In-Reply-To: <1261332945.8.0.343157479139.issue7552@psf.upfronthosting.co.za>
Message-ID: <1261354127.99.0.308779302149.issue7552@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r76952, r76953, r76954 and r76955

Thanks magcius !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7552>
_______________________________________

From report at bugs.python.org  Mon Dec 21 01:43:48 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 00:43:48 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261356228.61.0.229282623166.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Need additional patch for rpartition and rsplit on string, unicode and
bytearray objects.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 02:17:35 2009
From: report at bugs.python.org (Marius Gedminas)
Date: Mon, 21 Dec 2009 01:17:35 +0000
Subject: [issue7539] unicode exceptions terminate pdb.pm() loop
In-Reply-To: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
Message-ID: <1261358255.48.0.599683660367.issue7539@psf.upfronthosting.co.za>


Marius Gedminas <marius at gedmin.as> added the comment:

I don't know what I was smoking when I said pdb.set_trace() wasn't 
affected; I just reproduced the bug with 

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 pdb
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) raise Exception(u'\xff')
*** Exception: Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/bdb.py", line 50, in trace_dispatch
    return self.dispatch_return(frame, arg)
  File "/usr/lib/python2.6/bdb.py", line 83, in dispatch_return
    self.user_return(frame, arg)
  File "/usr/lib/python2.6/pdb.py", line 176, in user_return
    self.interaction(frame, None)
  File "/usr/lib/python2.6/pdb.py", line 194, in interaction
    self.cmdloop()
  File "/usr/lib/python2.6/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/usr/lib/python2.6/pdb.py", line 261, in onecmd
    return cmd.Cmd.onecmd(self, line)
  File "/usr/lib/python2.6/cmd.py", line 218, in onecmd
    return self.default(line)
  File "/usr/lib/python2.6/pdb.py", line 226, in default
    print >>self.stdout, '***', exc_type_name + ':', v
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in 
position 0: ordinal not in range(128)
>>> 

This makes testing simpler; attached is my very first patch for the 
Python test suite, please review it mercilessly.

(I verified that the test will pass once the bug is fixed by replacing 
U+00FF with U+0001 and seeing that it passes.)

----------
keywords: +patch
Added file: http://bugs.python.org/file15639/test-pdb-unicode-exc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7539>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:07:15 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 21 Dec 2009 03:07:15 +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: <1261364835.6.0.59075931517.issue7540@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:55:52 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 21 Dec 2009 05:55:52 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261374952.28.0.439843493567.issue7528@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I uploaded a new consolidated diff that includes the original patch with
(hopefully) correct whitespace, some tests, and doc updates.

The test just verifies that overflow is set/cleared properly. Proper
conversions to long are already tested in test_capi. Let me know if I
should add more tests.

I couldn't find any tests for LongAndOverflow in 3.x.

----------
Added file: http://bugs.python.org/file15640/patch7528.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:24:34 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Dec 2009 09:24:34 +0000
Subject: [issue7551] SystemError/MemoryError/OverflowErrors on encode()
	a	unicode string
In-Reply-To: <1261331200.96.0.262015712179.issue7551@psf.upfronthosting.co.za>
Message-ID: <4B2F3ECE.6080709@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

All string length calculations in Python 2.4 are done using ints
which are 32-bit, even on 64-bit platforms.

Since UTF-8 can use up to 4 bytes per Unicode code point, the encoder
overallocates the needed chunk of memory to len*4 bytes. This
will go straight over the 2GB limit the 32-bit int imposes if
you try to encode a 512M code point Unicode string.

The reason for using ints to represent string length is simple:
no one really expected that someone would work with 2GB strings
in memory at the time the string API was designed (large hard
drives had around 2GB at that time) - strings of such size are
simply not supported by Python 2.4.

BTW: I wouldn't really count on Python 2.4 working properly on
64-bit platforms. A lot of issues were fixed in Python 2.5
related to 32/64-bit differences.

----------
nosy: +lemburg
title: SystemError/MemoryError/OverflowErrors on encode() a unicode string -> SystemError/MemoryError/OverflowErrors on encode() a	unicode string

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7551>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:25:58 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 10:25:58 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>


New submission from Leo Spidian <zhangdongying1986 at gmail.com>:

isinstance() function returns False while surpposed to return True
============ tt.py =================
import ss
class tt:
    def __init__(self, s):
        if not isinstance(s, ss.ss):
            raise Exception("s is not an instance of ss.ss")
====================================
============ ss.py =================
import tt
class sss:
    pass
class ss(sss):
    pass
if __name__ == '__main__':
    s = ss()
    print isinstance(s, ss)
    t = tt.tt(s)
====================================
Run ss.py:
True
Traceback (most recent call last):
  File "D:\workspace\PostDocs\ss.py", line 11, in <module>
    t = tt.tt(s)
  File "D:\workspace\PostDocs\tt.py", line 6, in __init__
    raise Exception("s is not an instance of ss.ss")
Exception: s is not an instance of ss.ss

----------
components: None
files: ss.py
messages: 96733
nosy: leospidian
severity: normal
status: open
title: Wrong return value of isinstance() function
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15641/ss.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:26:34 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 10:26:34 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261391194.32.0.563149396819.issue7555@psf.upfronthosting.co.za>


Changes by Leo Spidian <zhangdongying1986 at gmail.com>:


Removed file: http://bugs.python.org/file15641/ss.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:27:02 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 10:27:02 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261391222.69.0.964673841121.issue7555@psf.upfronthosting.co.za>


Changes by Leo Spidian <zhangdongying1986 at gmail.com>:


Added file: http://bugs.python.org/file15642/ss.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:27:21 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 10:27:21 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261391241.59.0.210662244675.issue7555@psf.upfronthosting.co.za>


Changes by Leo Spidian <zhangdongying1986 at gmail.com>:


Added file: http://bugs.python.org/file15643/tt.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:58:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 10:58:52 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261393132.04.0.876505523327.issue7555@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

While I agree it's confusing, I think this is working as designed.  The 
problem is coming from the circular import.  If you add a "print id(ss)" 
between the definition of class ss and the "if __name__ == '__main__'" 
you'll see that ss ends up being defined twice.  s is an instance of one 
of the ss classes, but not the other.

See 

http://effbot.org/zone/import-confusion.htm

for more.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:05:02 2009
From: report at bugs.python.org (Retro)
Date: Mon, 21 Dec 2009 11:05:02 +0000
Subject: [issue7482] Improve ZeroDivisionError message for float and complex
	object
In-Reply-To: <1260569848.94.0.64759795971.issue7482@psf.upfronthosting.co.za>
Message-ID: <1261393502.89.0.209918787235.issue7482@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

The patch is *almost* okay.

errno = 0;
 	div = c_quot(v->cval,w->cval); /* The raw divisor value. */
 	if (errno == EDOM) {
-		PyErr_SetString(PyExc_ZeroDivisionError, "complex remainder");
+		PyErr_SetString(PyExc_ZeroDivisionError, "complex modulo by zero");
 		return NULL;


It should be as expressed in the code above. In the patch, the fixed
string is "complex remainder by zero", but this is broken English. I
propose "complex modulo by zero". Please fix your patch and we're good.

----------
nosy: +Retro
versions: +Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7482>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:11:40 2009
From: report at bugs.python.org (Leo Spidian)
Date: Mon, 21 Dec 2009 11:11:40 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261393900.27.0.122377479349.issue7555@psf.upfronthosting.co.za>


Leo Spidian <zhangdongying1986 at gmail.com> added the comment:

Thank you very much!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:26:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 11:26:12 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261394772.76.0.731240298005.issue7528@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Perfect---thank you!  Applied to trunk in r76963.  I tweaked the main 
comment and docstring, wrapped a long line, and replaced two instances of 
'*overflow = Py_SIZE(v) > 0 ? 1 : -1' with simply '*overflow = sign'.  I 
also expanded the test a bit to check for 1 and -1 *overflow values, 
rather than just checking for nonzero *overflow.

I'll propagate your tests to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:32:05 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 11:32:05 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261395125.91.0.677343533994.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Updated patch with optimization for:
 * rfind
 * rindex
 * rsplit
 * rpartition

And an optimization was implemented in r46398 but never used because
"#define USE_FAST" was removed 2 hours before: r46366.
==> I changed this to activate optimization on "S.split" too.

I propose to commit these changes before looking for further improvements.
(I plan to refactor some functions and macro to Objects/stringlib)

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15644/fastsearch_rfind_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:33:49 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 11:33:49 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261395229.83.0.191485122892.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Actually, the USE_FLAG macro was removed in r46367 (not 46366).

? needforspeed: remove remaining USE_FAST macros; if fastsearch was
broken, someone would have noticed by now ;-) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:49:50 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 11:49:50 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261396190.98.0.243362552256.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15507/fastsearch_rfind.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:50:22 2009
From: report at bugs.python.org (lekma)
Date: Mon, 21 Dec 2009 11:50:22 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261396222.96.0.349140873143.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

patch against trunk:
- fix tabs issue (I hope)
- add test

----------
Added file: http://bugs.python.org/file15645/issue7033_trunk_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:52:12 2009
From: report at bugs.python.org (lekma)
Date: Mon, 21 Dec 2009 11:52:12 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261396332.23.0.505379656202.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

The same with a simpler test.
I leave it up to you guys to choose which one is the best.

----------
Added file: http://bugs.python.org/file15646/issue7033_trunk_3_alt_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:54:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 11:54:51 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1261337398.52.0.792599789828.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261396534.3333.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I created a comprehensive set of tests to check all the possibilities
> that I listed in msg96319 and updated the patch for Object/exceptions.c.

Great!
Small thing: in tests, you should use setUp() to initialize test data
rather than __init__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:35:54 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 12:35:54 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261398954.3.0.901342132167.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15644/fastsearch_rfind_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:36:35 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 12:36:35 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261398995.92.0.353832766187.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I reupload the patch fixed (sorry).

----------
Added file: http://bugs.python.org/file15647/issue7462_fastsearch_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:37:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Dec 2009 12:37:16 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261399036.71.0.787632239583.issue7555@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just to be clear, this isn't a case of circular imports, but of the
class being defined twice (as two different objects, as Mark said), once
when the module is created as main when ss.py is run, and the other when
ss is imported for the first time (by tt).  You have two different
classes: __main__.ss and ss.ss.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:39:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 12:39:34 +0000
Subject: [issue7555] Wrong return value of isinstance() function
In-Reply-To: <1261391158.3.0.901615130384.issue7555@psf.upfronthosting.co.za>
Message-ID: <1261399174.83.0.560253905051.issue7555@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Much better explanation!  Thanks, David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7555>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:42:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 12:42:44 +0000
Subject: [issue7528] Provide PyLong_AsLongAndOverflow compatibility to Python
	2.x
In-Reply-To: <1261038937.25.0.365277054713.issue7528@psf.upfronthosting.co.za>
Message-ID: <1261399364.29.0.084474826524.issue7528@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I fixed up py3k to be in sync with trunk, and added your tests (slightly 
expanded) to py3k in r76971.  Thanks!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7528>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:51:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 12:51:46 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261399906.42.0.919294669388.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some things:
- is STRINGLIB_CMP still used? if not, it should be removed (use grep :-))
- please don't use "#if 1"
- if USE_FAST isn't used anymore, it should be remove as well
- did you check that rpartition, split and friends were sped up by the
patch?

Thanks for working on this!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 14:01:47 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 13:01:47 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261400507.15.0.376089102862.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Actually I see different macros which do the same thing: I will consider
reusing STRINGLIB_CMP to re-define PyUNICODE_MATCH and PySTRING_MATCH
(or create aliases if they have the same signature).

I can prepare a "all-in-one" patch which fixes all these things.
But don't you think we should do this incrementally, i.e. commit the
current patch before refactoring more code?

I will remove the "#if 1  /* USE_FAST */".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 14:06:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 13:06:23 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1261400507.15.0.376089102862.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261400826.3333.17.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually I see different macros which do the same thing: I will consider
> reusing STRINGLIB_CMP to re-define PyUNICODE_MATCH and PySTRING_MATCH
> (or create aliases if they have the same signature).

STRINGLIB_CMP, as the name implies, should only be used by stringlib.
(anything which doesn't start with Py* shouldn't be exported in the
official include files)

> But don't you think we should do this incrementally, i.e. commit the
> current patch before refactoring more code?

Well, if STRINGLIB_CMP isn't used anymore, removing it should be part of
the current issue. There's no reason to leave dead code in the source
tree. I agree that further cleanups can be part of another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 14:30:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 13:30:59 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261402259.67.0.848046617292.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removing "slow" parts and unnused macros STRINGLIB_CMP and USE_FAST.

----------
Added file: http://bugs.python.org/file15648/issue7462_fastsearch_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 14:31:06 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 13:31:06 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261402266.38.0.980927710539.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15647/issue7462_fastsearch_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 14:53:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 13:53:57 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1261403637.98.0.579047663401.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that makes the DeprecationWarning a TypeError, and adds a 
new DeprecationWarning for the 'L' format.

----------
keywords: +patch
Added file: http://bugs.python.org/file15649/issue5080.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5080>
_______________________________________

From report at bugs.python.org  Mon Dec 21 15:43:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 14:43:31 +0000
Subject: [issue7497] configure test for posix_semaphore capability leaves
	semaphore behind, causing test to fail for other users
In-Reply-To: <1260737595.26.0.117181393119.issue7497@psf.upfronthosting.co.za>
Message-ID: <1261406611.1.0.419135265167.issue7497@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems to be fixed;  I think I must have had a stale semaphore lying 
around, from while I was experimenting with the original problem.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7497>
_______________________________________

From report at bugs.python.org  Mon Dec 21 15:45:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 14:45:19 +0000
Subject: [issue7550] PyLong_As* methods should not call nb_int.
In-Reply-To: <1261305073.97.0.212369475826.issue7550@psf.upfronthosting.co.za>
Message-ID: <1261406719.26.0.940951201182.issue7550@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It turns out this is intimately bound up with the behaviour of 
PyArg_ParseTuple* for integer format codes.  Since this behaviour can't 
change until Python 3.3 (because of the moratorium), I'm closing this for 
now.

----------
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7550>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:28:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 15:28:12 +0000
Subject: [issue7518] Some functions in pymath.c should be moved elsewhere.
In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za>
Message-ID: <1261409292.2.0.649510871998.issue7518@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Moved atanh, asinh, acosh, log1p from pymath.c to Modules/_math.c in 
r76978 (trunk), r76980 (py3k).

----------
assignee:  -> mark.dickinson
priority:  -> normal
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7518>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:00:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Dec 2009 16:00:31 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261411231.43.0.95843522478.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I updated the patch and moved the helper class outside the __init__.

----------
Added file: http://bugs.python.org/file15650/issue6108-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:05:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 16:05:59 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261411559.59.0.214740210737.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks fine, module the slight style issue mentioned on IRC. Please
commit after you fix it.
(this is assuming all tests pass, of course!)

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:12:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 16:12:48 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261411968.9.0.764535671389.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't reviewed the algorithm (I don't know if I will, honestly), but
at least on the principle this looks good.
Fredrik, do you want to take a look?

----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:26:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 16:26:56 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261412816.01.0.312082981652.issue6058@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I tried running your script under IronPython 2.6 with Mono but I got a
bunch of errors; since I don't know IronPython at all I can't really
investigate)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:31:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 16:31:22 +0000
Subject: [issue7553] test_long_future is faulty
In-Reply-To: <1261333620.36.0.215143298483.issue7553@psf.upfronthosting.co.za>
Message-ID: <1261413082.37.0.506074308032.issue7553@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r76984.  Thanks!

----------
nosy: +mark.dickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7553>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:46:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 16:46:08 +0000
Subject: [issue7544] multiprocessing.Pool(): Fatal Python error:
	PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1261413968.1.0.333728925857.issue7544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We just had this error on one of the buildbots:

[...]
test_threadsignals
sem_wait: Unknown error 512
test_docxmlrpc
Fatal Python error: Invalid thread state for this thread
Fatal Python error: PyEval_AcquireThread: non-NULL old thread state
make: *** [buildbottest] Aborted


(see
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20trunk/builds/161/steps/test/logs/stdio
)

I don't know it's related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Mon Dec 21 17:47:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Dec 2009 16:47:52 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1261414072.4.0.0418005697011.issue7534@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:40:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Dec 2009 17:40:37 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261417237.79.0.580933614663.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This should be the final patch (issue6108-6.patch). I update the
comments, checked that (some of) the tests fail without the patch, that
they (all) pass with it and that there are no leaks.
I plan to backport this on 2.6 and possibly port the tests to py3k and 3.1.

----------
resolution: accepted -> 
stage: commit review -> patch review
Added file: http://bugs.python.org/file15651/issue6108-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:34:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 18:34:07 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261420447.13.0.243829685754.issue6108@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's ok for me.

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:37:52 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 18:37:52 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261420672.0.0.303274786301.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15637/stringbench_rfind_rindex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:38:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 18:38:18 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261420698.55.0.708932893412.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15652/stringbench_fixes_and_additions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:53:15 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 18:53:15 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261421595.92.0.951798843632.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15652/stringbench_fixes_and_additions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:59:18 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Dec 2009 18:59:18 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

While building pywin32 with Py3k trunk (not release version), I get this 
traceback:

   Creating library build\temp.win32-
3.1\Release\win32\src\pywintypes31.lib and object buil
d\temp.win32-3.1\Release\win32\src\pywintypes31.exp
Traceback (most recent call last):
  File "setup3.py", line 16, in <module>
    exec(str(got))
...skipping...
  File "<string>", line 2194, in <module>
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\core.py", line 149, in setup
    dist.run_commands()
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 919, in run_commands
    self.run_command(cmd)
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 938, in run_command
    cmd_obj.run()
  File "<string>", line 619, in run
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\command\build.py", line 128, in run
    self.run_command(cmd_name)
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\dist.py", line 938, in run_command
    cmd_obj.run()
  File 
"C:\HOME\as\apy\branches\nightly\build\pyhg_branches_release3_1_maint-
win32-x86-hgti
\command\build_ext.py", line 347, in run
p31-rrun\python\lib\distutils\ccompiler.py", line 791, in 
link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "<string>", line 1384, in link
p31-rrun\python\lib\distutils\msvc9compiler.py", line 663, in link
    manifest_buf = re.sub(pattern, "", manifest_buf)
p31-rrun\python\lib\re.py", line 166, in sub
    return _compile(pattern, flags).sub(repl, string, count)
TypeError: can't use a string pattern on a bytes-like object

----------
assignee: tarek
components: Distutils
messages: 96763
nosy: srid, tarek
severity: normal
status: open
title: msvc9compiler.py: TypeError: can't use a string pattern on a bytes-like object
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 20:01:36 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Dec 2009 19:01:36 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261422096.17.0.796263994037.issue7556@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Uh, cmd.exe seemed to have stripped some chars. Here's the full traceback: 
http://gist.github.com/261153

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 20:47:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Dec 2009 19:47:04 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261424824.2.0.792582951158.issue7556@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Correction: I found this in branches/release3.1-maint (not trunk - which I 
never tried)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:04:45 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 21 Dec 2009 20:04:45 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261425885.18.0.677421628244.issue7556@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I also raised this issue at the end of issue 4120 (which is closed).
I'll post the diff here, too.

----------
keywords: +patch
nosy: +skrah
versions: +Python 3.1
Added file: http://bugs.python.org/file15653/3.1-byte-string.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:11:43 2009
From: report at bugs.python.org (Jacques Lemire)
Date: Mon, 21 Dec 2009 20:11:43 +0000
Subject: [issue7557] Imprecise description for the fire.read() method
In-Reply-To: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
Message-ID: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>


New submission from Jacques Lemire <jaclemire at gmail.com>:

see this web page:
http://docs.python.org/3.1/library/stdtypes.html?
highlight=read#file.read

The description should say:
for Python 3.1 the method reads characters, for instance utf-8 
characters.

if the mode is 'rb', then it reads bytes (i.e. byte == 8 bits).

Context: Linux Ubuntu 9.10, 64 bit, compiled locally.

----------
assignee: georg.brandl
components: Documentation
messages: 96767
nosy: georg.brandl, jlp
severity: normal
status: open
title: Imprecise description for the fire.read() method
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:15:27 2009
From: report at bugs.python.org (John Nagle)
Date: Mon, 21 Dec 2009 20:15:27 +0000
Subject: [issue7558] Python 3.1.1 installer botches upgrade when installation
	is not on C drive.
In-Reply-To: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
Message-ID: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>


New submission from John Nagle <nagle at users.sourceforge.net>:

I just installed "python3.1.1.msi" on a system that had "python3.1.msi"
installed in "D:/python31".  In this situation, the installer does not
ask the user for a destination directory.  The installer found the old
installation in "D:/python31", removed most but not all of the files
there, and then installed the new version in "C:/python31". 

I uninstalled the failed install, and reinstalled.

On a new install, the installer prompts for the destination dir, and
that works. Upgrade installs, though, are botched.

                    John Nagle

----------
components: Installation
messages: 96768
nosy: nagle
severity: normal
status: open
title: Python 3.1.1 installer botches upgrade when installation is not on C drive.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7558>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:52:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Dec 2009 20:52:56 +0000
Subject: [issue4120] Do not embed manifest files in *.pyd when compiling
	with	MSVC
In-Reply-To: <1223971312.31.0.131537865896.issue4120@psf.upfronthosting.co.za>
Message-ID: <1261428776.09.0.304310269323.issue4120@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

See issue 7556 for the "can't use a string pattern on a bytes-like object" 
error.

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4120>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:55:08 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 20:55:08 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261428908.67.0.439277446109.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15654/stringbench_fixes_and_additions_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:07:17 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 21 Dec 2009 21:07:17 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

Say I have a test module test_foo, which fails to import with
ImportError. A reason for this might be a misspelt import in that module.

TestLoader().loadTestsFromName swallows the import error and instead
crashes with:
  File "/usr/lib/python2.6/unittest.py", line 584, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_foo'

A better thing to do would be to keep the import error and if the next
probe is an Attribute error, reraise the import error.
An alternative would be to return a test which would then reraise the
import error permitting the test suite to be constructed and execute but
still reporting the error.

----------
components: Library (Lib)
messages: 96770
nosy: rbcollins
severity: normal
status: open
title: TestLoader.loadTestsFromName swallows import errors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:16:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 21:16:59 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261430219.3.0.450026315497.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15654/stringbench_fixes_and_additions_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:17:17 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 21:17:17 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261430237.78.0.0505067071573.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15655/stringbench_fixes_and_additions_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:29:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 21:29:18 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261430958.38.0.624226246862.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

New benchmarks (and patch for the benchmark tool).

Best improvement is reached with such expression:
s="ABC"*33; (s+"E"+("D"+s)*500).rfind(s+"E") (*100)

String (classic):  93.14 ms
String (fast):      8.78 ms

Unicode (classic): 78.62 ms
Unicode (fast):     9.42 ms

----------
Added file: http://bugs.python.org/file15656/bench_rfind_algorithms_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:29:27 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 21:29:27 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1261430967.48.0.225762703996.issue7462@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15638/bench_rfind_algorithms_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:55:35 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 21:55:35 +0000
Subject: [issue7557] Imprecise description for the file.read() method
In-Reply-To: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
Message-ID: <1261432535.25.0.244692524083.issue7557@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

This section is obsolete and is removed from the documentation in r76893
an r76894. See issue #7508.

----------
nosy: +flox
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update 'file object' doc
title: Imprecise description for the fire.read() method -> Imprecise description for the file.read() method

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:06:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 21 Dec 2009 22:06:27 +0000
Subject: [issue7558] Python 3.1.1 installer botches upgrade when installation
	is not on C drive.
In-Reply-To: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
Message-ID: <1261433187.81.0.601773665468.issue7558@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't reproduce this; the 3.1.1 installer will most certainly ask for
a target directory even if there is a 3.1 installation already; see the
attached screenshot. I'm slightly puzzled by the file names you report,
as the files on python.org have dashes in their names. Where did you get
the files from?

Can you kindly run the 3.1.1 installation with

msiexec /i python-3.1.1.msi /l*v py.log

and attach (a compressed version of) the resulting log file?

----------
nosy: +loewis
Added file: http://bugs.python.org/file15657/inst311.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7558>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:13:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Dec 2009 22:13:05 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261433585.63.0.638796961361.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could you provide a more complete recipe for reproducing the problem,
please?  I created a test_foo.py containing 'import blert', and running
python -m unittest test_foo does not mask the import error for blert in
loadTestsFromName:

...
  File "/usr/lib/python2.6/unittest.py", line 576, in loadTestsFromName
    module = __import__('.'.join(parts_copy))
  File "test_foo.py", line 1, in <module>
    import blert
ImportError: No module named blert

----------
nosy: +michael.foord, r.david.murray
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:15:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 22:15:18 +0000
Subject: [issue7514] doc: documentation for "sys.flags" is obsolete.
In-Reply-To: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
Message-ID: <1261433718.91.0.614873464744.issue7514@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority:  -> low
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7514>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:15:45 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Dec 2009 22:15:45 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261433745.35.0.0991958492771.issue7556@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Stefan's patch will do the trick. I am adding a test to make sure this
part is covered before I apply the patch

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:20:10 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 22:20:10 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1261434010.9.0.309742909552.issue7537@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:24:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 21 Dec 2009 22:24:03 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261434243.71.0.161872439554.issue7556@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd rather prefer if the manifest was opened in text mode. It should be
UTF-8 encoded (although ASCII would work as well).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:24:24 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 21 Dec 2009 22:24:24 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1261434264.42.0.0818616772191.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority:  -> normal
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7455>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:28:44 2009
From: report at bugs.python.org (Robert Collins)
Date: Mon, 21 Dec 2009 22:28:44 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261434524.35.0.736042497057.issue7559@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

mkdir thing
touch thing/__init__.py
echo "import blert" > thing/test_foo.py
python -m unittest thing.test_fooTraceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.6/unittest.py", line 875, in <module>
    main(module=None)
  File "/usr/lib/python2.6/unittest.py", line 816, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.6/unittest.py", line 843, in parseArgs
    self.createTests()
  File "/usr/lib/python2.6/unittest.py", line 849, in createTests
    self.module)
  File "/usr/lib/python2.6/unittest.py", line 613, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.6/unittest.py", line 584, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_foo'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:37:17 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Dec 2009 22:37:17 +0000
Subject: [issue7544] multiprocessing.Pool(): Fatal Python error:
	PyEval_AcquireThread: NULL new thread state
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1261435037.76.0.316402611101.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

No, I don't think that this issue is related, because it starts with
another message: "Invalid thread state for this thread".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:02:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Dec 2009 23:02:03 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261436523.15.0.642297804939.issue7556@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

sure, that's even simpler. I am adding a test and this simple fix.

Notice that this code could be replaced with some code that uses an xml
parser. I find the regexp patterns a bit inappropriate here because it
removes "<dependentAssembly></dependentAssembly>" in a second call, but
may leave an empty "<dependency></dependency>" as far as I understand

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:05:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 21 Dec 2009 23:05:36 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261436736.44.0.797983775735.issue7556@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for using proper XML processing: that would be fine as well.

As for leaving an empty dependency element: in the original report, MAL
says that this is conforming. I found a schema file (from MS) which
agrees, and a textual documentation page that disagrees. The actual
implementation (atleast in Win7) also seems to agree: the loader would
(apparently) recognize the entire manifest even though it had this empty
dependency in it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:10:03 2009
From: report at bugs.python.org (Jacques Lemire)
Date: Mon, 21 Dec 2009 23:10:03 +0000
Subject: [issue7557] Imprecise description for the file.read() method
In-Reply-To: <1261432535.25.0.244692524083.issue7557@psf.upfronthosting.co.za>
Message-ID: <5657e3c50912211509l219da309n6472e594826cd2fc@mail.gmail.com>


Jacques Lemire <jaclemire at gmail.com> added the comment:

Merci Florent
Mais alors o?? se cache la documentation 3.1 "officiel" sur la classe file.

Jacques

2009/12/21 Florent Xicluna <report at bugs.python.org>

>
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
>
> This section is obsolete and is removed from the documentation in r76893
> an r76894. See issue #7508.
>
> ----------
> nosy: +flox
> resolution:  -> duplicate
> stage:  -> committed/rejected
> status: open -> closed
> superseder:  -> Update 'file object' doc
> title: Imprecise description for the fire.read() method -> Imprecise
> description for the file.read() method
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7557>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15658/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________
-------------- next part --------------
Merci Florent<br>Mais alors o?? se cache la documentation 3.1 &quot;officiel&quot; sur la classe file.<br><br>Jacques<br><br><div class="gmail_quote">2009/12/21 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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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>
This section is obsolete and is removed from the documentation in r76893<br>
an r76894. See issue #7508.<br>
<br>
----------<br>
nosy: +flox<br>
resolution: ??-&gt; duplicate<br>
stage: ??-&gt; committed/rejected<br>
status: open -&gt; closed<br>
superseder: ??-&gt; Update &#39;file object&#39; doc<br>
title: Imprecise description for the fire.read() method -&gt; Imprecise description for the file.read() method<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/issue7557" target="_blank">http://bugs.python.org/issue7557</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br><br clear="all"><br>-- <br>Jacques Lemire<br>

From report at bugs.python.org  Tue Dec 22 00:13:17 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Dec 2009 23:13:17 +0000
Subject: [issue7557] Imprecise description for the file.read() method
In-Reply-To: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
Message-ID: <1261437197.4.0.862764446119.issue7557@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's in the "io" module:
http://docs.python.org/dev/py3k/library/io.html

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:16:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Dec 2009 23:16:47 +0000
Subject: [issue7557] Imprecise description for the file.read() method
In-Reply-To: <1261426303.17.0.403576961756.issue7557@psf.upfronthosting.co.za>
Message-ID: <1261437407.87.0.0427517286134.issue7557@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Merci Florent
> Mais alors o? se cache la documentation 3.1 "officiel" sur la classe file.

Even though we seem to have a disturbing accumulation of French
developers here, please keep to English on the tracker :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7557>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:45:27 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Dec 2009 23:45:27 +0000
Subject: [issue7556] msvc9compiler.py: TypeError: can't use a string pattern
	on a bytes-like object
In-Reply-To: <1261421958.47.0.722908019254.issue7556@psf.upfronthosting.co.za>
Message-ID: <1261439127.69.0.695812272556.issue7556@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok thanks for the detailed info, Martin

I guess we could refactor it to an xml reader/writer if we need to do
more things in the future with these files.

I'll close this issue, as the mentioned problem is now fixed by using a
text mode. The test in test_msvc9compiler will make sure the XML file 
gets cleaned up by the regexp.

- done in r76993, r76995
- backported in r76996 and r76998 so the trunk behaves the same way.
- 2.6 stays unchanged, and keep using a binary mode.

Thanks all !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7556>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:16:36 2009
From: report at bugs.python.org (Adal Chiriliuc)
Date: Tue, 22 Dec 2009 00:16:36 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1261440996.08.0.984093434355.issue6900@psf.upfronthosting.co.za>


Adal Chiriliuc <adal.chiriliuc at gmail.com> added the comment:

This seem to have been broken when the help file style was changed (from
2.5 to 2.6).

I'm also bothered by this issue, since you cannot locate easily now
related modules.

For example, in the old help version I would go in the index to urllib,
display the module, then click Locate and I would then see all the
Internet related modules.

Now I have to search them through the Contents page.

----------
nosy: +adalx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:22:45 2009
From: report at bugs.python.org (John Nagle)
Date: Tue, 22 Dec 2009 00:22:45 +0000
Subject: [issue7558] Python 3.1.1 installer botches upgrade when installation
	is not on C drive.
In-Reply-To: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
Message-ID: <1261441365.09.0.402397035721.issue7558@psf.upfronthosting.co.za>


John Nagle <nagle at users.sourceforge.net> added the comment:

Cancel bug report.

It was my error. The installer says it is replacing the existing
installation, but by default installs it in C:.  But that can be
overridden in the directory entry field below the big empty white entry box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7558>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:24:18 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Dec 2009 00:24:18 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261441458.75.0.131572062883.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thank you.  I can reproduce this on trunk as well.  I'm leaving stage
set to test needed because we need to turn this into a unit test.

----------
keywords: +easy
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:27:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Dec 2009 00:27:57 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261441677.18.0.739583425818.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note: this problem is similar in some ways to issue 5230, and a similar
solution might be appropriate (or might not :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:33:44 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 22 Dec 2009 00:33:44 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261442024.49.0.6957516181.issue7559@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'll try and look at both these issues in the next few days unless one
of you beats me to it. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:53:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 00:53:34 +0000
Subject: [issue7558] Python 3.1.1 installer botches upgrade when installation
	is not on C drive.
In-Reply-To: <1261426527.41.0.844327197724.issue7558@psf.upfronthosting.co.za>
Message-ID: <1261443214.73.0.788808829882.issue7558@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7558>
_______________________________________

From report at bugs.python.org  Tue Dec 22 02:53:56 2009
From: report at bugs.python.org (Robert Collins)
Date: Tue, 22 Dec 2009 01:53:56 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261446836.99.0.0211251936239.issue7559@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

I'm scratching an itch at the moment, I just noted this in passing ;)

I'm partial to the 'turn it into a fake test case' approach, its what I
would do if I get to it first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:09:40 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Dec 2009 02:09:40 +0000
Subject: [issue1673007] urllib2 requests history + HEAD support
Message-ID: <1261447780.9.0.139792607912.issue1673007@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is a discussion and explanation from the submitter on what is meant
by history of requests.
http://mail.python.org/pipermail/python-dev/2007-March/072069.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673007>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:07:42 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:07:42 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>


New submission from Sebastian Hagen <sh_pybugs at memespace.net>:

Most of the functions in Python's stdlib that take filename parameters
allow for those parameters to be buffer (such as bytes, bytearray,
memoryview) objects. This is useful for various reasons, among them that
on Posix-likes, file- and pathnames ultimately *are* sequences of bytes.
A number of functions in the posix (and thus, os) module break this
convention:
mkfifo()
mknod()
statvfs()
pathconf()

E.g.:
>>> os.statvfs(b'/')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: statvfs() argument 1 must be string, not bytes

I'm attaching a patch that modifies the abovementioned functions to make
them accept buffer-like objects in addition to string objects; I've
never contributed code to the stdlib, so any general problems with that
patch can be ascribed to my ignorance about established practice (or
inability to program, in the case of downright bugs).

I'm a bit off a loss as what to do about posix.system(). IMO, that one
should also take bytes - at least on posix-like OSes - since it
specifies a commandline, and both the name and the arguments in such
lines are, on posix-likes, sequences of bytes.
I'm not sure how to best reconcile that with the MS Windows version of
that function, however; advice would be welcome.

----------
components: Library (Lib)
files: posix_fn_bytes_01.patch
keywords: patch
messages: 96792
nosy: sh
severity: normal
status: open
title: Various filename-taking posix methods don't like bytes / buffer objects.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:08:13 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:08:13 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261458493.24.0.659389087386.issue7560@psf.upfronthosting.co.za>


Changes by Sebastian Hagen <sh_pybugs at memespace.net>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:09:44 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:09:44 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261458584.15.0.107081759256.issue7560@psf.upfronthosting.co.za>


Changes by Sebastian Hagen <sh_pybugs at memespace.net>:


Removed file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:10:20 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:10:20 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261458620.92.0.877488620151.issue7560@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

I'm taking that patch back. More testing would have been in order before
posting; sorry for that, will repost once I've got the obvious problems
worked out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:42:10 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:42:10 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261460530.85.0.320079404238.issue7560@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

And further testing reveals that all of this has in fact already been
fixed in trunk. I assumed it hadn't been, because the code for at least
some of the relevant functions in Modules/_posixmodule.c is the same as
in 3.1.1; I didn't know that the samentics for the "s" format parameter
to PyArg_ParseTuple() had been modified. Apologies for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:42:40 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 05:42:40 +0000
Subject: [issue7560] Various filename-taking posix methods don't like bytes /
	buffer objects.
In-Reply-To: <1261458462.16.0.0100952896884.issue7560@psf.upfronthosting.co.za>
Message-ID: <1261460560.74.0.582970442246.issue7560@psf.upfronthosting.co.za>


Changes by Sebastian Hagen <sh_pybugs at memespace.net>:


----------
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7560>
_______________________________________

From report at bugs.python.org  Tue Dec 22 08:31:45 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 07:31:45 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>


New submission from Sebastian Hagen <sh_pybugs at memespace.net>:

Various functions in the 'posix' module that take filename arguments
accept bytearray values for those arguments, and mishandle those objects
in a way that leads to segfaults.

Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir(bytearray(b'/'))
Segmentation fault

There's at least two seperate problems with the way posixmodule handles
these objects. The first is that the code isn't set up to handle NULL
retvals from PyByteArray_AS_STRING(), which occur for zero-byte
bytearray objects. This causes a NULL-pointer dereference in
PyUnicode_FSConverter() if you pass a zero-length bytearray.

The second issue is that release_bytes() calls bytearray_releasebuffer()
with NULL for the first argument, which directly leads to a NULL-pointer
dereference.

I'm attaching a patch against SVN 77001 which should fix both of these
issues.

----------
components: Library (Lib)
files: posixmodule_fn_bytearray_fix_01.patch
keywords: patch
messages: 96795
nosy: sh
severity: normal
status: open
title: Filename-taking functions in posix segfault when called with a bytearray arg.
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15660/posixmodule_fn_bytearray_fix_01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:06:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Dec 2009 13:06:04 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261487164.7.0.570276798154.issue7561@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> high
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:24:20 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Dec 2009 13:24:20 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261488260.05.0.429657991654.issue6058@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I wrote a small C application that converts all possible
wchar_t to multibyte strings, using code page 65001.

Usage:

cl.exe gen65001.c
python check65001.py

Except for the newline character and a sequence from
55296-57343, this code page matches UFT-8.


Note, however, that cp65001 is a pseudo code page:

http://www.postgresql.org/docs/faqs.FAQ_windows.html#2.6


For instance, setlocale will not work:

http://blogs.msdn.com/michkap/archive/2006/03/13/550191.aspx

----------
nosy: +skrah
Added file: http://bugs.python.org/file15661/gen65001.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:24:58 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Dec 2009 13:24:58 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261488298.05.0.788244072396.issue6058@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file15662/check65001.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:57:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 22 Dec 2009 13:57:23 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261490243.97.0.754127443749.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

With patch 17 all tests pass on XP. I'm (still) working on getting a
Windows 7 environment to test there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:35:13 2009
From: report at bugs.python.org (Jari Pennanen)
Date: Tue, 22 Dec 2009 14:35:13 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>


New submission from Jari Pennanen <jari.pennanen at gmail.com>:

Long story short: Sometimes build_ext should be run before build_py, or 
something similar.

As an example when using SWIG and setup.py the build order is incorrect: 
During build_ext the SWIG generates .py files that should be used during 
build_py, but since build_py was already ran this doesn't work.

It would be useful if one could for example define custom order for 
subcommands in setup, in this case like: 

    setup(..., build_order=['build_ext', 'build_py'])

If adding a new keyword argument to setup is not an option, some other 
way to specify custom build order should be considered.

This is common problem especially using SWIG. Discussion about this 
issue was in here http://mail.python.org/pipermail/distutils-sig/2009-
December/015010.html the workaround for SWIG case is to use following 
setup.py:

   #!/usr/bin/env python
   from distutils.core import setup, Extension
   from distutils.command.build_py import build_py

   dist = setup(...)

   # Rerun the build_py
   build_py = build_py(dist)
   build_py.ensure_finalized()
   build_py.run()

----------
assignee: tarek
components: Distutils
messages: 96798
nosy: ciantic, tarek
severity: normal
status: open
title: Custom order for the subcommands of build
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:54:10 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 22 Dec 2009 14:54:10 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1261493650.11.0.171648053499.issue7562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:48:09 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Dec 2009 16:48:09 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261500489.31.0.359766257268.issue7561@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Crash confirmed. I don't see any issue with bytes2str(), the second part
of your patch is what fixes the problem. I attach the reduced patch so
it's clear what I mean.

----------
nosy: +skrah
Added file: http://bugs.python.org/file15663/release_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:19:17 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 17:19:17 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261502357.72.0.975314946637.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

Not exactly. The last part fixes the second problem, which you get for
non-zero-length bytearrays. But without the first fix, zero-length
bytearrays still lead to a crash:

Python 3.2a0 (py3k:77001M, Dec 22 2009, 18:17:08)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.mkdir(bytearray(0))
Segmentation fault

That's what the rest of the patch fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:29:11 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Dec 2009 17:29:11 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261502951.62.0.456659832756.issue7561@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Correction: You are of course right about PyByteArray_AS_STRING(), but
with

os.mkdir(bytearray(b''))

I get the segfault in PyUnicodeUCS2_FSConverter():


(gdb) n
1638             size = PyByteArray_GET_SIZE(output);
(gdb) n
1639             data = PyByteArray_AS_STRING(output);
(gdb) p size
$2 = 0
(gdb) n
1641        if (size != strlen(data)) {
(gdb) p data
$3 = (void *) 0x0


Should perhaps PyByteArray_AS_STRING() be fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:33:36 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 17:33:36 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261503216.62.0.587696279501.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

You're correct about PyUnicode_FSConverter(), which is why the very
first part of my patch fixes that function. Only fixing that one will
get rid of the segfaults, but also lead to incorrect error reporting for
the zero-length bytearray case; the bytes2str() modification is to get
the right exceptions.

I don't know which precise semantics PyByteArray_AS_STRING() is
*supposed* to have. I assumed it returning NULL was normal for
0-byte-length arrays, and based my patch off of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:49:24 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 17:49:24 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261504164.1.0.765216279573.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

Correction: "Only fixing that one will
get rid of the segfaults" ... well, for mkdir() on GNU/Linux, anyway.
POSIX.1-2008 doesn't specify what happens if you call mkdir() with a
NULL pointer, so I guess other conforming implementations might in fact
still segfault at that point - it just happens that the one I tested it
on is too nice to do that.

Either way, passing a NULL pointer to those functions is almost
certainly not a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:54:25 2009
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Dec 2009 17:54:25 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261504465.03.0.713211707196.issue7561@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Sorry that I missed the first part of your patch. I don't know exactly
what PyByteArray_AS_STRING() is meant to do either, but I think it would
make sense to return an empty string. This here works:

>>> bytes(bytearray(b''))
b''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 19:20:41 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 18:20:41 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261506041.7.0.361907756151.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

I've glanced at some of the other PyByteArray_AS_STRING() (and
PyByteArray_AsStr(), which inherits this behaviour) uses in the stdlib.
By far the heaviest user is bytearrayobject.c; aside from that, there's
by my count only 24 uses in current trunk. I haven't looked at all of
them in detail, but the ones I have looked at all seem to ensure that
the possible NULL retvals don't cause them problems.

Given that, and considering that bytearray itself uses it for all kinds
of operations, I'd be rather reluctant to add any additional overhead to
this macro absent some authoritative statement that the current
behaviour is bad. We'd definitely get better performance by just having
posixmodule.c pay attention to the retval it gets. [Yes, this is
probably premature optimization; but it's not as if fixing posixmodule.c
takes any massive changes either, so I'm not too worried about
additional code complexity in this particular case.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 19:42:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 18:42:32 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261507352.21.0.916333583614.issue7561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Stepping back from the issue, I wonder whether posixmodule needs to
accept bytearray objects at all.

IIRC, the rationale was to allow access to file names that are
unencodable, an issue that was mitigated by PEP 383. But even if
byte-oriented file names stay supported, it is unclear why bytearray
needs to be supported (as opposed to just supporting bytes).

I suggest to bring up the issue on python-dev.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 19:59:24 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 18:59:24 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261508364.5.0.758492569034.issue6058@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This report is really about the issues reported in #1602 and #7441, i.e.
where console output fails if the terminal encoding is 65001. Rather
than adding the alias, I would prefer to find out why terminal output
fails in that code page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:23:27 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 19:23:27 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261509807.18.0.00109848479573.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

Well, it doesn't *need* to accept them ... but it would certainly be
nice to have. If you've already got the filename in a bytearray object
for some reason, being able to pass it through directly saves you both a
copy and the explicit conversion code, which is a double-win.

>From an interface POV, it'd be even better if memoryview was allowed,
too ... is there a specific reason that it's not? If one kind of simple
readable buffers work, I don't see any good reason not to support all
such objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:23:44 2009
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Tue, 22 Dec 2009 19:23:44 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261509824.69.0.223011182118.issue6058@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

re Martin's question, I can offer the indirect wisdom of Michael Kaplan
in this blog post:

http://blogs.msdn.com/michkap/archive/2008/03/18/8306597.aspx

where he mentions that the easiest way to output unicode text in the
Windows console, is:

int main(void) {
    _setmode(_fileno(stdout), _O_U16TEXT);
    wprintf(L"\x043a\x043e\x0448\x043a\x0430 \x65e5\x672c\x56fd\n");
    return 0;
}

_setmode being the special call needed.

I haven't tested with any _O_U8TEXT (if such a thing exists), I don't do
Windows anymore, therefore I can't provide a patch.

It also seems that Python ?when stdin/stdout/stderr is under control of
a Windows console? doesn't use plain *printf functions. The example code
I offered in one of the other issues (dumb stdout doing plain .write as
UTF-8) runs and displays fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:27:25 2009
From: report at bugs.python.org (Sebastian Hagen)
Date: Tue, 22 Dec 2009 19:27:25 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261510045.08.0.952441360562.issue7561@psf.upfronthosting.co.za>


Sebastian Hagen <sh_pybugs at memespace.net> added the comment:

Oh, and *forcing* use of the PEP 383 hack for such interfaces would
really be the Wrong Thing. Byte sequences are the natural (and most
efficient, and least prone to misunderstandings) way to store filenames
on a posix-like. Storing them as unicode-except-not-really is an
acceptable hack for interfaces that need to standardize on strings for
some reasons, but that really doesn't apply to these functions, and I'd
always store such filenames as bytes if I know I'm running on a posix-like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:47:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 19:47:28 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261511248.89.0.786271784374.issue7561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I doubt that buffers (including bytearray) are as useful in Python for
storing file names as they are in C.

Typically, when creating a buffer, you allocate some maximum size (in C:
MAXPATH or some such), and then you fill the buffer, and null-terminate.
In Python, you can't null-terminate; instead, the buffer must have the
right size already. So I wonder: where would you get a bytearray from
that has exactly the right size for a file name that you want to access
(and where do you get the file name from)?

If it is IAGNI, then: practicality beats purity - just because we
*could* support arbitrary byte areas, it doesn't mean we should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:48:38 2009
From: report at bugs.python.org (Ronnie Maor)
Date: Tue, 22 Dec 2009 19:48:38 +0000
Subject: [issue7563] yield in except clause causes exception context to be lost
In-Reply-To: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za>
Message-ID: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za>


New submission from Ronnie Maor <ronnie.maor at gmail.com>:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def coroutine():
...     try:
...             raise Exception('bla')
...     except:
...             yield 'foo'
...             raise
...
>>> for _ in coroutine():
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in coroutine
TypeError: exceptions must be classes or instances, not NoneType

Seems that yielding in the except clause makes python forget the current 
exception, so a bar "raise" statement raises None, instead of the 
original exception.
changing except to except Exception,e: and raise to raise e throws the 
original exception, but then the original stack trace is lost.

----------
components: Interpreter Core
messages: 96812
nosy: ronniemaor
severity: normal
status: open
title: yield in except clause causes exception context to be lost
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7563>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:48:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 19:48:38 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261511318.68.0.668369882949.issue7561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

sh: I don't argue against supporting bytes (here), only against
supporting bytearray.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:48:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 19:48:41 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261511321.02.0.687769679873.issue7561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

sh: I don't argue against supporting bytes (here), only against
supporting bytearray.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:48:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 19:48:48 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261511328.67.0.110413157759.issue7561@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 22:16:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Dec 2009 21:16:34 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1261516594.46.0.35028662734.issue6058@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I also wonder whether stdin/stdout/stderr should be streams on Windows
that use WriteConsole instead of WriteFile. Then the entire issue of
console CP would go away for Unicode output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Tue Dec 22 22:18:37 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 22 Dec 2009 21:18:37 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1261516717.72.0.892643467245.issue7562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The distutils way of implementing a different fixed order would be to
create a build command sub-class, override the .sub_commands list and
then register this new subclass as 'build' command with distutils via
the cmdclass setup() keyword argument. (eGenix uses this approach in
mxSetup.py - see egenix-mx-base)

Note that I don't think that just providing an alternative order of
build_py and build_ext would solve the SWIG issue - e.g. build_py
wouldn't know about the new files SWIG generates unless the SWIG build
process explicitly tells the build_py command about these new files.

It would probably be better to add a completely new command just for
managing the SWIG build process to distutils. This could then add the
generated files, run build_ext with the required special arguments,
rerun build_py, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________

From report at bugs.python.org  Tue Dec 22 22:21:15 2009
From: report at bugs.python.org (Karl D'Adamo)
Date: Tue, 22 Dec 2009 21:21:15 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1261516875.7.0.482181077341.issue1675951@psf.upfronthosting.co.za>


Karl D'Adamo <karld-python at ofb.net> added the comment:

This patch is awesome.  It makes it possible to do this with http
response objects that return gzipped streams:

>>> conn = httplib.HTTPConnection('blah')
>>> req = conn.request('GET', 'a.gz')
>>> resp = conn.getresponse()
>>> unzipper = gzip.GzipFile(fileobj=resp)
# read just the first 100 lines
>>> for i in range(100):
    print unzipper.readline()

----------
nosy: +karld

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Wed Dec 23 00:07:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Dec 2009 23:07:10 +0000
Subject: [issue7563] yield in except clause causes exception context to be lost
In-Reply-To: <1261511318.07.0.56759832135.issue7563@psf.upfronthosting.co.za>
Message-ID: <1261523230.53.0.303745499454.issue7563@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is fixed in Python 3. I don't know if it's worth backporting the
changes because it may be hard to avoid also backporting the
incompatibilities in the exception model.

----------
nosy: +benjamin.peterson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7563>
_______________________________________

From report at bugs.python.org  Wed Dec 23 00:31:34 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 22 Dec 2009 23:31:34 +0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1261524694.68.0.876246607013.issue1729305@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It still occurs on trunk.

test test_doctest crashed -- <type 'exceptions.UnicodeEncodeError'>:
  'ascii' codec can't encode characters in position 343-344:
    ordinal not in range(128)

----------
components: +Tests -Library (Lib)
nosy: +flox
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_______________________________________

From report at bugs.python.org  Wed Dec 23 00:39:15 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 22 Dec 2009 23:39:15 +0000
Subject: [issue7564] test_ioctl fails sometimes
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

I got it to fail sometimes on trunk, when run with "-r -uall".

Debian 64bits, Python 2.7a r77004


test_ioctl
test_ioctl (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_signed_unsigned_code_param (test.test_ioctl.IoctlTests) ... ok

======================================================================
FAIL: test_ioctl (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_ioctl.py", line 27, in test_ioctl
    self.assertTrue(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
AssertionError: 9165 not in (2334, 15696)

======================================================================
FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_ioctl.py", line 37, in test_ioctl_mutate
    self.assertTrue(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
AssertionError: 9165 not in (2334, 15696)

----------------------------------------------------------------------
Ran 3 tests in 0.001s

FAILED (failures=2)
test test_ioctl failed -- multiple errors occurred

----------
components: Tests
messages: 96820
nosy: flox
severity: normal
status: open
title: test_ioctl fails sometimes
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:25:35 2009
From: report at bugs.python.org (George King)
Date: Wed, 23 Dec 2009 00:25:35 +0000
Subject: [issue7565] Increasing resource.RLIMIT_NOFILE has no effect
In-Reply-To: <1261527935.68.0.0855643074362.issue7565@psf.upfronthosting.co.za>
Message-ID: <1261527935.68.0.0855643074362.issue7565@psf.upfronthosting.co.za>


New submission from George King <gkbox at arboreality.net>:

My builds from trunk fail to open a number of files greater than the 
default 2660, even when I increase the limit using:

resource.setrlimit(resource.RLIMIT_NOFILE, (test_limit, -1))

Attached is a script that doubles the default limit, sets it, queries it 
to make sure that it is set, and then opens the expected number of 
files. The script succeeds when run on the python2.6 that apples ships 
with 10.6, and it succeeds when run on my build of python3.2 trunk 
(updated today). However, it fails on python2.7 trunk (also built 
today). 

here is sample output:

gk > python2.6 ./file_limits_bug.py 
default file limits: (2560, 9223372036854775807)
new file limits: (5120, 9223372036854775807)

gk > python2.7 ./file_limits_bug.py 
default file limits: (2560, 9223372036854775807)
new file limits: (5120, 9223372036854775807)
Traceback (most recent call last):
  File "./file_limits_bug.py", line 34, in <module>
IOError: [Errno 24] Too many open files: 'testfiles/testfile2557'

----------
components: Library (Lib)
files: file_limits_bug.py
messages: 96821
nosy: george.king
severity: normal
status: open
title: Increasing resource.RLIMIT_NOFILE has no effect
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15664/file_limits_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7565>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:28:52 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 00:28:52 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261528132.4.0.0380086966942.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15219/windows symlink draft 15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:29:00 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 00:29:00 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261528140.26.0.494080875575.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15403/windows symlink draft 16.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:56:48 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 00:56:48 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In issue1578269, asvetlov suggests adding an implementation of
os.sameopenfile to ntpath.py:

---
Jason, as I see you implemented os.samefile (actually ntpath.samefile) 
but  os.sameopenfile is still not implemented.

Looks like it's easy to do: while GetFinalPathNameByHandle already 
accept file handle you can use CRT function _get_osfhandle(fd) to 
convert file descriptors (arguments for sameopenfile) to file handles 
and pass it to GetFinalPathNameByHandle.

For me samefile and sameopenfile has very close semantic and I like to 
see both if it's possible.
---

This seems entirely reasonable, but I would like to track and tackle
this as a separate issue.

----------
components: Windows
messages: 96822
nosy: jaraco
severity: normal
status: open
title: Add ntpath.sameopenfile support for Windows
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:00:15 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 01:00:15 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261530015.42.0.425451127806.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Andrew, thanks for pointing out the apparent mismatch of having
ntpath.samefile but not ntpath.sameopenfile. Since this behavior doesn't
immediately affect the support of os.symlink, I've created a separate
issue, issue7566, to track that effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:02:08 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 01:02:08 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1261530128.62.0.523200005399.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Eric: That's great news. I was gearing up to test myself to see if I
could reproduce the issue, but I'm glad it works since you beat me to
it. Let me know if it would help to provide a Windows 7 VMWare Player
virtual machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:16:15 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 23 Dec 2009 01:16:15 +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: <1261530975.04.0.775509888041.issue2698@psf.upfronthosting.co.za>


Craig McQueen <ces-pub at mcqueen.id.au> added the comment:

This seems to be an bug in Python 3.1.1. Is it fixed in the Python 3
code? Is the issue being tracked in a separate issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:46:18 2009
From: report at bugs.python.org (Yury)
Date: Wed, 23 Dec 2009 01:46:18 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>


New submission from Yury <yury.sobolev at gmail.com>:

Calling curses.initscr after curses.endwin() results in a messed up
terminal the second time curses.endwind() is called. For example:

import curses
curses.initscr(); curses.endwin(); curses.initscr(); curses.endwin()

This behaves correctly in python 2.5. It does not work in python 2.6.

----------
components: Library (Lib)
messages: 96826
nosy: yury
severity: normal
status: open
title: Messed up terminal after calling curses.initscr() twice.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Wed Dec 23 03:02:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Dec 2009 02:02:32 +0000
Subject: [issue7565] Increasing resource.RLIMIT_NOFILE has no effect
In-Reply-To: <1261527935.68.0.0855643074362.issue7565@psf.upfronthosting.co.za>
Message-ID: <1261533752.83.0.0582871861537.issue7565@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What operating system are you using? Can you provide a relevant snipped
of strace output?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7565>
_______________________________________

From report at bugs.python.org  Wed Dec 23 03:07:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Dec 2009 02:07:06 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1261534026.34.0.441945918734.issue7566@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As NTFS supports hard links, I think GetFileInformationByHandle should
be used to compare handles (looking at dwVolumeSerialNumber,
nFileIndexHigh,nFileIndexLow)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________

From report at bugs.python.org  Wed Dec 23 03:21:01 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 23 Dec 2009 02:21:01 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1261534861.56.0.389934820696.issue4772@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think both AF_BLUETOOTH and AF_TIPC should raise ValueError since the
type of the argument is correct but it's not a good value. I piggybacked
on Amaury's patch and changed the exceptions with a patch against r77004.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15665/issue4772.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4772>
_______________________________________

From report at bugs.python.org  Wed Dec 23 03:27:16 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 23 Dec 2009 02:27:16 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1261535236.92.0.192783643961.issue5116@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Has there been any consensus about what to do with this? I know there
was some chatter on python-dev about assertions causing problems with
buildbots (6 months ago?) but I don't think anything came out of it.

The code change is small and looks good. Is it worth extending this to
expose CrtSetReportFile since a file is one of the options of
CrtSetReportMode?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5116>
_______________________________________

From report at bugs.python.org  Wed Dec 23 09:54:20 2009
From: report at bugs.python.org (Daniel)
Date: Wed, 23 Dec 2009 08:54:20 +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: <1261558460.11.0.9310666408.issue2698@psf.upfronthosting.co.za>


Daniel <daniel.mondon at free.fr> added the comment:

Hello,

I confirm : Python3.1.1 
.../...
running build
running build_py
running build_ext
building 'cx_Freeze.util' extension
error: Unable to find vcvarsall.bat

I've got the r73896 file correction.
:(
D.

----------
nosy: +Daniel26
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Wed Dec 23 10:47:08 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 23 Dec 2009 09:47:08 +0000
Subject: [issue1747858] chown broken on 64bit
Message-ID: <1261561628.86.0.987468500414.issue1747858@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

indeed, those were missed.  fixed in trunk r77007 and release26-maint 
r77008.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1747858>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:02:12 2009
From: report at bugs.python.org (Eric Devolder)
Date: Wed, 23 Dec 2009 10:02:12 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1261558460.11.0.9310666408.issue2698@psf.upfronthosting.co.za>
Message-ID: <f0531c170912230202o6789326cu66c4b11085d26663@mail.gmail.com>


Eric Devolder <eric.devolder at gmail.com> added the comment:

Will send you the trick (file) to make it work, but I can't do it from here
(at work - access restrictions) - please wait until Tonight :-)

Cheers

Eric

2009/12/23 Daniel <report at bugs.python.org>

>
> Daniel <daniel.mondon at free.fr> added the comment:
>
> Hello,
>
> I confirm : Python3.1.1
> .../...
> running build
> running build_py
> running build_ext
> building 'cx_Freeze.util' extension
> error: Unable to find vcvarsall.bat
>
> I've got the r73896 file correction.
> :(
> D.
>
> ----------
> nosy: +Daniel26
> versions:  -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2698>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15666/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________
-------------- next part --------------
<div>Will send you??the trick??(file) to make it work, but I can&#39;t do it from here (at work - access restrictions) - please wait until Tonight :-)</div>
<div>??</div>
<div>Cheers</div>
<div>??</div>
<div>Eric<br><br></div>
<div class="gmail_quote">2009/12/23 Daniel <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"><br>Daniel &lt;<a href="mailto:daniel.mondon at free.fr">daniel.mondon at free.fr</a>&gt; added the comment:<br>
<br>Hello,<br><br>I confirm : Python3.1.1<br>.../...<br>running build<br>running build_py<br>running build_ext<br>building &#39;cx_Freeze.util&#39; extension<br>
<div class="im">error: Unable to find vcvarsall.bat<br><br></div>I&#39;ve got the r73896 file correction.<br>:(<br>D.<br><br>----------<br>nosy: +Daniel26<br>versions: ??-Python 2.6<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/issue2698" target="_blank">http://bugs.python.org/issue2698</a>&gt;<br>
_______________________________________<br></div></div></blockquote></div><br>

From report at bugs.python.org  Wed Dec 23 11:08:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Dec 2009 10:08:24 +0000
Subject: [issue1811] True division of integers could be more accurate
In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
Message-ID: <1261562904.3.0.412385779924.issue1811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stealing this from Tim, with the intention of acting on it in the next 
couple of weeks.

----------
assignee: tim_one -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:31:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Dec 2009 10:31:12 +0000
Subject: [issue7417] open builtin has no signature in docstring
In-Reply-To: <1259674902.72.0.145233253757.issue7417@psf.upfronthosting.co.za>
Message-ID: <1261564272.97.0.302730189508.issue7417@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added signature from msg95885 in r77009.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7417>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:45:53 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 23 Dec 2009 10:45:53 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1261565153.33.0.289985309636.issue6873@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I applied the same fix that was applied to chown in trunk r77007 for 
lchown and fchown.  Could you test it on a platform where it previously 
failed?

The existing code might still have issues if there are platforms where 
uid_t and gid_t are unsigned but not the same size as a long as at the 
moment it merely casts and does not test to see that the values are the 
same as the patch you have supplied here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6873>
_______________________________________

From report at bugs.python.org  Wed Dec 23 12:09:58 2009
From: report at bugs.python.org (Jari Pennanen)
Date: Wed, 23 Dec 2009 11:09:58 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1261566598.5.0.597833273316.issue7562@psf.upfronthosting.co.za>


Jari Pennanen <jari.pennanen at gmail.com> added the comment:

> Note that I don't think that just providing an alternative order of 
build_py and build_ext would solve the SWIG issue - e.g. build_py 
wouldn't know about the new files SWIG generates unless the SWIG build 
process explicitly tells the build_py command about these new files.

I don't think this is the case, let me explain:

Usually to my naive understanding, (I've just developed first SWIG 
python extension) the generated .py filenames are *known by name* 
beforehand, thus I can do following:

    #!/usr/bin/env python

    from distutils.core import setup, Extension
    from distutils.command.build_py import build_py

    dist = setup(name='mypythonmodule',
        ext_modules=[
            Extension('swiggedmodule', ['swiggedinterface.i'], 
                ...
            )
        ],
        py_modules=['swiggedmodule'], # We *know* that the SWIG 
                                      # generation creates this module.
    )

    # Rerun the build_py to ensure that swig generated py is build
    build_py = build_py(dist)
    build_py.ensure_finalized()
    build_py.run()

The very first line of `swiggedinterface.i` is the key here, it is 
created by us, which explicitely says it will create swiggedmodule.py:

    %module "swiggedmodule"
    ...

This fact makes us sure that it creates only swiggedmodule.py and we can 
safely put it in setup py without any guessing work. This is why the 
simply re-running the built_py works, or running "setup.py build_ext 
build_py" but users of the module shouldn't need to use different way of 
building the swig modules than other modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________

From report at bugs.python.org  Wed Dec 23 12:57:24 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 23 Dec 2009 11:57:24 +0000
Subject: [issue7561] Filename-taking functions in posix segfault when called
	with a bytearray arg.
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261569444.87.0.13634722631.issue7561@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I briefly looked at how PyByteArray_AS_STRING() is used in other places.
A similar segfault can be provoked in long_new():

int(bytearray(b''), 10)


Then, there are a couple of places where pointer arithmetic is used with
the NULL pointer. Also, memcpy(x, NULL, 0) can occur. If I'm not
mistaken, both of these work in practice but are strictly speaking
undefined behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:22:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Dec 2009 13:22:51 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261574571.25.0.631040127513.issue7561@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Interpreter Core
priority: high -> critical
title: Filename-taking functions in posix segfault when called with a bytearray arg. -> PyByteArray_AS_STRING used unsafely

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:04:02 2009
From: report at bugs.python.org (Mike Putnam)
Date: Wed, 23 Dec 2009 15:04:02 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>


New submission from Mike Putnam <mike at theputnams.net>:

The documentation string within the IMAP4.thread function incorrectly
spells the "threading_algorithm" arg as "threading_alogrithm"

Appears to affect imaplib.py ver. 2.55 & 2.58  Could not find other
versions to examine.

Starting in:
/release24-maint/Lib/imaplib.py
__version__ = "2.55"     3 occurences of "threading_alogrithm"

/release25-maint/Lib/imaplib.py
__version__ = "2.58"     1 occurence  of "threading_alogrithm"

/release26-maint/Lib/imaplib.py
__version__ = "2.58"     1 occurence  of "threading_alogrithm"

/release30-maint/Lib/imaplib.py
__version__ = "2.58"     1 occurence  of "threading_alogrithm"

/release31-maint/Lib/imaplib.py
__version__ = "2.58"     1 occurence  of "threading_alogrithm"

----------
components: Library (Lib)
messages: 96839
nosy: mikeputnam
severity: normal
status: open
title: Spelling error in imaplib module docs
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:33:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Dec 2009 15:33:53 +0000
Subject: [issue1811] True division of integers could be more accurate
In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
Message-ID: <1261582433.15.0.849644454059.issue1811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated patch, against py3k.  On my machine, a/b is a touch faster with this patch when abs(a), 
abs(b) are smaller than 1e15 or so;  it's (inevitably) slower than the existing implementation for larger a 
and b.  For 'random' a and b, average running time is proportional to the size of b, and is independent of 
the size of a;  worst-case running time (which occurs when a has many trailing zero bits) grows as 
max(size(a), size(b)).

Changing versions to 2.7 and 3.2, but I'm mostly aiming for 3.2.  It may not be worth backporting to 2.7, 
given the extra effort required to deal correctly with ints as well as with longs.

----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0
Added file: http://bugs.python.org/file15667/long_division2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:40:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Dec 2009 15:40:11 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261582811.29.0.411928962341.issue7568@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:40:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Dec 2009 15:40:21 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261582821.04.0.256830359018.issue7568@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:43:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Dec 2009 15:43:03 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261582983.85.0.260630009448.issue7568@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:54:14 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 23 Dec 2009 15:54:14 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261534026.34.0.441945918734.issue7566@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBD5BA10765E2@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That's an excellent idea. I had searched briefly for a more correct solution, but did not find one at the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________

From report at bugs.python.org  Wed Dec 23 17:23:08 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 23 Dec 2009 16:23:08 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1261585388.05.0.115119865795.issue7566@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/issue7566>
_______________________________________

From report at bugs.python.org  Wed Dec 23 20:15:47 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 23 Dec 2009 19:15:47 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

It would be great if the documentation of c_char_p
(http://docs.python.org/library/ctypes.html#ctypes.c_char_p) could be
reformulated as follows (would have saved me quite some time):

class ctypes.c_char_p?
    Represents the C char * datatype when it points a zero-terminated
string. For a general character pointer that may also point to binary
data, POINTER(c_char) must be used. The constructor accepts an integer
address, or a string.

----------
assignee: georg.brandl
components: Documentation
messages: 96842
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: ctypes doc improvement: c_char_p
type: feature request
versions: 3rd party, 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/issue7569>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:11:58 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Wed, 23 Dec 2009 21:11:58 +0000
Subject: [issue7570] Error in urllib2 example
In-Reply-To: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>
Message-ID: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>


New submission from Manuel Murad?s <mmuradas at dieresys.com.ar>:

We've found an error in an urllib2 example with Proxy Basic
authentication. This is the example with the error:
{{{
This example replaces the default ProxyHandler with one that uses
programmatically-supplied proxy URLs, and adds proxy authorization
support with ProxyBasicAuthHandler.

proxy_handler = urllib2.ProxyHandler({'http':
'http://www.example.com:3128/'})
proxy_auth_handler = urllib2.HTTPBasicAuthHandler()
proxy_auth_handler.add_password('realm', 'host', 'username', 'password')

opener = build_opener(proxy_handler, proxy_auth_handler)
# This time, rather than install the OpenerDirector, we use it directly:
opener.open('http://www.example.com/login.html')
}}}

Attached you will find a patch with the fix.

----------
assignee: georg.brandl
components: Documentation
files: urllib2.patch
keywords: patch
messages: 96843
nosy: dieresys, georg.brandl
severity: normal
status: open
title: Error in urllib2 example
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15668/urllib2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7570>
_______________________________________

From report at bugs.python.org  Wed Dec 23 23:11:05 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Wed, 23 Dec 2009 22:11:05 +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: <1261606265.56.0.614168338497.issue7291@psf.upfronthosting.co.za>


Manuel Murad?s <mmuradas at dieresys.com.ar> added the comment:

Hi! 2.6 backport is missing an argument in _set_tunnel definition. It
should be:

    def _set_tunnel(self, host, port=None, headers=None):

----------
nosy: +dieresys

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Wed Dec 23 23:16:01 2009
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Wed, 23 Dec 2009 22:16:01 +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: <1261606561.5.0.178392728179.issue7291@psf.upfronthosting.co.za>


Manuel Murad?s <mmuradas at dieresys.com.ar> added the comment:

The patch fixes only when you pass the authentication info in the proxy
handler's URL. Like:

    proxy_handler = urllib2.ProxyHandler({'https':
'http://user:pass at proxy-example.com:3128/'})

But setting the authentication using a ProxyBasicAuthHandler is still
broken:

    proxy_auth_handler = urllib2.ProxyBasicAuthHandler()
    proxy_auth_handler.add_password('realm', 'proxy-example.com:3128',
'user', 'pass')

In the attached file (urllib2_with_proxy_auth_comparison.py) we've wrote
a comparison between what works with HTTP and HTTPS.

The problem is the 407 error never reaches the ProxyBasicAuthHandler
because HTTPConnection._tunnel raises an exception when the http
response status code is not 200.

----------
Added file: http://bugs.python.org/file15669/urllib2_with_proxy_auth_comparison.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Thu Dec 24 00:06:15 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Dec 2009 23:06:15 +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: <1261609575.99.0.592384893651.issue7544@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: multiprocessing.Pool(): Fatal Python error: PyEval_AcquireThread: NULL new thread state -> Fatal error on thread creation in low memory condition

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Thu Dec 24 01:53:31 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 24 Dec 2009 00:53:31 +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: <20091224005321.GE4089@ubuntu.ubuntu-domain>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the note, Manuel. Fixed it in revision 77013.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Thu Dec 24 01:59:59 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 24 Dec 2009 00:59:59 +0000
Subject: [issue7570] Error in urllib2 example
In-Reply-To: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>
Message-ID: <1261616399.49.0.18437534876.issue7570@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7570>
_______________________________________

From report at bugs.python.org  Thu Dec 24 03:27:38 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 24 Dec 2009 02:27:38 +0000
Subject: [issue7570] Error in urllib2 example
In-Reply-To: <1261602718.38.0.18447814559.issue7570@psf.upfronthosting.co.za>
Message-ID: <1261621658.02.0.829481743775.issue7570@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed it in r77018 and merges.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7570>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:37:00 2009
From: report at bugs.python.org (Boya Sun)
Date: Thu, 24 Dec 2009 04:37:00 +0000
Subject: [issue6873] posix_lchown: possible overflow of uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1261629420.28.0.552783747521.issue6873@psf.upfronthosting.co.za>


Boya Sun <boya.sun at case.edu> added the comment:

Gregory,

I discovered this bug by static analysis, so I do not have a system 
that this bug is actually triggered. But I am happy to see the fix 
applied since this makes code safer. It would be great if anyone could 
write a test case that cause uid and gid to overflow, then use the test 
case as a regression test on the fix.

Boya

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6873>
_______________________________________

From report at bugs.python.org  Thu Dec 24 07:48:42 2009
From: report at bugs.python.org (Frank Millman)
Date: Thu, 24 Dec 2009 06:48:42 +0000
Subject: [issue7571] Change 'name' of Process - assertion failure if Unicode
In-Reply-To: <1261637322.52.0.734915496426.issue7571@psf.upfronthosting.co.za>
Message-ID: <1261637322.52.0.734915496426.issue7571@psf.upfronthosting.co.za>


New submission from Frank Millman <frank at chagford.com>:

At the top of my program, I have 'from __future__ import 
unicode_literals'.

I subclassed Process, and passed "name='test'" as an argument. I got 
the following traceback.

Traceback (most recent call last):
  File "F:\junk\multiprocess\mp5.py", line 37, in <module>
    p = Frank(name='test')
  File "F:\junk\multiprocess\mp5.py", line 18, in __init__
    self.name = name
  File "C:\Python26\lib\multiprocessing\process.py", line 141, in name
    assert isinstance(name, str), 'name must be a string'
AssertionError: name must be a string

If I change the argument to "name=str('test')" there is no error.

For Python 2.x I think the assertion should be "isinstance(name, 
basestring)" to prevent this from happening.

----------
components: Library (Lib)
messages: 96849
nosy: frankmillman
severity: normal
status: open
title: Change 'name' of Process - assertion failure if Unicode
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7571>
_______________________________________

From report at bugs.python.org  Thu Dec 24 10:51:56 2009
From: report at bugs.python.org (Daniel)
Date: Thu, 24 Dec 2009 09:51:56 +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: <1261648316.0.0.663881484604.issue2698@psf.upfronthosting.co.za>


Daniel <daniel.mondon at free.fr> added the comment:

Thank you :)

Daniel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Thu Dec 24 11:18:38 2009
From: report at bugs.python.org (lakshmipathi)
Date: Thu, 24 Dec 2009 10:18:38 +0000
Subject: [issue7572] Strabge issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>


New submission from lakshmipathi <lakshmipathi.g at gmail.com>:

Hi all,
I'm new user to python and sqlite, let me know if i'm wrong or it's
sqlite issue.When I uncomment the line from below program it works -as
expected. But even when it's commented It works for first time.-As per
doc,without commit -all changes will be lost- am i right?

Issue : Running the program once without commit works for the first time
but not the next time.

Try changing the return value from 'OSS' to 'GNU' and comment/uncomment
the commit line.
----------------------------------
Here is my program:
-------------------------------------
import sqlite3
def loopy():
	return 'OSS'
#get connection object 
conn = sqlite3.connect("/tmp/example")
#get curson obj. and invoke execute
cur = conn.cursor()

conn.create_function("loopy",0,loopy)

cur.execute("insert into stk values (loopy())""")
#commit changes.
#conn.commit()  # ******Uncomment this line and run again*******

# read values
cur.execute("select * from stk")
for row in cur:
	print row
	
cur.close()
-------------------------

----------
messages: 96851
nosy: lakshmipathi
severity: normal
status: open
title: Strabge issue : cursor.commit() with sqlite
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:26:21 2009
From: report at bugs.python.org (instigate_team)
Date: Thu, 24 Dec 2009 11:26:21 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>


New submission from instigate_team <narine_martirosyan at instigatedesign.com>:

Hello Python development team!

We encountered problem concerning Python 3.1 usage.

Platform info:

    Ubuntu 9.10 32/64bit, glibc v. 2.10.1, gcc v. 4.4.0, Python 3.1.

Problem description:

  Below is given the C++ program text causing the warning:
   
#include <string>
#include <Python.h>

int main()
{
     return 0;
}

Compilation result is the following:

In file included from /usr/include/python3.1/Python.h:8,
                 from main.cpp:3:
/usr/include/python3.1/pyconfig.h:1108:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from
/usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39,
                 from
/usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243,
                 from /usr/include/c++/4.4/string:40,
                 from main.cpp:2:
/usr/include/features.h:158:1: warning: this is the location of the
previous definition
In file included from /usr/include/python3.1/Python.h:8,
                 from main.cpp:3:
/usr/include/python3.1/pyconfig.h:1130:1: warning: "_XOPEN_SOURCE" redefined
In file included from
/usr/include/c++/4.4/i486-linux-gnu/bits/os_defines.h:39,
                 from
/usr/include/c++/4.4/i486-linux-gnu/bits/c++config.h:243,
                 from /usr/include/c++/4.4/string:40,
                 from main.cpp:2:
/usr/include/features.h:160:1: warning: this is the location of the
previous definition

Analyzing the error:

We find out that the includes sequence influences on the application
build. We have no problem in case if Python header is included before
"string" file.
The problem is concerning the conflict of pyconfig.h  and features.h
(/usr/include/features.h, which is the part of glibc), which is included
in string header file. We have the same result with any header file,
which includes features.h file.

File features.h defines _POSIX_C_SOURCE in case of some conditions are true.

In its turn pyconfig.h contains the following code in line 1108

#define _POSIX_C_SOURCE 200112L

And we get redefinition warning. Our projects are working with gcc
-Werror flags, so this is the blocking problem.

The same happened with _XOPEN_SOURCE.

Any help from your side will be very much appreciated.

----------
components: Build
messages: 96852
nosy: instigate_team
severity: normal
status: open
title: Python build issue on Ubuntu 9.10
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:54:41 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 24 Dec 2009 11:54:41 +0000
Subject: [issue7574] PyUnicode_FromFormat broken and not documented for 2.x
In-Reply-To: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>
Message-ID: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Include/unicodeobject.h includes prototypes for PyUnicode_FromFormat and 
PyUnicode_FromFormatV in both 2.6 and 2.7, but those functions are not 
included in the documention.

And worse, the implementation contains bugs: the %R format code tries to 
include the repr() of an object and blindly assumes that the result of 
PyObject_Repr is a unicode string. In the 2.x tree PyObject_Repr usually 
(but not allways) returns a regular string (str instead of unicode).

The same problem is present in the implementation of %S.

For the %U and %V formats the code does typechecking in an assert 
statement rather than always testing and bailing out using a NULL result 
from the function.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 96853
nosy: georg.brandl, ronaldoussoren
severity: normal
stage: needs patch
status: open
title: PyUnicode_FromFormat broken and not documented for 2.x
type: crash
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7574>
_______________________________________

From report at bugs.python.org  Thu Dec 24 13:08:00 2009
From: report at bugs.python.org (Carl Chenet)
Date: Thu, 24 Dec 2009 12:08:00 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1261656480.75.0.00460000869923.issue7418@psf.upfronthosting.co.za>


Carl Chenet <chaica at ohmytux.com> added the comment:

Hi,

Maybe you have some ideas on this patch? I think it could be a nice
feature e.g in my app I need to support every hash algorithms available
so with optparse module it is possible to write something like :
 
        for __hashtype in ('md5', 'sha1',
'sha224','sha256','sha384','sha512'):
            __parser.add_option('--{}'.format(__hashtype), dest='hashtype',
                action='store_const', const='{}'.format(__hashtype),
                help='use the {} hash algorithm type'.format(__hashtype))
        __options, _ = __parser.parse_args()

And it would be better if this tuple could be provided by the hashlib
module itself, making the code more evolutive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7418>
_______________________________________

From report at bugs.python.org  Thu Dec 24 13:09:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Dec 2009 12:09:58 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1261656598.5.0.187953380998.issue7573@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you do reorder the include statements, will then the warning go away?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:48:22 2009
From: report at bugs.python.org (instigate_team)
Date: Thu, 24 Dec 2009 13:48:22 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1261662502.46.0.212858191562.issue7573@psf.upfronthosting.co.za>


instigate_team <narine_martirosyan at instigatedesign.com> added the comment:

Yes, We have no warnings after changing the include sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:04:11 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 24 Dec 2009 14:04:11 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1261663451.84.0.693941161291.issue6834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed the completed patch as r77031 (trunk) and r77032 (py3k)

I will not backport to 2.6 and 3.1 because this is not a bugfix.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:25:34 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 24 Dec 2009 14:25:34 +0000
Subject: [issue7541] python-config --ldflags doesn't pick up libpython2.5.a
In-Reply-To: <1261153688.5.0.917977427633.issue7541@psf.upfronthosting.co.za>
Message-ID: <1261664734.13.0.393186455728.issue7541@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r77033 (trunk), r77034 (2.6), r77035 (py3k), r77036 (3.1)

Development on the 2.5 tree is closed, I will therefore not backport to 
2.5.

As a workaround you can add -Wl,-search_paths_first to the linker flags to 
ensure that the libpython.a in the framework gets picked up before 
/usr/lib/libpython2.5.dylib.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7541>
_______________________________________

From report at bugs.python.org  Thu Dec 24 16:20:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Dec 2009 15:20:12 +0000
Subject: [issue7571] Change 'name' of Process - assertion failure if Unicode
In-Reply-To: <1261637322.52.0.734915496426.issue7571@psf.upfronthosting.co.za>
Message-ID: <1261668012.03.0.754984926959.issue7571@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done in r77038.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7571>
_______________________________________

From report at bugs.python.org  Thu Dec 24 16:35:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Dec 2009 15:35:59 +0000
Subject: [issue7572] Strabge issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1261668959.65.0.559587183902.issue7572@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> ghaering
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:03:00 2009
From: report at bugs.python.org (Salman Haq)
Date: Thu, 24 Dec 2009 16:03:00 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>


New submission from Salman Haq <salman.haq at gmail.com>:

See output of regrtest below. It was run on an Intel Mac OS X 10.4

A similar failure is observed on the py3k branch.

./python.exe Lib/test/regrtest.py -v test_math

test_math
testAcos (test.test_math.MathTests) ... ok
testAcosh (test.test_math.MathTests) ... ok
testAsin (test.test_math.MathTests) ... ok
testAsinh (test.test_math.MathTests) ... ok
testAtan (test.test_math.MathTests) ... ok
testAtan2 (test.test_math.MathTests) ... ok
testAtanh (test.test_math.MathTests) ... ok
testCeil (test.test_math.MathTests) ... ok
testConstants (test.test_math.MathTests) ... ok
testCopysign (test.test_math.MathTests) ... ok
testCos (test.test_math.MathTests) ... ok
testCosh (test.test_math.MathTests) ... ok
testDegrees (test.test_math.MathTests) ... ok
testExp (test.test_math.MathTests) ... ok
testFabs (test.test_math.MathTests) ... ok
testFactorial (test.test_math.MathTests) ... ok
testFloor (test.test_math.MathTests) ... ok
testFmod (test.test_math.MathTests) ... ok
testFrexp (test.test_math.MathTests) ... ok
testFsum (test.test_math.MathTests) ... ok
testHypot (test.test_math.MathTests) ... ok
testIsinf (test.test_math.MathTests) ... ok
testIsnan (test.test_math.MathTests) ... ok
testLdexp (test.test_math.MathTests) ... ok
testLog (test.test_math.MathTests) ... ok
testLog10 (test.test_math.MathTests) ... ok
testLog1p (test.test_math.MathTests) ... ok
testModf (test.test_math.MathTests) ... ok
testPow (test.test_math.MathTests) ... ok
testRadians (test.test_math.MathTests) ... ok
testSin (test.test_math.MathTests) ... ok
testSinh (test.test_math.MathTests) ... ok
testSqrt (test.test_math.MathTests) ... ok
testTan (test.test_math.MathTests) ... ok
testTanh (test.test_math.MathTests) ... ok
test_exceptions (test.test_math.MathTests) ... ok
test_mtestfile (test.test_math.MathTests) ... FAIL
test_testfile (test.test_math.MathTests) ... ok
test_trunc (test.test_math.MathTests) ... ok
Doctest: ieee754.txt ... ok

======================================================================
FAIL: test_mtestfile (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/salman/svn/python/trunk/Lib/test/test_math.py", line
1016, in test_mtestfile
    '\n  '.join(failures))
AssertionError: Failures in test_mtestfile:
  expm10302:expm1(709.7827128932839): expected 1.797693134682424e+308,
got 'OverflowError'

----------------------------------------------------------------------
Ran 40 tests in 2.273s

FAILED (failures=1)
test test_math failed -- Traceback (most recent call last):
  File "/Users/salman/svn/python/trunk/Lib/test/test_math.py", line
1016, in test_mtestfile
    '\n  '.join(failures))
AssertionError: Failures in test_mtestfile:
  expm10302:expm1(709.7827128932839): expected 1.797693134682424e+308,
got 'OverflowError'

1 test failed:
    test_math

----------
components: Tests
messages: 96860
nosy: slmnhq
severity: normal
status: open
title: tes_math fails Mac OS X 10.4 due to OverflowError in test_mtestfile
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:03:18 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 24 Dec 2009 16:03:18 +0000
Subject: [issue3363] python version incorrectly reported in crash reports on
	Mac OS X 10.4.11 PPC
In-Reply-To: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za>
Message-ID: <1261670598.3.0.304621054501.issue3363@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is no longer an issue: the Info.plist is now initialized by the build 
process and includes the correct version number. At the time the bug was 
files the plist needed to be updated manually and that didn't always 
happen (or rather, more often than not it didn't get updated at new 
releases)

----------
keywords: +easy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3363>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:07:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 16:07:55 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261670875.45.0.723547506276.issue7575@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
priority:  -> normal
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:17:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 16:17:22 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261671442.14.0.464340902853.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Salman Haq also reported (on IRC) that the configure output shows:

checking for expm1... yes

so this appears to be a problem with the platform's implementation of 
expm1, rather than with Python's expm1 code (which is only used when the 
platform version isn't available).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:19:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 16:19:33 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261671573.76.0.215860206039.issue7568@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  Fixed in revisions r77041 through r77044.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:19:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 16:19:41 +0000
Subject: [issue7568] Spelling error in imaplib module docs
In-Reply-To: <1261580641.6.0.189966780235.issue7568@psf.upfronthosting.co.za>
Message-ID: <1261671581.88.0.771544051339.issue7568@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7568>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:26:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 16:26:40 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261672000.41.0.474989949905.issue7575@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:55:28 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Dec 2009 16:55:28 +0000
Subject: [issue7526] tkinter menubutton underline behaviour varies between
	tkinter * and tkinter.ttk *
In-Reply-To: <1260981799.48.0.698138003814.issue7526@psf.upfronthosting.co.za>
Message-ID: <1261673728.99.0.777621735398.issue7526@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I get the same behavior while using ttk in wish8.5, so this is not 
related to the ttk.py module.

But, after looking this sample you posted, it looks like you want 
something like this instead:

from tkinter import Tk, Menu

root = Tk()
menu = Menu()
root['menu'] = menu

filemenu = Menu(menu)
menu.add_cascade(label="File", menu=filemenu, underline=0)
filemenu.add_command(label="New", accelerator="Ctrl+N")

root.geometry("300x300")
root.mainloop()

----------
nosy: +gpolo
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7526>
_______________________________________

From report at bugs.python.org  Thu Dec 24 18:05:59 2009
From: report at bugs.python.org (Salman Haq)
Date: Thu, 24 Dec 2009 17:05:59 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1261674359.17.0.455111551945.issue4388@psf.upfronthosting.co.za>


Salman Haq <salman.haq at gmail.com> added the comment:

Confirming that the test fails on r77044. 

Tested on Mac OS X 10.4.11 (Intel).

running build_scripts
test_cmd_line
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_q (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... FAIL
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok

======================================================================
FAIL: test_run_code (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/Users/salman/svn/python/branches/py3k/Lib/test/test_cmd_line.py", line 
132, in test_run_code
    0)
AssertionError: 1 != 0

----------------------------------------------------------------------
Ran 13 tests in 2.235s

FAILED (failures=1)
test test_cmd_line failed -- Traceback (most recent call last):
  File 
"/Users/salman/svn/python/branches/py3k/Lib/test/test_cmd_line.py", line 
132, in test_run_code
    0)
AssertionError: 1 != 0

1 test failed:
    test_cmd_line

----------
nosy: +slmnhq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Dec 24 18:17:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 17:17:10 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261675030.17.0.366482616002.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems to be specific to OS X/Intel:  I'm not seeing any failure on my 
ancient iBook G4 (OS X 10.4.11).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 18:24:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 17:24:58 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261675498.86.0.656918046891.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Salman Haq, could you find out roughly where expm1 starts overflowing on 
your machine?  E.g., do all of the following overflow for you?

>>> from math import expm1
>>> expm1(709.78271289338397)
1.7976931348622732e+308
>>> expm1(709.782712893)
1.797693134172102e+308
>>> expm1(709.7827)
1.7976699566638014e+308
>>> expm1(709.7)
1.6549840276802644e+308

I'm just trying to determine whether the 10.4 expm1 is so broken that 
Python should work around it, or whether it's only slightly broken.  In 
the latter case we can just live with it, and either weaken the tests 
slightly or explicitly skip that particularly test on OS X 10.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 18:38:37 2009
From: report at bugs.python.org (Salman Haq)
Date: Thu, 24 Dec 2009 17:38:37 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261676317.1.0.216316197152.issue7575@psf.upfronthosting.co.za>


Salman Haq <salman.haq at gmail.com> added the comment:

Only the argument with one decimal place precision does NOT overflow.

Python 2.7a1+ (trunk:76872, Dec 21 2009, 09:54:29) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import expm1
>>> expm1(709.78271289338397)     
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> expm1(709.782712893)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> expm1(709.7827)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> expm1(709.782)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> expm1(709.78)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
>>> expm1(709.7)
1.6549840276802644e+308

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 20:15:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 19:15:51 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261682151.16.0.486871126691.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for that.  I'd call that pretty broken then:  the result of 
expm1(709.78) is effectively wrong by 24.4 trillion ulps (perhaps that 
should be 24.4 teraulps?).  I guess someone just coded a hard cutoff value 
somewhere between 709.7 and 709.78.

But since anyone getting this close to overflow is asking for trouble 
anyway, perhaps the easiest solution is just to change the test to test a 
value not quite as close to the overflow boundary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 20:22:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 19:22:00 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1261682520.3.0.378569264551.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch (against trunk).

----------
keywords: +patch
Added file: http://bugs.python.org/file15670/issue7575.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Thu Dec 24 20:52:23 2009
From: report at bugs.python.org (Joe Amenta)
Date: Thu, 24 Dec 2009 19:52:23 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261684343.23.0.954851699189.issue7006@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

One such weird corner case:

from collections import Callable
class Spam(object):
   def __call__(self):
      return self

can_of_spam = Spam()
print callable(can_of_spam) == isinstance(can_of_spam, Callable) # True
del Spam.__call__
can_of_spam.__call__ = lambda can: 'spam'
print callable(can_of_spam) == isinstance(can_of_spam, Callable) # False

Regardless, attached a patch for the new proposed semantics

----------
keywords: +patch
nosy: +joe.amenta
Added file: http://bugs.python.org/file15671/new_callable_semantics.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:37:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 22:37:51 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1261694271.84.0.71005263921.issue7561@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:03:10 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Dec 2009 23:03:10 +0000
Subject: [issue6108] unicode(exception) and str(exception) should return the
	same message on Py2.6
In-Reply-To: <1243313597.65.0.747575886374.issue6108@psf.upfronthosting.co.za>
Message-ID: <1261695790.27.0.0760105751686.issue6108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77045 (trunk) and r77046 (release26-maint). No need to port it
to py3k since unicode() is gone.

----------
keywords:  -needs review
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6108>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:14:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Dec 2009 23:14:07 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1261696447.26.0.242034896453.issue3132@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Fri Dec 25 01:03:50 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 25 Dec 2009 00:03:50 +0000
Subject: [issue7572] Strabge issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1261699430.32.0.674829398606.issue7572@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Please change your test case so that it works with an in-memory database
":memory:". Then you'll also need to include a schema creation command
"create table", which is missing here.

Please also state which behaviour you see and which one you expect. Best
is to provide a test case that asserts the expected behaviour in code.

For example if you expect a certain SELECT statement to return more than
one value, you can use code like this:

{{{
cur.execute("select ...")
rows = cur.fetchall()
assert len(rows) > 1
}}}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Fri Dec 25 02:31:47 2009
From: report at bugs.python.org (Craig McQueen)
Date: Fri, 25 Dec 2009 01:31: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: <1261704707.39.0.37915205814.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Eric (keldonin), please consider attaching the file (solution you
mentioned) to this issue for the benefit of the rest of us. I'm
interested to see it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Fri Dec 25 02:37:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Dec 2009 01:37:36 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1261705056.92.0.35802020058.issue7569@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +theller
priority:  -> normal
versions:  -3rd party, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________

From report at bugs.python.org  Fri Dec 25 03:02:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Dec 2009 02:02:36 +0000
Subject: [issue7514] doc: documentation for "sys.flags" is obsolete.
In-Reply-To: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
Message-ID: <1261706556.95.0.784037091615.issue7514@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There are a couple of options missing from the trunk doc too
(no_user_site and bytes_warning).
I'll fix both.

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7514>
_______________________________________

From report at bugs.python.org  Fri Dec 25 03:21:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Dec 2009 02:21:11 +0000
Subject: [issue7514] doc: documentation for "sys.flags" is obsolete.
In-Reply-To: <1260892639.52.0.821475780434.issue7514@psf.upfronthosting.co.za>
Message-ID: <1261707671.47.0.57228523375.issue7514@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77050 (trunk), r77051 (release26-maint), r77052 (py3k), r77053
(release31-maint). Thanks for the report and the patch!

----------
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/issue7514>
_______________________________________

From report at bugs.python.org  Fri Dec 25 03:28:22 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Dec 2009 02:28:22 +0000
Subject: [issue7574] PyUnicode_FromFormat broken and not documented for 2.x
In-Reply-To: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>
Message-ID: <1261708102.82.0.641000005064.issue7574@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7574>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:11:55 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Dec 2009 07:11:55 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261725115.49.0.690857317885.issue7006@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That isn't a semantic change, it is exactly the same semantics as
callable() in 2.x:

>>> class Spam(object):
...   def __call__(self): pass
...
>>> callable(Spam())
True
>>> del Spam.__call__
>>> callable(Spam())
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:13:50 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Dec 2009 07:13:50 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261725230.68.0.855712413267.issue7006@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just confirming that 2.x also correctly ignores instance attributes (as
it should, since it looks at the tp_call slot):

>>> odd = Spam()
>>> odd.__call__ = lambda: 'very odd'
>>> callable(odd)
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:16:16 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Dec 2009 07:16:16 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261725376.64.0.183075050149.issue7006@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The patch however does not look correct - the import should be added as
a global import at the beginning of affected files rather than inline
with each callable check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:22:44 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 25 Dec 2009 07:22:44 +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: <1261725764.38.0.605170326922.issue7540@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/issue7540>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:23:10 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 25 Dec 2009 07:23:10 +0000
Subject: [issue7564] test_ioctl fails sometimes
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1261725790.49.0.418974071399.issue7564@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/issue7564>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:41:54 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 25 Dec 2009 07:41:54 +0000
Subject: [issue7519] CompileParser can't read files with BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1261726914.23.0.0254844024127.issue7519@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/issue7519>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:46:05 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 25 Dec 2009 07:46:05 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
	rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1261727165.57.0.89501176494.issue7503@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/issue7503>
_______________________________________

From report at bugs.python.org  Fri Dec 25 09:00:46 2009
From: report at bugs.python.org (Nir Aides)
Date: Fri, 25 Dec 2009 08:00:46 +0000
Subject: [issue7481] Failing to start a thread leaves "zombie" thread in
	"initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1261728046.7.0.323213240344.issue7481@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/issue7481>
_______________________________________

From report at bugs.python.org  Fri Dec 25 12:28:15 2009
From: report at bugs.python.org (Trundle)
Date: Fri, 25 Dec 2009 11:28:15 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261740495.11.0.380270866877.issue7006@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

What Joe Amenta stumbled across is that ABCMeta caches its subclass 
checks. If you call ``isinstance(spam, Callable)`` and after that delete 
`type(spam).__call__`, every other call of ``isinstance(spam, Callable)`` 
will still return True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 13:40:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Dec 2009 12:40:19 +0000
Subject: [issue7576] Avoid warnings in PyModuleDef_HEAD_INIT
In-Reply-To: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za>
Message-ID: <1261744819.66.0.987087888755.issue7576@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

When running GCC with warnings the compiler can warn about incomplete 
structure initializers. This gives spurious warnings when initializing a 
PyModuleDef structure using PyModuleDef_HEAD_INIT

The attached patchs changes PyModuleDef_HEAD_INIT to explicitly 
initialize all fields in PyModuleDef_Base.

An example warning that is silenced by this patch:

Modules/objc/test/structpointer2.m:19: warning: missing initializer
Modules/objc/test/structpointer2.m:19: warning: (near initialization for 
?mod_module.m_base.m_init?)

----------
files: moduleobject-init-warnings.patch
keywords: needs review, patch, patch
messages: 96881
nosy: ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid warnings in PyModuleDef_HEAD_INIT
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file15672/moduleobject-init-warnings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7576>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:25:25 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Dec 2009 13:25:25 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261747525.33.0.460914596453.issue7006@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah yes, I misread the example. Agreed that that is a change in behaviour
then - it is possible to clear the caches if absolutely necessary, but
doing so isn't particularly portable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:32:56 2009
From: report at bugs.python.org (Joe Amenta)
Date: Fri, 25 Dec 2009 17:32:56 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261762376.2.0.852600911935.issue7006@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

I believe that this patch works like you described...

Attached a patch with more test cases to show this.

(the [1:] parts are to make the test cases readable; they will still pass 
if all the leading newlines are removed from the triple-quoted strings and 
all [1:] are removed :-)

----------
Added file: http://bugs.python.org/file15673/new_callable_semantics_moretests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:41:08 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Fri, 25 Dec 2009 17:41:08 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1261762868.53.0.804786306694.issue7484@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

This patch solves the problem with the VRFY command, but I'm still 
wondering if this happens with other commands too.

----------
keywords: +patch
nosy: +pablomouzo
Added file: http://bugs.python.org/file15674/issue7484-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:41:43 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Fri, 25 Dec 2009 17:41:43 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1261762903.28.0.803865818489.issue7484@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


Added file: http://bugs.python.org/file15675/issue7484-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:47:40 2009
From: report at bugs.python.org (Joe Amenta)
Date: Fri, 25 Dec 2009 17:47:40 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1261763260.52.0.109224202417.issue7006@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

To elaborate on my last comment:

- touch_import looks for the required import binding in any scope, and it 
will add a global import if not found, otherwise it leaves it alone
- the import added does not have a newline prefix, so if the newlines were 
left in, (without [1:]) the tests would fail.
  However, I found that the test cases are easier to read if they all 
start on the same indentation level, so adding a newline for the reader 
but telling the parser to ignore it makes readable, correct test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:37:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Dec 2009 20:37:54 +0000
Subject: [issue6710] hotshot stats load causes TypeError when multiple files
	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1261773474.57.0.0568227350987.issue6710@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The change that causes this problem has been introduced in r60149 to fix
#1269.

----------
nosy: +ezio.melotti, georg.brandl, therve
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________

From report at bugs.python.org  Sat Dec 26 01:06:56 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Dec 2009 00:06:56 +0000
Subject: [issue7519] ConfigParser can't read files with BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1261786016.77.0.471493974913.issue7519@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
title: CompileParser can't read files with BOM markers -> ConfigParser can't read files with BOM markers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7519>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:21:10 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 11:21:10 +0000
Subject: [issue1700507] Carbon.Scrap.PutScrapFlavor
Message-ID: <1261826470.26.0.209655508204.issue1700507@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/issue1700507>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:26:43 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 11:26:43 +0000
Subject: [issue2019] API to clear most free lists
In-Reply-To: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>
Message-ID: <1261826803.2.0.648117957368.issue2019@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Is patch this still relevant? 

The functionality seems to be present in the trunk and py3k.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2019>
_______________________________________

From report at bugs.python.org  Sat Dec 26 14:18:14 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 13:18:14 +0000
Subject: [issue3054] test_disutils fails
In-Reply-To: <1212788058.33.0.328120732213.issue3054@psf.upfronthosting.co.za>
Message-ID: <1261833494.85.0.0672126144619.issue3054@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This issue is fixed in the 2.7 and 3.2 trees.

I'm therefore closing this issue.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3054>
_______________________________________

From report at bugs.python.org  Sat Dec 26 16:11:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 15:11:56 +0000
Subject: [issue7577] documention buglet
In-Reply-To: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>
Message-ID: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for bf_getbuffer at <http://www.python.org/doc/3.1/c-
api/typeobj.html#buffer-object-structures> claims:

<quote>
The signature of getbufferproc is int (PyObject *obj, PyObject *view, 
int flags). obj is the object to export, view is the Py_buffer struct to 
fill
</quote>

This is incorrect, the 'view' argument has type 'Py_buffer*'.

The same issue is also present in the 3.2 documentation (and I haven't 
checked the 2.6/2.7 docs yet)

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 96889
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: documention buglet
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7577>
_______________________________________

From report at bugs.python.org  Sat Dec 26 16:47:31 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Dec 2009 15:47:31 +0000
Subject: [issue7577] documention buglet for PyBuffer
In-Reply-To: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>
Message-ID: <1261842451.56.0.935243877565.issue7577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Another buffer documentation buglet is the documentation for 
'PyBuffer_FillInfo'. The prototype in the documentation is:

int PyBuffer_FillInfo(Py_buffer *view, void *buf, Py_ssize_t len, int 
readonly, int infoflags)

The real prototype has an additional argument (the second one in the 
prototype below):

int PyBuffer_FillInfo(Py_buffer *view, PyObject *o, void *buf,
                                       Py_ssize_t len, int readonly,
                                       int flags);

----------
title: documention buglet -> documention buglet for PyBuffer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7577>
_______________________________________

From report at bugs.python.org  Sat Dec 26 21:11:07 2009
From: report at bugs.python.org (Salman Haq)
Date: Sat, 26 Dec 2009 20:11:07 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1261858267.16.0.353658766041.issue7559@psf.upfronthosting.co.za>


Salman Haq <salman.haq at gmail.com> added the comment:

Line 348 in trunk/Lib/test/test_unittest.py has a test case to
specifically test that in the described situation, the test returns an
AttributeError. Should this test be changed so that it passes if the
exception is in fact an ImportError?

   def test_loadTestsFromName__unknown_attr_name(self):
        loader = unittest.TestLoader()

        try:
            loader.loadTestsFromName('unittest.sdasfasfasdf')
        except AttributeError, e:
            self.assertEqual(str(e), "'module' object has no attribute
'sdasfasfasdf'")
        else:
            self.fail("TestLoader.loadTestsFromName failed to raise
AttributeError")

----------
nosy: +slmnhq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Sat Dec 26 21:48:36 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sat, 26 Dec 2009 20:48:36 +0000
Subject: [issue7578] Behavio of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

The io.IOBase class doc says:
"""Note that calling any method (even inquiries) on a closed stream is
undefined. Implementations may raise IOError in this case."""

But the io.IOBase.close() method document says:
"""Once the file is closed, any operation on the file (e.g. reading or
writing) will raise an IOError."""
which unlike the class doc is not conditional about the behavior...

Experimentation (see below) show that I get a ValueError in practice
(python 3.1, but also true for 2.6) with io.BufferedWriter and
io.StringIO objects.

>>> with open( 'dummy', 'wb') as f:
...     pass
...
>>> f.write( b'' )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: write to closed file
>>> f.writable()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

>>> import io
>>> s = io.StringIO()
>>> s.close()
>>> s.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

----------
assignee: georg.brandl
components: Documentation
messages: 96892
nosy: blep, georg.brandl
severity: normal
status: open
title: Behavio of operations on a closed file object is not documented correctly
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Sat Dec 26 21:49:17 2009
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sat, 26 Dec 2009 20:49:17 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261860557.5.0.137780030736.issue7578@psf.upfronthosting.co.za>


Changes by Baptiste Lepilleur <blep at users.sourceforge.net>:


----------
title: Behavio of operations on a closed file object is not documented correctly -> Behavior of operations on a closed file object is not documented correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Sat Dec 26 22:29:29 2009
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 26 Dec 2009 21:29:29 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Patch to provide docstrings throughout the msvcrt module.

----------
assignee: georg.brandl
components: Documentation, Windows
files: msvcrt_docstrings.diff
keywords: patch
messages: 96893
nosy: brian.curtin, georg.brandl
severity: normal
status: open
title: Patch to add docstrings to msvcrt
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15676/msvcrt_docstrings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Sat Dec 26 23:03:13 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Dec 2009 22:03:13 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1261864993.19.0.633336940778.issue5116@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

_CrtSetReportMode() is exposed without the leading underscore. IMO the 
_CRT_WARN and other constants should be renamed the same way.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5116>
_______________________________________

From report at bugs.python.org  Sun Dec 27 04:20:20 2009
From: report at bugs.python.org (=?utf-8?b?5L2Z6LCo5pm6?=)
Date: Sun, 27 Dec 2009 03:20:20 +0000
Subject: [issue4758] Python 3.0 internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1261884020.49.0.283781214845.issue4758@psf.upfronthosting.co.za>


??? <yu_jin_zhi at 163.com> added the comment:

As my opinion, Adding them as comments here is better as we can see the
same kind of issues all at once.

----------
nosy: +yu_jin_zhi
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:02:05 2009
From: report at bugs.python.org (Ben Kaplan)
Date: Sun, 27 Dec 2009 04:02:05 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>


New submission from Ben Kaplan <benjamin.kaplan at case.edu>:

Comes from this thread on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e15915df2e9cdd9/

The Makefile for distutils in the Mac binary for Python 3.1 specifies
the use of the OS X 10.4u SDK. However, XCode only includes the SDK for
the newest two versions of OS X, currently 10.5 and 10.6. This causes
build problems with gmpy on OS X Snow Leopard and the newest XCode. It
probably will also cause problems on other libraries that are compiled
using distutils but I've seen no other reports of issues. I don't know
enough about makefiles to come up with a patch that would work on all
supported versions of OS X. 

The offending code is line 118 in the Makefile, which installs itself in
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/config/Makefile.
The line is
UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk

Here's a copy of Mensanator's errors:

$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
setup.py install
running install
running build
running build_ext
building 'gmpy' extension
creating build/temp.macosx-10.3-fat-3.1
creating build/temp.macosx-10.3-fat-3.1/src
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/
MacOSX10.4u.sdk
Please check your Xcode installation
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/
opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/
include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/
gmpy.o
In file included from src/gmpy.c:206:
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:11:20: error: limits.h: No such file or directory
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:14:2: error: #error "Something's broken.  UCHAR_MAX should be
defined in limits.h."
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:18:

----------
assignee: tarek
components: Distutils, Installation, Macintosh
messages: 96896
nosy: bskaplan, tarek
severity: normal
status: open
title: distutils makefile from python.org installer doesn't work on OS X Snow Leopard
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:07:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Dec 2009 04:07:31 +0000
Subject: [issue4758] Python 3.0 internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1261886851.07.0.0783410667548.issue4758@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If David doesn't answer I'd close this issue. A year passed since the
first message and several bugs have been probably fixed already.

----------
status: open -> pending
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:08:17 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 27 Dec 2009 04:08:17 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261886897.05.0.00755355124415.issue7580@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/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:14:41 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 04:14:41 +0000
Subject: [issue4758] Python 3.0 internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1261887281.26.0.669704832786.issue4758@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hi Ezio, let us not close the issue. Waiting for David Beazley's patch
is okay or even looking at specific modules pointed out from the point
of str vs bytes interfaces and if any docs can be improved, we can
improve them. If we determine there is none, then we can close it as fixed.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 07:41:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Dec 2009 06:41:27 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261896087.42.0.571094215531.issue7580@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 07:54:35 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 06:54:35 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1261896875.72.0.628774118668.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I am attaching an updated patch for caching the 301 redirects.
As per RFC 2616:

10.3.2 301 Moved Permanently
   ...
   ...references returned by the server, where possible. This response
is  cacheable unless indicated otherwise.

So, I have included an additional argument to the 301 method called
cacheable=True. Which can be used to turn off the cache if required.

I would like to seek some comments on the patch, specifically on adding
this cacheable=True keyword argument.  If its fine, I would go ahead and
check it in.

----------
Added file: http://bugs.python.org/file15677/urllib2-301-redirection.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755841>
_______________________________________

From report at bugs.python.org  Sun Dec 27 10:12:01 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 09:12:01 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1261905121.75.0.252508961211.issue5625@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the patch, Ned. Fixed in the trunk revision 77058.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Sun Dec 27 11:17:26 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 10:17:26 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1261909046.61.0.952067857158.issue5625@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Merged the fixes in r77059, r77060 and r77061
I fixed the thishost function to return all ips in py3k.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Sun Dec 27 11:48:09 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 27 Dec 2009 10:48:09 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261910889.68.0.924705515272.issue7580@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is happening because "./configure --enable-universalsdk" was used
in MacPorts.

In Python source, "/Mac/BuildScript/build-installer.py" can be used to
drive ./configure with another SDK (via --sdk-path) so maybe macports
itself should use it as a pre-built step.

In any case, maybe such an option could be added in configure itself. I
am adding Ronald into the loop, he'll propably know what's the best
thing to do.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:10:34 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Sun, 27 Dec 2009 11:10:34 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1260227301.79.0.395664550525.issue7451@psf.upfronthosting.co.za>
Message-ID: <1261912234.51.0.307179785981.issue7451@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I applied most of this patch to r206 of simplejson trunk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7451>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:30:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Dec 2009 11:30:32 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261913432.74.0.411904653217.issue7580@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

AFAIK This is already fixed in the repository. 

I don't have time to verify this right now, but will do so later this week 
(which is why I'm assigning the issue to myself)

----------
assignee: tarek -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:33:10 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Dec 2009 11:33:10 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261913590.26.0.121139059646.issue7580@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I forgot to mention the workaround for the 3.1 release: reinstall XCode 
and make sure that you don't do the default install, but select the 10.4u 
SDK for installation as well.

You may then run into linking issues, they only workaround for that is to 
patch the makefile: use 'gcc-4.0' instead of just 'gcc' for compiling and 
linking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:43:48 2009
From: report at bugs.python.org (WANG Lu)
Date: Sun, 27 Dec 2009 11:43:48 +0000
Subject: [issue7581] incomplete doc of zlib
In-Reply-To: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>
Message-ID: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>


New submission from WANG Lu <coolwanglu at gmail.com>:

Python version: 2.6.4 r264:75706 (ubuntu 9.10)

I'm working on zlib, and have been busy in finding a way of specify the
window size of compression.

After wasting minutes in python online doc, I google and find the way:

zlib.compressobj(level, method, window_size, mem_level)

However, in both online doc and build-in doc, only the first parameter
'level' is mentioned. This is too bad.

And I wonder if there are more missing ones.

----------
assignee: georg.brandl
components: Documentation
messages: 96906
nosy: coolwanglu, georg.brandl
severity: normal
status: open
title: incomplete doc of zlib
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7581>
_______________________________________

From report at bugs.python.org  Sun Dec 27 13:00:39 2009
From: report at bugs.python.org (WANG Lu)
Date: Sun, 27 Dec 2009 12:00:39 +0000
Subject: [issue7581] incomplete doc of zlib
In-Reply-To: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>
Message-ID: <1261915239.02.0.656304294748.issue7581@psf.upfronthosting.co.za>


WANG Lu <coolwanglu at gmail.com> added the comment:

Oh I found this is mentioned in
msg94409(http://bugs.python.org/issue7191#msg94409)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7581>
_______________________________________

From report at bugs.python.org  Sun Dec 27 13:02:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Dec 2009 12:02:25 +0000
Subject: [issue7451] improve json decoding performance
In-Reply-To: <1261912234.51.0.307179785981.issue7451@psf.upfronthosting.co.za>
Message-ID: <1261915390.3631.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 27 d?cembre 2009 ? 11:10 +0000, Bob Ippolito a ?crit :
> Bob Ippolito <bob at redivi.com> added the comment:
> 
> I applied most of this patch to r206 of simplejson trunk

Thank you. Will you port it to CPython yourself or would you prefer
someone else to do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7451>
_______________________________________

From report at bugs.python.org  Sun Dec 27 14:45:01 2009
From: report at bugs.python.org (Ben Kaplan)
Date: Sun, 27 Dec 2009 13:45:01 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1261921501.77.0.353108302844.issue7580@psf.upfronthosting.co.za>


Ben Kaplan <benjamin.kaplan at case.edu> added the comment:

The issue here isn't with Macports (which doesn't do a universal build
by default). It's with the installer on python.org which is also a
universal binary.

Macports has the advantage of knowing which OS version it's being
compiled on so it should just require a patch to the portfile. If this
issue does show up on the Macports universal build, someone should file
another report with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:10:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Dec 2009 15:10:12 +0000
Subject: [issue1811] True division of integers could be more accurate
In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
Message-ID: <1261926612.34.0.373213418328.issue1811@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r77062 (trunk), r77063 (py3k).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:43:02 2009
From: report at bugs.python.org (Iustin Pop)
Date: Sun, 27 Dec 2009 15:43:02 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1261928582.3.0.189621309382.issue7353@psf.upfronthosting.co.za>


Iustin Pop <iusty at k1024.org> added the comment:

Hi,

Might I suggest that, whatever the outcome of the re-adding intobject.h
discussion, the documentation is updated? I think I'm not the only
module author which spent time trying to understand why the 3.1
documentation refers to non-existent header before finally finding this
bug :)

thanks a lot,
iustin

----------
nosy: +iustin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:57:58 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 15:57:58 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

make diff.py produce unified diffs with ISO 8601 timestamps

Currently generated timestamps are difficult to separate from filename 
when parsing if you don't know that the diff was generated by diff.by
This patch make diff.py output more standard compliant by including ISO 
8601 timestamps that also conform to RFC 3339 profile for timestamp format 
on the internet.

----------
components: Demos and Tools
files: diff.py_iso_timestamps.diff
keywords: patch
messages: 96912
nosy: techtonik
severity: normal
status: open
title: [patch] diff.py to use iso timestamp
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15678/diff.py_iso_timestamps.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:21:39 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 16:21:39 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1261930899.41.0.620386811065.issue3599@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I dont see the failure on trunk either. 
Is it either specific to windows or existed back when the bug was raised?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:23:21 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2009 16:23:21 +0000
Subject: [issue6452] urllib2.Request() will not work with long authorization
	headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1261931001.98.0.94854318321.issue6452@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6452>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:50:32 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 16:50:32 +0000
Subject: [issue7583] doctest should normalize tabs when comparing output
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Since 2.4 doctest converts all tabs to 8-space sequences in test source. 
It should do the same with output it receives for comparison. Right now 
there is no way to write a correct doctest if the output includes tab 
character. See attached doctabtest.py

This change would be backwards compatible, because all tests with tabs are 
either fail or run with doctest.NORMALIZE_WHITESPACE flag, which is 
usually inappropriate for doctest cases that involve tab formatting.

----------
components: Tests
files: doctabtest.py
messages: 96914
nosy: techtonik
severity: normal
status: open
title: doctest should normalize tabs when comparing output
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15679/doctabtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7583>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:18:20 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sun, 27 Dec 2009 17:18:20 +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: <1261934300.42.0.948657793798.issue7540@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

The problem here is that the headers are not updated if they already 
exists. The solution is quite simple but breaks the tests because it 
"clobbers the existing headers".

You can do this:
...
req.add_data(some_data)
req.add_unredirected_header('Content-Length', len(some_data))
urllib2.urlopen(req)
...

But is risky because all the other headers are still outdated.

Is there any reason why you need to reuse the request object?

----------
keywords: +patch
nosy: +pablomouzo
Added file: http://bugs.python.org/file15680/bad_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Sun Dec 27 19:19:55 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 27 Dec 2009 18:19:55 +0000
Subject: [issue6452] urllib2.Request() will not work with long authorization
	headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1261937995.49.0.924669900322.issue6452@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/issue6452>
_______________________________________

From report at bugs.python.org  Sun Dec 27 19:28:58 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 27 Dec 2009 18:28:58 +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: <1261938538.38.0.494006705618.issue7544@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/issue7544>
_______________________________________

From report at bugs.python.org  Sun Dec 27 19:33:38 2009
From: report at bugs.python.org (Sriram)
Date: Sun, 27 Dec 2009 18:33:38 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1261938818.98.0.63561086889.issue5727@psf.upfronthosting.co.za>


Sriram <sriramrathinavelu at yahoo.com> added the comment:

Hi,

This is the first bug am working in python, kindly excuse my mistakes, 
if any.

As far as I can understand, the pdb disabled readline when an explicit 
stdin or stdout is passed, to allow remote debugging.

I found this in Python 2.5.4 Release log. 
"""
Patch #721464: pdb.Pdb instances can now be given explicit stdin and
  stdout arguments, making it possible to redirect input and output
  for remote debugging.
"""

Now in doctest.py since we pass the stdout argument (which is always 
sys.stdout) to pdb.py, readline is always disabled when pdb is invoked 
from doctest.py.

One fix I can think of is to have pdb disable use of readline, not if 
any output stream is passed but only if a output stream other than 
sys.stdout is passed. I infact believe, this will preserve the 
functionality of pdb.py that existed before release of version 2.5.4


The above fix would still not solve the problem because before we pass 
the output stream to pdb.py, we override sys.stdout in doctest to 
doctest's spoofout. So in pdb.py, sys.stdout will not point to real 
sys.stdout. This can be fixed by overriding sys.stdout after we 
initialize the debugger.

Please find the patch for doctest and pdb as an attachment. 

Thanks
Sriram

----------
Added file: http://bugs.python.org/file15681/readline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5727>
_______________________________________

From report at bugs.python.org  Sun Dec 27 20:18:08 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 19:18:08 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

RFC 3339 defines a standard for Date and Time on the Internet. 
http://www.ietf.org/rfc/rfc3339.txt Given that Python is increasingly 
popular on the Internet is should include convenience function to 
generate RFC 3339 timestamps in standard library.

It is impossible to generate RFC 3339 timestamps (that are also valid 
ISO 8601 timestamps) with datetime.strftime() alone, so the following 
code should be used:

import datetime

def rfcformat(dt):
    """ Output datetime in RFC 3339 format that is also valid ISO 8601
        timestamp representation"""

    if dt.tzinfo is None:
        suffix = "-00:00"
    else:
        suffix = dt.strftime("%z")
        suffix = suffix[:-2] + ":" + suffix[-2:]
    return dt.strftime("%Y-%m-%dT%H:%M:%S") + suffix

----------
components: Library (Lib)
messages: 96917
nosy: techtonik
severity: normal
status: open
title: datetime.rfcformat() for Date and Time on the Internet
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Sun Dec 27 20:19:13 2009
From: report at bugs.python.org (Nir Aides)
Date: Sun, 27 Dec 2009 19:19:13 +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: <1261941553.79.0.421809693984.issue7544@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Memory can be pre-allocated by thread_PyThread_start_new_thread() before 
thread is spawned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:07:10 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Dec 2009 20:07:10 +0000
Subject: [issue2019] API to clear most free lists
In-Reply-To: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>
Message-ID: <1261944430.29.0.122458242101.issue2019@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed, r60797 and r64753 removed sys._compact_freelists, in favor of an 
automatic call to all PyXxx_ClearFreelist() during the collection of the 
highest generation.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2019>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:27:32 2009
From: report at bugs.python.org (Till Maas)
Date: Sun, 27 Dec 2009 20:27:32 +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: <1261945652.09.0.43193688539.issue7540@psf.upfronthosting.co.za>


Till Maas <opensource at till.name> added the comment:

I do not need to reuse a request object, but I did in a script when only
the data was different for each request. If this is not meant to be
done, then any not meant to be done modification should somehow create
an error, when it is done, instead of silently performing broken HTTP
requests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7540>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:42:34 2009
From: report at bugs.python.org (Carwyn Edwards)
Date: Sun, 27 Dec 2009 20:42:34 +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: <1261946554.95.0.570389435296.issue6792@psf.upfronthosting.co.za>


Carwyn Edwards <carwyn at carwyn.com> added the comment:

This prevents numerous packages from installing correctly including the
current 0.6c11 version of setuptools. When the installer runs it reports
that it can't find the version of python installed from
python-2.6.4.amd64.msi.

It seems to be looking for it in:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\InstallPath]
@="C:\\Python26\\"

.. rather than the:
[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.6\InstallPath]
@="C:\\Python26\\"

.. that the python installer puts in the registry.

This is related to the conversation in this thread:

http://www.mail-archive.com/distutils-sig at python.org/msg10512.html

And to quote from http://bugs.python.org/setuptools/issue2 :

"The issue is with the .exe header used by the bdist_wininst command;
setuptools doesn't generate this wrapper itself; it uses the one
supplied by the distutils, so non-setuptools packages will have the same
problem.  Without a fixed .exe header in the Python installation, *all*
bdist_wininst-generated .exe installers (setuptools or distutils) will
have the same problem."

----------
nosy: +carwyn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:45:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Dec 2009 20:45:04 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1261946704.02.0.674264537945.issue7582@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Using ISO format certainly makes sense, but it seems to me that after 
dt=datetime.fromtimestamp(mtime), dt.tzinfo is always None, so the test is 
not necessary.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:46:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Dec 2009 20:46:56 +0000
Subject: [issue7581] incomplete doc of zlib
In-Reply-To: <1261914227.57.0.480854340776.issue7581@psf.upfronthosting.co.za>
Message-ID: <1261946816.66.0.206005671816.issue7581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Closing as duplicate of issue7191

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Odd behaviour with zlib.decompressobj optional parameter "wbits"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7581>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:53:32 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 27 Dec 2009 20:53:32 +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: <1261947212.07.0.958364660624.issue6792@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/issue6792>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:57:38 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 20:57:38 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The patch inserts \t character between filename and timestamp in unified 
and context diff headers. 

According to specification by Guido Van Rossum =)
http://www.artima.com/weblogs/viewpost.jsp?thread=164293

And de-facto output from various tools
http://code.google.com/p/python-patch/source/browse/#svn/trunk/doc

And the common sense
--- that it is easier to split	this stuff
+++ than this one into filename + timestamp

--- diff.py Sun Dec 27 16:08:28 2009
+++ trunk/diff.py	Sun Dec 27 15:46:58 2009

----------
components: Library (Lib)
files: difflib.tab_separated_filename.diff
keywords: patch
messages: 96924
nosy: techtonik
severity: normal
status: open
title: [patch] difflib should separate filename from timestamp with tab
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15682/difflib.tab_separated_filename.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Sun Dec 27 22:22:45 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Dec 2009 21:22:45 +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: <1261948965.42.0.0725922978014.issue6792@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Carwyn: those packages just need to create two versions of their
installers - one for 32-bit Python, and one for 64-bit Python. Please
report that to the respective packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Sun Dec 27 22:57:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Dec 2009 21:57:06 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261951026.06.0.58811970781.issue7578@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Should all these ValueErrors be turned into IOErrors?

----------
nosy: +amaury.forgeotdarc, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:00:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Dec 2009 22:00:30 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261951230.75.0.805577915628.issue7578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think we raise ValueError because that's already what 2.x does with
plain file objects. Also, it's true that it's a programming error (using
a closed file) and not really an "IO error".

Simplest would be to fix the docs for the io module, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:12:48 2009
From: report at bugs.python.org (sorin)
Date: Sun, 27 Dec 2009 22:12:48 +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: <1261951968.41.0.12309306968.issue6792@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

It is possible to create combined x86 and x64 msi files and in fact it
would be a good idea to have only one instead of two.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:12:55 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 27 Dec 2009 22:12:55 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1261951975.79.0.535367385153.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That's true. Is there any way to get current TZ offset in Python? I can't 
find anything better than datetime.datetime.now() - 
datetime.datetime.utcnow() and then rounding to a nearest minute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Mon Dec 28 00:03:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Dec 2009 23:03:43 +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: <1261955023.76.0.972240953498.issue6792@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

sorin: can you provide a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Dec 28 00:11:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 27 Dec 2009 23:11:37 +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: <1261955497.71.0.467912452984.issue6792@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Dec 28 01:34:21 2009
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 28 Dec 2009 00:34:21 +0000
Subject: [issue7586] Typo in collections documentation
In-Reply-To: <1261960461.08.0.700949009831.issue7586@psf.upfronthosting.co.za>
Message-ID: <1261960461.08.0.700949009831.issue7586@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

In the documentation for the namedtuple
(http://docs.python.org/3.1/library/collections.html), the following
phrase is incorrect:

The subclass shown above sets __slots__ to an empty tuple. This keeps
keep memory requirements low by preventing the creation of instance
dictionaries.

It should read

The subclass shown above sets __slots__ to an empty tuple. This helps
keep memory requirements low by preventing the creation of instance
dictionaries.

or

The subclass shown above sets __slots__ to an empty tuple. This keeps
memory requirements low by preventing the creation of instance dictionaries.

(either change "keeps" to "helps", or delete the next "keep").

----------
assignee: georg.brandl
components: Documentation
messages: 96931
nosy: georg.brandl, nneonneo
severity: normal
status: open
title: Typo in collections documentation
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7586>
_______________________________________

From report at bugs.python.org  Mon Dec 28 01:39:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Dec 2009 00:39:47 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1261960787.24.0.762415914185.issue7579@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a good idea. I have some comments though:
- the second docstring says "heapmin" when it should describe "locking".
- there are strange characters around "pushed back". Please use only ascii 
characters.
- The body of the docstrings should be split into separate lines. the 
ending ' \' should be replaced by with '\n\' (see Python/sysmodule.c, for 
example)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Mon Dec 28 02:56:15 2009
From: report at bugs.python.org (Phillip J. Eby)
Date: Mon, 28 Dec 2009 01:56:15 +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: <1261965375.49.0.84145297889.issue6792@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

ISTM there may be two ways to fix this problem; one was to change the
.exe header produced by bdist_wininst, but in retrospect, it can't fix
this because it's likely Windows' 64-to-32 bit conversion (Wow6432Node)
that's changing the registry path used, rather than anything that Python
or distutils is doing.

The other way, which has more probability of working, is for the 64-bit
Python installer to include an extra registry entry that would allow the
32 bit versions to find the 64-bit version.

(This might also require an install-time 64/32 compatibility check being
added to the .exe header for bdist_wininst to prevent installing
binary-incompatible extensions.)

----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Mon Dec 28 03:13:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 28 Dec 2009 02:13:54 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1261966434.75.0.443539224774.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

lemburg - see which issue #?

Anyways perhaps the right thing to do instead of trunk r65961 would have 
been to change the s# to an s*.

Undoing it will be more painful now as several changes have gone in since 
that require undoing and possibly redoing differently.

----------
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Dec 28 03:25:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 28 Dec 2009 02:25:54 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1261967154.09.0.375176917047.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

rpetrov - I couldn't really understand your message so I'm not sure if I'm 
answering the right things:  yes both the openssl and non-openssl modules 
need to behave identically.  the reason openssl is used when possible is 
that its optimized hash functions are several times faster than the plain 
C versions in the individual modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Dec 28 04:04:51 2009
From: report at bugs.python.org (Karen Tracey)
Date: Mon, 28 Dec 2009 03:04:51 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1261969491.9.0.0346684287396.issue3745@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

I think the missing issue reference is to this thread on python-dev:

http://mail.python.org/pipermail/python-dev/2009-December/094574.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Dec 28 07:29:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 06:29:41 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1261981781.77.0.546981501533.issue1755841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have trouble understanding what the patch does. I would expect it to
cache the <original URL> -> <redirected URL> mapping, but it seems to
cache the final HTTP response instead.

Also, it's not obvious in which situations the default for `cacheable`
would be overriden. Aren't http_error_301 and friends for internal use?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755841>
_______________________________________

From report at bugs.python.org  Mon Dec 28 08:59:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 07:59:35 +0000
Subject: [issue7577] documention buglet for PyBuffer
In-Reply-To: <1261840316.44.0.384020679104.issue7577@psf.upfronthosting.co.za>
Message-ID: <1261987175.67.0.484700755707.issue7577@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77081, r77082.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7577>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:02:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:02:17 +0000
Subject: [issue7586] Typo in collections documentation
In-Reply-To: <1261960461.08.0.700949009831.issue7586@psf.upfronthosting.co.za>
Message-ID: <1261987337.69.0.579808025717.issue7586@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77084.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7586>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:10:40 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:10:40 +0000
Subject: [issue7381] subprocess.check_output: "docstring has inconsistent
	leading whitespace"
In-Reply-To: <1258982917.41.0.193216902616.issue7381@psf.upfronthosting.co.za>
Message-ID: <1261987840.13.0.285917374424.issue7381@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, applied in r77086, r77087.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7381>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:12:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:12:09 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1261987929.1.0.639700112527.issue7569@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Wouldn't a "general" pointer better be of type c_void_p?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:14:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:14:14 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261988054.75.0.159185771479.issue7578@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree; though I would wish for a bit finer-grained I/O related
exceptions...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:14:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:14:24 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1261988064.23.0.492676693236.issue7578@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:27:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:27:49 +0000
Subject: [issue7530] doc of multiprocessing.managers is wrong (server_forever)
In-Reply-To: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
Message-ID: <1261988869.1.0.263109896661.issue7530@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7530>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:36:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:36:11 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1261989371.34.0.153986742686.issue7033@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch! I rewrote the C function a bit to also take a dict
argument, and added a test for that.  Committed in r77088.  Will merge
to py3k.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:46:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:46:32 +0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1261989992.0.0.134915387415.issue1286@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FWIW, for the sake of consistency I'm +1 on supporting the context
manager protocol on all file-like objects in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:48:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Dec 2009 08:48:38 +0000
Subject: [issue7404] optparse Documentation References Example Files that do
	not Exist
In-Reply-To: <1259377966.36.0.486259270616.issue7404@psf.upfronthosting.co.za>
Message-ID: <1261990118.72.0.603118591732.issue7404@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the report. I removed the references in r77092.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7404>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:08:02 2009
From: report at bugs.python.org (lekma)
Date: Mon, 28 Dec 2009 14:08:02 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1262009282.82.0.503466723311.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

> Thanks for the patch! I rewrote the C function a bit to also take a dict
> argument, and added a test for that.  Committed in r77088.  Will merge
> to py3k.

Great!
Thanks to all for the help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:25:57 2009
From: report at bugs.python.org (Anurag)
Date: Mon, 28 Dec 2009 14:25:57 +0000
Subject: [issue7587] Python 3.1.1 source build issues
In-Reply-To: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>
Message-ID: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>


New submission from Anurag <anurag.sharma.101 at gmail.com>:

Hi

I downloaded the source for Python-3.1.1 for windows x86. I followed the
instructions in the PCbuild\Readme.txt file to build python

Basically, all I did was
1.	Open the ?PCbuild\pcbuild.sln? in VS2008.
2.	Select the ?Win32? as Solution Platform and ?Release? as Solution
Configuration
3.	Build Solution (F6)

I got the following error messages
Error      1              fatal error C1083: Cannot open source file:
'..\..\sqlite-3.5.9\sqlite3.c': No such file or directory   c1         
      sqlite3
Error      11           fatal error C1083: Cannot open include file:
'bzlib.h': No such file or directory      
Desktop\Python-3.1.1__\Python-3.1.1\Modules\bz2module.c     12           bz2
Error      12           fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory          
Desktop\Python-3.1.1__\Python-3.1.1\Modules\_tkinter.c           66    
      _tkinter
Error      13           fatal error C1083: Cannot open include file:
'tcl.h': No such file or directory          
Desktop\Python-3.1.1__\Python-3.1.1\Modules\tkappinit.c          16    
      _tkinter
Error      14           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      15           error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..."           _ssl        _ssl
Error      16           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      17           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      18           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      19           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      20           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      21           fatal error C1083: Cannot open include file:
'sqlite3.h': No such file or directory  
desktop\python-3.1.1__\python-3.1.1\modules\_sqlite\connection.h     33
          _sqlite3
Error      23           error PRJ0019: A tool returned an error code
from "Performing Pre-Build Event..."           _hashlib               
_hashlib



To fix the missing sqllite code issue, I did the following
1. I created a folder named "sqlite-3.5.9" under "Modules". 
2. I downloaded the code for sqlite-3.5.9 (This code is attached). 
3. I copied the downlaoded code for sqlite-3.5.9 under the following
directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\sqlite-3.5.9
4. From the newly copied files, I copied the "sqlite3.h" file to the
following folder
Desktop\Python-3.1.1\Python-3.1.1\Modules\_sqlite

After this I tried cleaned and build again.

Errors reduced. I got the following errors this time.

Error	1	fatal error C1083: Cannot open source file:
'..\..\sqlite-3.5.9\sqlite3.c': No such file or directory	c1	sqlite3
Error	2	fatal error C1083: Cannot open include file: 'bzlib.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\bz2module.c	12	bz2
Error	3	fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\_tkinter.c	66	_tkinter
Error	4	fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory
Desktop\Python-3.1.1\Python-3.1.1\Modules\tkappinit.c	16	_tkinter
Error	5	error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..."	_ssl	_ssl
Error	6	fatal error LNK1181: cannot open input file '.\sqlite3.lib'
_sqlite3	_sqlite3
Error	7	error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..."	_hashlib	_hashlib


Can someone help me fix these errors.

Thanks in advance


Thanks
Anurag

----------
components: Build
files: sqlite-source-3_5_9.zip
messages: 96947
nosy: sharmaag
severity: normal
status: open
title: Python 3.1.1 source build issues
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15683/sqlite-source-3_5_9.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7587>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:30:41 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 28 Dec 2009 14:30:41 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Sometime between Python 2.6 and 2.7a1, the
unittest.TestCase.shortDescription method changed from returning just
the test method name to the test method name, in parentheses, the fully
qualified Python name of the test case.

This breaks several Twisted unit tests and, I think, goes against the
expectations users have of the "shortDescription" method.

----------
components: Library (Lib)
messages: 96948
nosy: exarkun
severity: normal
status: open
title: unittest.TestCase.shortDescription isn't short anymore
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:41:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Dec 2009 14:41:39 +0000
Subject: [issue7587] Python 3.1.1 source build issues
In-Reply-To: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>
Message-ID: <1262011299.49.0.442691889462.issue7587@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The purpose of this bug tracker is not to obtain help, but to report
bugs etc.

See PCbuild/readme.txt for detailed instructions.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7587>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:45:03 2009
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Dec 2009 14:45:03 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1262011503.45.0.0717443014653.issue7579@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I fixed up the bodies of the docstrings, removed the weird quotes around
"pushed back" (copy/paste error), and got the heapmin/locking name fixed up.

Thanks for taking a look at this.

----------
Added file: http://bugs.python.org/file15684/msvcrt_docstrings_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:46:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Dec 2009 14:46:13 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262011573.92.0.909270519979.issue7588@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:49:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Dec 2009 14:49:46 +0000
Subject: [issue7587] Python 3.1.1 source build issues
In-Reply-To: <1262010357.46.0.74375888558.issue7587@psf.upfronthosting.co.za>
Message-ID: <1262011786.33.0.757534899713.issue7587@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To the poster's defense, the paragraph mentioning "external.bat" is
below the list of the external projects.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7587>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:56:19 2009
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Dec 2009 14:56:19 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262012179.81.0.39372301043.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

> Antoine Pitrou added the Comment:
>                                                                      
                                               
> I have trouble understanding what the patch does. I would expect it to
> cache the <original URL> -> <redirected URL> mapping, but it seems   
> cache the final HTTP response instead.

Oops. My mistake. I got carried away by my misunderstanding of the RFC
section on 301. The patch is wrong. I coded it to cache the response
from the redirection instead of just the redirected URL.
I shall write the correct one to cache just the redirection.           
                                               
                                                                       
                                               
> Aren't http_error_301 and friends for internal use?
                                                                       
      
Not really. They are exposed methods and I believe are being used by
clients. There have been bug reports related those redirection         
methods. Even the related Issue735515, explains pretty clearly about
the redirection required. (My bad again and my comment in that issue
is irrelevant.) In this issue, John says that there is no obvious need
to change the interface.  

RFC had a statement along the lines that "301 redirection is cached by
default, unless indicated otherwise". This is where I thought, an option
to turn-off the cacheable behavior might be needed.
                                                   
Thanks for looking at this quickly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755841>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:07:29 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Dec 2009 15:07:29 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262012849.05.0.431444026266.issue7588@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Personally I agree. I'll see if I can find the change (don't think it
was me) and see if there was some kind of rationale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:14:51 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Dec 2009 15:14:51 +0000
Subject: [issue7589] setup.py shouldn't try to build nis module when nis
	headers aren't available
In-Reply-To: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>
Message-ID: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

setup.py shouldn't try to build nis module when nis headers aren't
available (e.g. on uclibc systems). I'm attaching the patch for
setup.py.

----------
components: Build
files: python-nis.patch
keywords: patch
messages: 96954
nosy: Arfrever
severity: normal
status: open
title: setup.py shouldn't try to build nis module when nis headers aren't available
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15685/python-nis.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7589>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:19:08 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 28 Dec 2009 15:19:08 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1262013548.83.0.743166149617.issue7569@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

I don't want to judge if the best way to represent binary data in C is a
void* or char*, but there is a lot of C code out there that uses char*,
and if we want to interface with such a library we need to use
POINTER(c_char).

Note that my docpatch doesn't say anything about using void_p or not:
"For a general *character* pointer that may point to binary data,
POINTER(c_char) must be used". This refers only to char*, so if the C
code uses void* instead, we can of course also use c_void_p on the
Python side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:26:49 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Dec 2009 15:26:49 +0000
Subject: [issue7589] setup.py shouldn't try to build nis module when nis
	headers aren't available
In-Reply-To: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>
Message-ID: <1262014009.05.0.20035278077.issue7589@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7589>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:38:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 15:38:15 +0000
Subject: [issue735515] urllib / urllib2 should cache 301 redirections
Message-ID: <1262014695.5.0.650521735285.issue735515@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies:  -Patch for [ 735515 ] urllib2 should cache 301 redir
resolution:  -> duplicate
status: open -> closed
superseder:  -> Patch for [ 735515 ] urllib2 should cache 301 redir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue735515>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:40:16 2009
From: report at bugs.python.org (Salman Haq)
Date: Mon, 28 Dec 2009 15:40:16 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1262014816.38.0.211921650844.issue7559@psf.upfronthosting.co.za>


Salman Haq <salman.haq at gmail.com> added the comment:

I'm attaching a patch (against trunk) which I think is a step in the
right direction but I could use some feedback. 

This patch modifies 'loadTestsFromName()' so that it saves and re-raises
an ImportError.

Further this patch introduces a new unittest
(test_loadTestsFromName__badimport) and slightly modifies two existing
unittests (test_loadTestsFromName__unknown_attr_name,
test_loadTestsFromNames__unknown_attr_name) in test_unittest.py. Also, I
think a second new unittest is needed (test_loadTestsFromNames__badimport).

----------
keywords: +patch
Added file: http://bugs.python.org/file15686/issuee7559_trunk_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:05:21 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Dec 2009 16:05:21 +0000
Subject: [issue5969] setup build with Platform SDK, finding vcvarsall.bat
In-Reply-To: <1241791427.1.0.931613951559.issue5969@psf.upfronthosting.co.za>
Message-ID: <1262016321.29.0.905174925765.issue5969@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Duplicate of issue 7511.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5969>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:05:53 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Dec 2009 16:05:53 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1262016353.41.0.437099104138.issue6283@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Duplicate of issue 7511.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6283>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:29:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Dec 2009 16:29:22 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262017762.15.0.779144613866.issue1755841@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't reviewed the patch, but I would like the caching behavior to
be settable.  I can easily imagine a use case where I would not want the
URLs cached: when using urllib in a test suite or test tool.  (I just
ran into this problem trying to use firefox as a test tool...at the time
I was doing it I wasn't aware that firefox cached the 301 responses).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755841>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:23:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 17:23:07 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1262020987.21.0.204732228305.issue7569@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The suggestion looks good to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:38:56 2009
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Dec 2009 17:38:56 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262021936.97.0.957630270182.issue7585@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't think the conditional checks around the timestamps are
necessary. Couldn't you just put the \t directly in the string that gets
yielded? That way the chunk headers always follow the same format.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:59:45 2009
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Dec 2009 17:59:45 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262023185.97.0.186565971634.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Look at time.timezone -
http://docs.python.org/library/time.html#time.timezone

# I'm in US Central time, so it's -6 from UTC
>>> import time
>>> tz = time.timezone
>>> tz
21600
>>> tz / 60 / 60
6

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Mon Dec 28 19:56:41 2009
From: report at bugs.python.org (Greg)
Date: Mon, 28 Dec 2009 18:56:41 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262026601.28.0.75885704871.issue3972@psf.upfronthosting.co.za>


Greg <greg.hellings at gmail.com> added the comment:

Did this ever happen?  It seems like overkill in the non-Python sort of 
way to continue pointing people to over-riding classes and extending 
objects when such a small patch adds so powerful and useful a 
functionality to the library.

----------
nosy: +greg.hellings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 20:19:27 2009
From: report at bugs.python.org (honesthacker)
Date: Mon, 28 Dec 2009 19:19:27 +0000
Subject: [issue2204] document ConfigParser behaviour when a file has same
	section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1262027967.38.0.357425230755.issue2204@psf.upfronthosting.co.za>


Changes by honesthacker <justin at honesthacker.com>:


----------
nosy: +honesthacker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
_______________________________________

From report at bugs.python.org  Mon Dec 28 20:39:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Dec 2009 19:39:33 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262029173.92.0.338895875379.issue3972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since Gregory didn't update the ticket, it seems likely that it hasn't
happened yet.  If you'd care to try the patch and report on your
results, that would help the process.  We'll also need unit tests and
documentation updates, so patches for those would also speed the process.

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> test needed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 21:06:49 2009
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 28 Dec 2009 20:06:49 +0000
Subject: [issue7590] 'exceptions' module mentioned in documentation
In-Reply-To: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>
Message-ID: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

As I can see, 'exceptions' module does not exist in py3k.

But it is mentioned in documentation
http://docs.python.org/dev/py3k/library/exceptions.html
"The exceptions are defined in the module exceptions. This module never 
needs to be imported explicitly: the exceptions are provided in the 
built-in namespace as well as the exceptions module."

----------
assignee: georg.brandl
components: Documentation
messages: 96965
nosy: July, georg.brandl
severity: normal
status: open
title: 'exceptions' module mentioned in documentation
type: behavior
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7590>
_______________________________________

From report at bugs.python.org  Mon Dec 28 21:47:09 2009
From: report at bugs.python.org (Greg)
Date: Mon, 28 Dec 2009 20:47:09 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262033229.46.0.906919771444.issue3972@psf.upfronthosting.co.za>


Greg <greg.hellings at gmail.com> added the comment:

Just looking at the indicated file in the 2.6.4 release tarball, it does 
not seem that it would apply cleanly.  The line numbers do not apply 
properly anymore, though the edited lines themselves still appear to be 
unaffected.  Without context diff in the original patch, it's difficult 
for me to asseess exactly which lines should be the affected ones.

Unfortunately, I'm not in a position right now with my job to spend the 
time necessary to produce this as a patch since I'm on a timescale that 
requires equivalent functionality by Wednesday on production systems.  
Modifying it to apply cleanly to the latest versions of Python appears 
like it would be easy, if the internals of that file have not changed 
drastically in structure since 2.6.4.

Documentation should be relatively straightforward as well, since the 
functionality the patch introduces is rather transparent.  Unit tests 
are beyond my expertise to comment on.

Would have loved to have seen this in the 2.7/3.1 series, as it would 
make my task much easier!  I'll keep it in mind for my "off time" this 
holiday weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 21:56:28 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Dec 2009 20:56:28 +0000
Subject: [issue7006] The replacement suggested for callable(x) in py3k is
	not	equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1262033788.73.0.224075306247.issue7006@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77093.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:57:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 21:57:55 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262037475.64.0.945269989611.issue3972@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure why this is needed in httplib. Isn't it a matter of
configuring the machine's routing tables properly?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:00:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 22:00:46 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This started happening recently on some 3.1 buildbots:

======================================================================
FAIL: test_get_platform (distutils.tests.test_util.UtilTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/doko/buildarea/3.1.klose-debian-alpha/build/Lib/distutils/tests/test_util.py",
line 99, in test_get_platform
    self.assertEquals(get_platform(), 'macosx-10.3-i386')
AssertionError: 'macosx-10.3-x86_64' != 'macosx-10.3-i386'

----------------------------------------------------------------------

----------
assignee: tarek
components: Distutils, Tests
messages: 96969
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_get_platform fails on 3.1
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:02:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 22:02:28 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1262037748.67.0.635620416925.issue4758@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Python 3.0 internet documentation needs work -> Python 3.x internet documentation needs work

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:03:04 2009
From: report at bugs.python.org (Greg)
Date: Mon, 28 Dec 2009 22:03:04 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262037784.91.0.160529071411.issue3972@psf.upfronthosting.co.za>


Greg <greg.hellings at gmail.com> added the comment:

For my own case, I have a machine with 50 IP addresses set and I need to 
run a script to grab data that will randomly select one of those IP 
addresses to use for its outgoing connection.  That's something which 
needs to be selected at the socket level, as best I understand the issue, 
not on the routing end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:11:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 22:11:05 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1262037784.91.0.160529071411.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262038312.3366.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For my own case, I have a machine with 50 IP addresses set and I need to 
> run a script to grab data that will randomly select one of those IP 
> addresses to use for its outgoing connection.  That's something which 
> needs to be selected at the socket level, as best I understand the issue, 
> not on the routing end.

Why do you need to select manually between those 50 IP addresses?
Load-balancing? Fooling the remote server so that you don't get
blacklisted for opening too many connections?

The problem I see with adding this to httplib is that it's not
HTTP-specific. Other modules (smtplib etc.) might want to benefit,
depending on the use case.

By the way, what I mean by routing is your OS' internal routing table
for outbound packets. For example under Linux:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
X.Y.223.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
X.Y.222.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         X.Y.222.254     0.0.0.0         UG    100    0        0 eth0

The interface for each outbound route is part of the routing table.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:11:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Dec 2009 22:11:47 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261988054.75.0.159185771479.issue7578@psf.upfronthosting.co.za>
Message-ID: <1262038355.3366.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree; though I would wish for a bit finer-grained I/O related
> exceptions...

I agree with that. It probably needs someone to shepherd the idea to
python-dev so as to get it accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7578>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:23:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Dec 2009 22:23:34 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262039014.31.0.448762532716.issue3972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct that more than just httplib may need this; however, it
is a real need.  Consider for example a machine that has multiple IPs on
the same network (perhaps there used to be two machines but the services
were consolidated onto one or something), and some other server it talks
to is using IP based security in its .htaccess file.  So the client
machine needs to bind to the IP address that the server machine has
authorized to access the web service.  This is why, for example, the ssh
command has a '-b' option to specify the port to which the client binds.
 Or, for an even more apropos example, wget has a --bind-address option
for this reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:30:23 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Dec 2009 22:30:23 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262039423.1.0.734863001523.issue3972@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

In case it helps, a guy recently reported the same issue for pyftpdlib:
http://code.google.com/p/pyftpdlib/issues/detail?id=123

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:48:11 2009
From: report at bugs.python.org (Eldon Ziegler)
Date: Mon, 28 Dec 2009 22:48:11 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262040491.97.0.640851872039.issue3972@psf.upfronthosting.co.za>


Eldon Ziegler <eldonz at atlanticdb.com> added the comment:

The patch files for Python 2.6 and a test file are in the attached tar
file. Both httplib.py and socket.py need to be patched now.

httplib.HTTPConnection(host[, port[, strict[, timeout]]])

becomes

httplib.HTTPConnection(host[, port[, strict[, timeout[, bindip]]]])

and

httplib.HTTPSConnection(host[, port[, key_file[, cert_file[, strict[,
timeout]]]]])

becomes

httplib.HTTPSConnection(host[, port[, key_file[, cert_file[, strict[,
timeout[, bindip]]]]]])

----------
Added file: http://bugs.python.org/file15687/httplibmod2.6.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:19:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Dec 2009 23:19:32 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262042372.55.0.788138102111.issue3972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you want the maximum chance for this to get applied, it would be best
to have one or a set of patch files in 'svn diff' format against trunk
(see http://python.org/dev for information on how to produce such a
patch, specifically section 6.1 of the dev FAQ).  The tests will need to
be in unittest format (they would go in test_httplib and/or test_socket).

I imagine that writing the unittests so they will run on any machine
might be a tad tricky.  If I were doing it I'd try binding to 127.0.0.1
and checking to see that the socket is bound to that address rather than
0.0.0.0 in the binaddr case, and that it is bound to 0.0.0.0 in the
default case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:55:24 2009
From: report at bugs.python.org (Michael Newman)
Date: Mon, 28 Dec 2009 23:55:24 +0000
Subject: [issue7592] ssl module documentation: SSLSocket.unwrap description
	shown twice
In-Reply-To: <1262044524.74.0.400601888714.issue7592@psf.upfronthosting.co.za>
Message-ID: <1262044524.74.0.400601888714.issue7592@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

For the "ssl" module documentation at:
http://docs.python.org/3.1/library/ssl.html

I noticed that "SSLSocket.unwrap()" description is listed twice in the
"17.3.2. SSLSocket Objects" section.

----------
assignee: georg.brandl
components: Documentation
messages: 96977
nosy: georg.brandl, mnewman
severity: normal
status: open
title: ssl module documentation: SSLSocket.unwrap description shown twice
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7592>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:55:40 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Dec 2009 23:55:40 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262044540.99.0.0397490480772.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks! Now the most elegant patch I could think out.

----------
Added file: http://bugs.python.org/file15688/diff.py_iso_timestamps_true.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:30:11 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Dec 2009 00:30:11 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262046611.04.0.731857973211.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks cleaner and works for me.

One very minor comment: the spaces inside the parenthesis on the
time.localtime call are inconsistent and don't comply with PEP-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:34:04 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Dec 2009 00:34:04 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262046844.48.0.282331591254.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Conditional checks are required to prevent leaving trailing whitespace in 
filename when date component is not present. Such trailing whitespace may 
confuse patch tools. [1]

[1] http://code.google.com/p/python-patch/issues/detail?id=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:50:34 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Dec 2009 00:50:34 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262047834.5.0.116354696773.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Pepeighfied and regenerated. Should be flawless now.

----------
Added file: http://bugs.python.org/file15689/diff.py_iso_timestamps_true.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:50:41 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Dec 2009 00:50:41 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262047841.99.0.898739829201.issue7582@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Removed file: http://bugs.python.org/file15688/diff.py_iso_timestamps_true.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Tue Dec 29 02:14:44 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 29 Dec 2009 01:14:44 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262049284.82.0.0890953459944.issue3972@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

yes its a real need and yes we should support this in the standard 
library.  no i have not had time to look at it since my comment a 14 
months ago.

Thanks for the updated patch Eldon!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Tue Dec 29 02:49:28 2009
From: report at bugs.python.org (Shinnosuke)
Date: Tue, 29 Dec 2009 01:49:28 +0000
Subject: [issue210849] Fwd: Debian Bug#42318: urllib.py has problems with
	malformed proxy env. variables (PR#59)
Message-ID: <1262051368.46.0.20634826339.issue210849@psf.upfronthosting.co.za>


Shinnosuke <shinnosuke.goto at gmail.com> added the comment:

I found a solution of the same errors from Windows, and my solution was
removed the double quote at HTTP_PROXY settings.

----------
components: +Windows -Library (Lib)
nosy: +shinnosuke
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue210849>
_______________________________________

From report at bugs.python.org  Tue Dec 29 03:11:31 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 29 Dec 2009 02:11:31 +0000
Subject: [issue7593] Computed-goto patch
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

Part of Unladen Swallow's roadmap is to use a threaded-interpreter
technique for the regular expression engine.  That sounded like an
interesting idea, so I went ahead and tried to implement it.

The current patch is attached.  To try it: run configure
--with-computed-gotos; apply the patch; and compile Python.

Still to do:

* Benchmarking, to determine if it's actually an improvement.

* Possibly integrate construction of the Modules/re_opcodes.h file into
the build process.  The current file is supplied; to rebuild it, run
"python Modules/makereopcodes.py > Modules/re_opcodes.h". (But it only
needs rebuilding if you add new regex opcodes, which is rarely done --
maybe it's sufficient to include a reminder to update it plus the script).

----------
components: Regular Expressions
messages: 96984
nosy: akuchling
severity: normal
status: open
title: Computed-goto patch
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Tue Dec 29 03:12:06 2009
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 29 Dec 2009 02:12:06 +0000
Subject: [issue7593] Computed-goto patch
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262052726.69.0.743274074569.issue7593@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


Added file: http://bugs.python.org/file15690/re-computed-goto-v1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Tue Dec 29 03:15:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Dec 2009 02:15:57 +0000
Subject: [issue7593] Computed-goto patch
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262052957.11.0.832229610026.issue7593@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review, patch
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Tue Dec 29 04:27:22 2009
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 29 Dec 2009 03:27:22 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1262057242.13.0.814864368164.issue4758@psf.upfronthosting.co.za>


David M. Beazley <beazley at users.sourceforge.net> added the comment:

An apology on the delay.  Things have been rather hectic.

Regarding a patch, I don't really have a patch so much as a suggested 
procedure.   Basically, I'm suggesting that the maintainers of the 
library documentation simply do a quick survey of network related 
modules and make it clear that many of the operations work on "byte 
strings" and not "strings."     In Python 2.X, you could get away with 
being a little sloppy, but in Python 3, the bytes/strings distinction 
becomes much more prominent.

If I have time, I might be able to make a specific patch, but it 
probably wouldn't be until after PyCON sometime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:33:15 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Dec 2009 04:33:15 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262061195.05.0.657563582115.issue7585@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Shouldn't the patch tool handle that? FWIW, both the "svn diff" and *nix
diff utilities produce headers with the parts split by a tab character.

Would the code in example.py work in your tool to handle both tabs and
spaces?

----------
Added file: http://bugs.python.org/file15691/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:07:28 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Dec 2009 07:07:28 +0000
Subject: [issue7593] Computed-goto patch
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262070448.05.0.670499813654.issue7593@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:07:42 2009
From: report at bugs.python.org (Brian Harring)
Date: Tue, 29 Dec 2009 08:07:42 +0000
Subject: [issue7594] shlex refactoring
In-Reply-To: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
Message-ID: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>


New submission from Brian Harring <ferringb at gmail.com>:

Currently, shlex.shlex's internal read_token is a bit of a nasty mess to
follow and pretty poorly performant.

The refactoring I'll be attaching essentially inverts the state machine
approach read_token uses- instead, converting it over to a more
procedural set of loops.  The benefits of this is that it's far, far
easier to track what the code is actually doing and the performance goes
up fairly drastically via tightening the various for loops (for example,
if doing quoting, you only care about escapes and the terminating quote-
thus a loop there).

End result, the refactored code actually has whitespace in it and still
is shorter- specifically the tokenenizer was converted into a generator
to preserve state internally, thus simplifying the code flow immensely.

Beyond that, this should still be api compatible... and is 2x faster,
passing tests.

Note this patch is cut against 2.6.4; assuming folks are happy w/ the
general approach, I'll rebase it to py3k trunk.

>From there, I'd be willing to tackle the other shlex issues where
applicable, but personally... not w/out the refactoring base, since that
state machine is a pita to trace out.

----------
components: Library (Lib)
files: shlex-py2.6.4-20091229.patch
keywords: patch
messages: 96987
nosy: ferringb
severity: normal
status: open
title: shlex refactoring
type: performance
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15692/shlex-py2.6.4-20091229.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7594>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:39:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Dec 2009 08:39:21 +0000
Subject: [issue7594] shlex refactoring
In-Reply-To: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
Message-ID: <1262075961.51.0.424808488228.issue7594@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch.

Three minor things:
1) the source contains non-ASCII chars and an encoding declaration at
the beginning of the file. PEP8 says that "using \x, \u or \U escapes is
the preferred way to include non-ASCII data in string literals", so I
would use \x escapes and remove the encoding declaration;
2) the class "stream_source" should be named "StreamSource" unless there
are compatibility or consistency issues;
3) patches should be done against trunk first (your patch applies fine
on trunk too and the tests pass), they will then be ported to py3k.

----------
keywords: +needs review
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7594>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:28:52 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Dec 2009 10:28:52 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262082532.7.0.670083635923.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Filenames may contain spaces too.

--- handle dis Sun Dec 27 16:08:28 2009
--- ??? ??? ??? ???, ??? 27 16:08:28 2009

The last line is space separated filename and date in Russian locale. 
Patch tool should handle that, but as you may see it is not always 
possible. That's why difflib modification with \t separator will greatly 
improve interoperability of difflib patches regardless of timestamp 
format.

Stripping trailing whitespace when there is no timestamp serves the same 
purpose. We can assume that patch tools are perfect, but I wouldn't 
write my tool if that was true, so its better to be friendly on difflib 
side and generate the output that won't require more work than necessary 
to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:34:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Dec 2009 10:34:49 +0000
Subject: [issue7569] ctypes doc improvement: c_char_p
In-Reply-To: <1261595747.14.0.140020920323.issue7569@psf.upfronthosting.co.za>
Message-ID: <1262082889.23.0.0132525696709.issue7569@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, applied in r77108.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7569>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:35:10 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 29 Dec 2009 10:35:10 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1262082910.25.0.592187493292.issue3745@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

gregory - refer to setup.py logic to build modules

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:43:07 2009
From: report at bugs.python.org (lakshmipathi)
Date: Tue, 29 Dec 2009 10:43:07 +0000
Subject: [issue7572] Strabge issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1262083387.98.0.250044043296.issue7572@psf.upfronthosting.co.za>


lakshmipathi <lakshmipathi.g at gmail.com> added the comment:

ok..let me put this question ,in different manner.
Here is my code (example2)
------------------
import sqlite3
def loopy():
	return 'GNU'
#get connection object 
conn = sqlite3.connect("/tmp/example2")
#get curson obj. and invoke execute
cur = conn.cursor()
cur.execute('''create table stk (txt text)''')
#insert a single record
conn.create_function("loopy",0,loopy)
t=(loopy(),)
cur.execute("insert into stk values (?)",t)
#I have close it without committing. -So my record length == 0
cur.close()
#But when  i open again new cursor cur1
cur1=conn.cursor()
cur1.execute("select * from stk")
row = cur1.fetchall()
# i expect this assert to pass - since there is no record 
assert len(row) < 1

-------------------------------------------------------
I used sqlite3 /tmp/example2 and select * from stk returned zero records
as expected.
--------------------------
So commit refers to committing to Database not with in the program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:21:34 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 29 Dec 2009 11:21:34 +0000
Subject: [issue7572] Strange issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1262085694.3.0.539292368694.issue7572@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
title: Strabge issue : cursor.commit() with sqlite -> Strange issue : cursor.commit() with sqlite

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:27:48 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 29 Dec 2009 11:27:48 +0000
Subject: [issue7572] Strange issue : cursor.commit() with sqlite
In-Reply-To: <1261649918.23.0.144063644038.issue7572@psf.upfronthosting.co.za>
Message-ID: <1262086068.96.0.532527943283.issue7572@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

You confuse two things here: cursors and connections.

Indeed closing a connection without calling commit() on it will do an
implicit rollback, i. e. any changes on the database will not be persisted.

Closing cursors, however does nothing except invalidating the cursor
object for further usage. Cursors are basically only used for executing
SQL and looping over resultsets. You can reuse them or you can close
them and open new ones. But they have no relationship whatsoever with
transactions.

I hope this clears things up. I'm closing the issue now.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7572>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:03:59 2009
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 29 Dec 2009 12:03:59 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1262088239.21.0.91729152545.issue7566@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/issue7566>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:02:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Dec 2009 13:02:48 +0000
Subject: [issue7539] unicode exceptions terminate pdb.pm() loop
In-Reply-To: <1261137339.47.0.500431932871.issue7539@psf.upfronthosting.co.za>
Message-ID: <1262091768.51.0.975427614394.issue7539@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch, along with the test that I modified a little bit:
- it uses _saferepr (and repr.Repr) to render the exception object
- it also fixes exception raised by the "p" action.
- The test uses a raw docstring, to avoid chr(255) in the string

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file15693/pdb-unicode-exc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7539>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:37:15 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Dec 2009 13:37:15 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1261966434.75.0.443539224774.issue3745@psf.upfronthosting.co.za>
Message-ID: <4B3A0608.3050203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory P. Smith wrote:
> 
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> lemburg - see which issue #?

Sorry, the message got truncated for some reason.

I was referring to http://bugs.python.org/issue3745

This was discussed on python-dev: http://mail.python.org/pipermail/python-dev/2009-December/094593.html

> Anyways perhaps the right thing to do instead of trunk r65961 would have 
> been to change the s# to an s*.

That would have worked as well.

> Undoing it will be more painful now as several changes have gone in since 
> that require undoing and possibly redoing differently.

Using s* should pretty much avoid the need to use GET_BUFFER_VIEW_OR_ERROUT(),
so if you want to keep the other changes, removing the use of the
macro should be fairly straight-forward, unless I'm missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Tue Dec 29 16:28:06 2009
From: report at bugs.python.org (Chad Whitacre)
Date: Tue, 29 Dec 2009 15:28:06 +0000
Subject: [issue7595] Doc typo for select.kevent()
In-Reply-To: <1262100486.01.0.362584684262.issue7595@psf.upfronthosting.co.za>
Message-ID: <1262100486.01.0.362584684262.issue7595@psf.upfronthosting.co.za>


New submission from Chad Whitacre <chad at zetaweb.com>:

I believe the default "flags" argument to select.kevent() should be given 
as KQ_EV_ADD, not KQ_ADD.

http://docs.python.org/dev/py3k/library/select.html

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 96996
nosy: georg.brandl, whit537
severity: normal
status: open
title: Doc typo for select.kevent()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7595>
_______________________________________

From report at bugs.python.org  Tue Dec 29 17:41:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Dec 2009 16:41:48 +0000
Subject: [issue7548] If a generator raises TypeError when being unpacked,
	an unrelated error message is shown
In-Reply-To: <1261250773.36.0.925954913531.issue7548@psf.upfronthosting.co.za>
Message-ID: <1262104908.53.0.976112966442.issue7548@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of issue4806.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Function calls taking a generator as star argument can mask TypeErrors in the generator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7548>
_______________________________________

From report at bugs.python.org  Tue Dec 29 19:15:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Dec 2009 18:15:22 +0000
Subject: [issue5576] Don't use PyLong_SHIFT with _PyLong_AsScaledDouble()
In-Reply-To: <1238113402.96.0.541162373186.issue5576@psf.upfronthosting.co.za>
Message-ID: <1262110522.04.0.340155972192.issue5576@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Long double (80 bits) exponent is in range [-16382; 16383] and so 
would
> fits in an int, unsigned int, size_t or Py_ssize_t.

Sure, but I don't think that's relevant to the point I was attempting to 
make:  PyLong_AsScaledDouble returns the number of bits in the given 
PyLong, and that number can be (theoretically) as large as 
PY_SSIZE_T_MAX * PyLong_SHIFT.  So Py_ssize_t is a better fit than int 
to hold this number:  otherwise you'll get unnecessary overflows on a 
64-bit system.

I'm working on refactoring PyLong_AsScaledDouble and PyLong_AsDouble to 
have them both use the same core code.  This would make 
PyLong_AsScaledDouble correctly rounded, and hence independent of the 
implementation of a PyLong (in particular, independent of the decision 
to use 15-bit or 30-bit digits for PyLongs: this decision really 
shouldn't affect the result of a log function or any other functions 
using _PyLong_AsScaledDouble).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5576>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:10:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Dec 2009 19:10:57 +0000
Subject: [issue5576] Don't use PyLong_SHIFT with _PyLong_AsScaledDouble()
In-Reply-To: <1238113402.96.0.541162373186.issue5576@psf.upfronthosting.co.za>
Message-ID: <1262113857.69.0.978153966977.issue5576@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch:

 - rename _PyLong_AsScaledDouble to _PyLong_Frexp (for the benefit of
   anyone foolish enough to be using an undocumented private API
   function)
 - make the exponent type Py_ssize_t instead of int
 - do the scaling by PyLong_SHIFT in _PyLong_Frexp instead of in the
   functions that call it (e.g., loghelper in the math module)
 - remove longintrepr.h include from math module, since it's no longer
   needed
 - change _PyLong_Frexp algorithm to do correct rounding
 - refactor PyLong_Double to use _PyLong_Frexp.

----------
Added file: http://bugs.python.org/file15694/issue5576.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5576>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:18:23 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Dec 2009 19:18:23 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262114303.52.0.423546566369.issue7588@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It looks like this was changed in r70837

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________

From report at bugs.python.org  Tue Dec 29 21:40:49 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Dec 2009 20:40:49 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1262119249.21.0.402227503198.issue7561@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Having the ob_bytes field be NULL for a bytearray seems like a strange 
choice;  does anyone know why bytearray was designed this way?  Is it 
mainly for ease of combination with the stringlib library?

There does seem to be an awful lot of code that acts as though it 
expects x->ob_bytes to always be non-NULL for a valid PyByteArrayObject* 
x.  IMO, the use of pointer arithmetic with NULL pointers that Stefan 
pointed out should definitely be fixed.

The long_new problem looks like a trivial fix:  I'd fix it already, but 
given the number of other problems with this macro I'm not sure whether 
it should be fixed in Objects/longobject.c, or in the 
PyByteArray_AS_STRING macro itself.

I guess this is up to Georg and Benjamin, but I don't think 3.2 or 3.1.2 
should go out of the door with this bug present.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Tue Dec 29 21:53:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Dec 2009 20:53:56 +0000
Subject: [issue7575] tes_math fails Mac OS X 10.4 due to OverflowError in
	test_mtestfile
In-Reply-To: <1261670580.8.0.882101850319.issue7575@psf.upfronthosting.co.za>
Message-ID: <1262120036.61.0.590534901535.issue7575@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r77116 (trunk), r77117 (py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7575>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:07:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Dec 2009 21:07:12 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262120832.9.0.0870093146522.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This patch still(!) applies almost perfectly cleanly to trunk.  On a 64-
bit machine, I'm getting a failure in test_auto_overflow, coming from:

>>> pow(0L, 0, 9223372036854775807)
28051505152L

I haven't looked hard to figure out where this is coming from, but my 
guess is that the 15-bitness of digits is hard-coded in the patch 
somewhere.

My general feeling is that three-argument pow is such a little-used 
operation in Python that it's not worth the extra code to speed it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:09:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Dec 2009 21:09:24 +0000
Subject: [issue7595] Doc typo for select.kevent()
In-Reply-To: <1262100486.01.0.362584684262.issue7595@psf.upfronthosting.co.za>
Message-ID: <1262120964.44.0.0037068078594.issue7595@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed (in docs and docstring) in r77120.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7595>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:18:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Dec 2009 21:18:03 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_logging sometimes fails with the following error, e.g. on the
buildbots (*):

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/atexit.py",
line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/logging/__init__.py",
line 1556, in shutdown
    h.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Error in sys.exitfunc:
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/atexit.py",
line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File
"/home/buildbot/cpython-ucs4/trunk.pitrou-ubuntu-wide/build/Lib/logging/__init__.py",
line 1556, in shutdown
    h.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
[874213 refs]


(*)
http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20wide%20trunk/builds/185/steps/test/logs/stdio

----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 97005
nosy: pitrou, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_logging sometimes fails
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/issue7596>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:18:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Dec 2009 21:18:46 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262121526.75.0.884528294.issue7596@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also: 
http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20trunk/builds/182/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7596>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:23:23 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Dec 2009 21:23:23 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1262121803.95.0.93156225778.issue7588@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7588>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:23:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Dec 2009 21:23:31 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1262121811.94.0.751701210383.issue7579@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good, can someone with the ability to test it please commit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:25:32 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Dec 2009 21:25:32 +0000
Subject: [issue7590] 'exceptions' module mentioned in documentation
In-Reply-To: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>
Message-ID: <1262121932.88.0.78442495496.issue7590@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You're right, July, that the exceptions module does not exist in Python 3.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7590>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:41:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Dec 2009 21:41:27 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1262122887.29.0.597885958637.issue7033@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

lekma, this patch is now listed in the 2.7 "what's new" document as
contributed by "the lekma user", please tell us if you want your name there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Tue Dec 29 23:18:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Dec 2009 22:18:20 +0000
Subject: [issue7590] 'exceptions' module mentioned in documentation
In-Reply-To: <1262030809.1.0.0623559052096.issue7590@psf.upfronthosting.co.za>
Message-ID: <1262125100.03.0.816705477496.issue7590@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, should be fixed in r77121.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7590>
_______________________________________

From report at bugs.python.org  Tue Dec 29 23:41:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Dec 2009 22:41:46 +0000
Subject: [issue7413] datetime.datetime.isoformat truncation problem
In-Reply-To: <1259632981.58.0.493446472024.issue7413@psf.upfronthosting.co.za>
Message-ID: <1262126506.7.0.122523073324.issue7413@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r77122 (trunk) and r77125 (release26-maint).

py3k uses PyUnicode_FromFormat directly and does not have this problem.
I merged the test there nonetheless.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7413>
_______________________________________

From report at bugs.python.org  Wed Dec 30 00:34:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Dec 2009 23:34:46 +0000
Subject: [issue5420] Queue deprecation warning patch
In-Reply-To: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za>
Message-ID: <1262129686.68.0.72045643767.issue5420@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's too late now for deprecation in 3.2...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5420>
_______________________________________

From report at bugs.python.org  Wed Dec 30 00:36:16 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Dec 2009 23:36:16 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262129776.01.0.83589850476.issue7585@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I agree that splitting with a tab character is good, but I think it
should be split by a tab character in every case. 

If the separator is different based on what data is provided, then it
complicates parsing and would have to be explained in documentation that
we provide different header formats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Wed Dec 30 00:42:39 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Dec 2009 23:42:39 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1262130159.24.0.53359771157.issue7579@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r77126 in trunk.
I reflowed the text for getch(), so that help(msvcrt) displays nicely in a 
80-chars-wide console (this was my "test")

I was about to merge it into py3k, when I realized that the documentation 
should be updated to match the str/bytes distinction.
Can someone suggest a patch for py3k? (and for Doc/library/msvcrt.rst as 
well)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Wed Dec 30 01:14:31 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 30 Dec 2009 00:14:31 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1262132071.0.0.0722345548922.issue5116@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just noticed that this already exists in py3k, added in r57823 (lacks
docs but I'll cover them in the py3k fix for #7579)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5116>
_______________________________________

From report at bugs.python.org  Wed Dec 30 01:51:24 2009
From: report at bugs.python.org (Oki Mikito)
Date: Wed, 30 Dec 2009 00:51:24 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1262134284.32.0.867829049196.issue2259@psf.upfronthosting.co.za>


Oki Mikito <moki at maia.eonet.ne.jp> added the comment:

Hello,

My apology for failing to reply ... Here's a small AIFF file (24-bit, 
48000hz). Try this file to see if it can be opened using aifc. Thank you!

----------
Added file: http://bugs.python.org/file15695/24b48k.aif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Wed Dec 30 01:52:03 2009
From: report at bugs.python.org (Oki Mikito)
Date: Wed, 30 Dec 2009 00:52:03 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1262134323.57.0.406235531101.issue2259@psf.upfronthosting.co.za>


Changes by Oki Mikito <moki at maia.eonet.ne.jp>:


Removed file: http://bugs.python.org/file15695/24b48k.aif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Wed Dec 30 01:52:59 2009
From: report at bugs.python.org (Oki Mikito)
Date: Wed, 30 Dec 2009 00:52:59 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1262134379.62.0.461328737079.issue2259@psf.upfronthosting.co.za>


Oki Mikito <moki at maia.eonet.ne.jp> added the comment:

Hello,

My apology for failing to reply ... Here's a small AIFF file (24-bit, 
48000hz). Try this to see if it can be opened using aifc. Thank you!

----------
Added file: http://bugs.python.org/file15696/24b48k.aif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Wed Dec 30 01:57:30 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Dec 2009 00:57:30 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262134650.03.0.333517820752.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This patch makes sure filename and date split by tab in every case when 
date is provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Wed Dec 30 02:46:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 01:46:52 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1262137612.1.0.788921906441.issue6203@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Wed Dec 30 02:58:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 01:58:27 +0000
Subject: [issue4046] test_formatdate_usegmt fails on non-englisch locale
In-Reply-To: <1223210837.43.0.59197631848.issue4046@psf.upfronthosting.co.za>
Message-ID: <1262138307.34.0.948161684148.issue4046@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not able to reproduce this problem, and I would not expect to be
able to, since LANG should have no effect unless setlocale is called,
which the regression tests should not be doing without restoring it
afterward (and which the tests are not doing at all if you just run
test_email).

That said, I'm on linux, and issue 5125, which is also still open,
suggests this might be an OS X specific problem (maybe specific to
Apple's version of Python?).  Can you reproduce it with the python.org
version of 3.1?

----------
nosy: +r.david.murray, ronaldoussoren
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4046>
_______________________________________

From report at bugs.python.org  Wed Dec 30 03:32:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 02:32:51 +0000
Subject: [issue4491] email.Header.decode_header() doesn't work if encoded-word
	was separeted by CRLF
In-Reply-To: <1228234559.58.0.381415224429.issue4491@psf.upfronthosting.co.za>
Message-ID: <1262140371.58.0.396133135171.issue4491@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> decode_header does not follow RFC 2047

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4491>
_______________________________________

From report at bugs.python.org  Wed Dec 30 03:42:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 02:42:27 +0000
Subject: [issue4696] email module does not unfold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1262140947.46.0.961699897522.issue4696@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

While I agree with you, this represents a significant API change and so
is only going to be dealt with in the new version of the email package
(see http://wiki.python.org/moin/Email%20SIG)

----------
nosy: +r.david.murray
priority:  -> normal
title: email module does not fold headers -> email module does not unfold headers
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4696>
_______________________________________

From report at bugs.python.org  Wed Dec 30 03:59:10 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 02:59:10 +0000
Subject: [issue7589] setup.py shouldn't try to build nis module when nis
	headers aren't available
In-Reply-To: <1262013291.35.0.301750948413.issue7589@psf.upfronthosting.co.za>
Message-ID: <1262141950.89.0.167953701012.issue7589@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r77128.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7589>
_______________________________________

From report at bugs.python.org  Wed Dec 30 08:26:46 2009
From: report at bugs.python.org (lekma)
Date: Wed, 30 Dec 2009 07:26:46 +0000
Subject: [issue7033] C/API - Document exceptions
In-Reply-To: <1254482070.14.0.607686602716.issue7033@psf.upfronthosting.co.za>
Message-ID: <1262158006.77.0.300579017221.issue7033@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

> lekma, this patch is now listed in the 2.7 "what's new" document as
> contributed by "the lekma user", please tell us if you want your name
> there.

Nope, that's ok (it's perfect).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7033>
_______________________________________

From report at bugs.python.org  Wed Dec 30 09:21:25 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 08:21:25 +0000
Subject: [issue4770] binascii module, crazy error messages, unexpected behavior
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1262161285.0.0.034105328141.issue4770@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15560/issue4770_binascii_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Wed Dec 30 09:32:31 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 08:32:31 +0000
Subject: [issue4770] binascii module,
	inconsistent behavior: some functions accept unicode string input
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1262161951.45.0.663873775613.issue4770@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> patch review
title: binascii module, crazy error messages, unexpected behavior -> binascii module, inconsistent behavior: some functions accept unicode string input

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Wed Dec 30 10:46:22 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 09:46:22 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1262166382.78.0.696306215964.issue691291@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

slight update.

----------
stage:  -> patch review
type: feature request -> behavior
versions: +Python 2.7
Added file: http://bugs.python.org/file15697/issue691291_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue691291>
_______________________________________

From report at bugs.python.org  Wed Dec 30 10:48:24 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 09:48:24 +0000
Subject: [issue691291] codecs.open(filename, 'U', 'UTF-16') corrupts text
Message-ID: <1262166504.56.0.995343456179.issue691291@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15435/issue691291.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue691291>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:12:23 2009
From: report at bugs.python.org (Kan-Ru Chen)
Date: Wed, 30 Dec 2009 10:12:23 +0000
Subject: [issue7597] curses.use_env implementation error
In-Reply-To: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
Message-ID: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>


New submission from Kan-Ru Chen <kanru at kanru.info>:

According to doc: 
http://docs.python.org/library/curses.html#curses.use_env

curses.use_env() must be called before initscr(), curses man page also 
says so.

But python gives error: _curses.error: must call initscr() first

test.py is the test program, the output should change if your term 
size changed

test_ctypes.py shows the desired behavior.

ps. curses.COLS and curses.LINES doesn't change, but that's another 
story.

----------
components: Extension Modules
files: test.py
messages: 97024
nosy: kanru
severity: normal
status: open
title: curses.use_env implementation error
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15698/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7597>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:12:39 2009
From: report at bugs.python.org (Kan-Ru Chen)
Date: Wed, 30 Dec 2009 10:12:39 +0000
Subject: [issue7597] curses.use_env implementation error
In-Reply-To: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
Message-ID: <1262167959.56.0.889456694718.issue7597@psf.upfronthosting.co.za>


Changes by Kan-Ru Chen <kanru at kanru.info>:


Added file: http://bugs.python.org/file15699/test_ctypes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7597>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:12:52 2009
From: report at bugs.python.org (Kan-Ru Chen)
Date: Wed, 30 Dec 2009 10:12:52 +0000
Subject: [issue7597] curses.use_env implementation error
In-Reply-To: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
Message-ID: <1262167972.43.0.077547255585.issue7597@psf.upfronthosting.co.za>


Changes by Kan-Ru Chen <kanru at kanru.info>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15700/_curses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7597>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:38:50 2009
From: report at bugs.python.org (sh.00)
Date: Wed, 30 Dec 2009 10:38:50 +0000
Subject: [issue7598] Cannot install, problems with assembly?
In-Reply-To: <1262169529.95.0.0672707986414.issue7598@psf.upfronthosting.co.za>
Message-ID: <1262169529.95.0.0672707986414.issue7598@psf.upfronthosting.co.za>


New submission from sh.00 <sh96films at yahoo.it>:

When the installation is near the end, suddently I get the error message. 
Python is not the only program that cannot be installed correctly,and the 
error message is absolutely the same. Can anybody help me?

----------
files: SH_scr^001 Dec. 30 02.35.jpg
messages: 97025
nosy: sh.00
severity: normal
status: open
title: Cannot install, problems with assembly?
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15701/SH_scr^001 Dec. 30 02.35.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7598>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:41:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2009 10:41:52 +0000
Subject: [issue7598] Cannot install, problems with assembly?
In-Reply-To: <1262169529.95.0.0672707986414.issue7598@psf.upfronthosting.co.za>
Message-ID: <1262169712.03.0.0263952513309.issue7598@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #4735.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> An error occurred during the installation of assembly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7598>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:45:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2009 10:45:21 +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: <1262169921.09.0.990693058523.issue4735@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The same error has been reported in #7598 with Python 2.6.4.

----------
nosy: +ezio.melotti, sh.00
priority:  -> normal
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4735>
_______________________________________

From report at bugs.python.org  Wed Dec 30 13:13:16 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 12:13:16 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1262175196.0.0.78152224361.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in trunk in r77139.  I'll wait to check that the buildbots are 
happy, and then merge to py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Wed Dec 30 13:27:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 12:27:03 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1262176023.76.0.212116610639.issue7561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

IMO bytearray should be fixed, for everyone else's sanity.

----------
nosy: +benjamin.peterson, georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Wed Dec 30 13:40:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 12:40:10 +0000
Subject: [issue7597] curses.use_env implementation error
In-Reply-To: <1262167943.14.0.464762801223.issue7597@psf.upfronthosting.co.za>
Message-ID: <1262176810.14.0.862844641198.issue7597@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +akuchling
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7597>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:55:30 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2009 13:55:30 +0000
Subject: [issue5511] zipfile - add __exit__ attribute to make ZipFile object
	compatible with with_statement
In-Reply-To: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>
Message-ID: <1262181330.47.0.0801173652613.issue5511@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done in r77136 (trunk) and r77142 (py3k). Thanks for the patch!

----------
resolution: accepted -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5511>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:55:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 13:55:39 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262181339.1.0.593670059104.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like the test failure is a result of a misplaced (twodigits) cast:  replacing the line

   carry += (twodigits) ( (*aptr) + (u * (*mptr++)) );

in function mont_reduce with

   carry += *aptr + (twodigits)u * *mptr++;

fixes this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:01:35 2009
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 30 Dec 2009 14:01:35 +0000
Subject: [issue7599] (c)ElementTree can produce invalid XML
In-Reply-To: <1262181695.14.0.680778590248.issue7599@psf.upfronthosting.co.za>
Message-ID: <1262181695.14.0.680778590248.issue7599@psf.upfronthosting.co.za>


New submission from Jakub Wilk <ubanus at users.sf.net>:

$ cat buggy.py 
import sys
from xml.etree import ElementTree as et
root = et.Element('root')
root.text = u'\x07'
et.ElementTree(root).write(sys.stdout)

$ python buggy.py | xmllint -
-:1: parser error : PCDATA invalid Char value 7
<root></root>
      ^

----------
components: Library (Lib)
messages: 97032
nosy: jwilk
severity: normal
status: open
title: (c)ElementTree can produce invalid XML
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7599>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:39:36 2009
From: report at bugs.python.org (mhh91)
Date: Wed, 30 Dec 2009 14:39:36 +0000
Subject: [issue7600] interpreter crashes before start
In-Reply-To: <1262183976.04.0.961463499173.issue7600@psf.upfronthosting.co.za>
Message-ID: <1262183976.04.0.961463499173.issue7600@psf.upfronthosting.co.za>


New submission from mhh91 <mhh91 at hotmail.com>:

when I set my Locale to "Arabic(Egypt)" on Windows 7,Python does not
start,giving this Error :


Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

----------
components: Interpreter Core
messages: 97033
nosy: mhh91
severity: normal
status: open
title: interpreter crashes before start
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7600>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:52:06 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2009 14:52:06 +0000
Subject: =?utf-8?q?=5Bissue4328=5D_=22=C3=A0=22_in_u=22foo=22_raises_a_misleading_?=
	=?utf-8?q?error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1262184726.96.0.63646395515.issue4328@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:03:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 15:03:40 +0000
Subject: [issue7600] interpreter crashes before start
In-Reply-To: <1262183976.04.0.961463499173.issue7600@psf.upfronthosting.co.za>
Message-ID: <1262185420.43.0.282626565813.issue7600@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 1616979, which has been fixed.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> cp720 encoding map

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7600>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:33:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 15:33:13 +0000
Subject: =?utf-8?q?=5Bissue4328=5D_=22=C3=A0=22_in_u=22foo=22_raises_a_misleading_?=
	=?utf-8?q?error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1262187193.0.0.449402190912.issue4328@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, I've already fixed this for 2.7 (issue 1680159) by letting the
UnicodeDecodeError propagate upward.  I don't think making 'f' in u'foo'
an error would be a good idea.

Unless I'm mistaken the py3 behavior is correct.  If someone has a case
where the py3 message or behavior is incorrect they can reopen (or open
a new issue, since the cause is likely to be different if there is a
problem).

(Actually, the message you get when you do 'o' in b'foo' is...not
obvious; but as I said I think that's a different issue from this one.)

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Misleading exception from unicode.__contains__
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:48:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Dec 2009 15:48:22 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262188102.05.0.46031413436.issue7593@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
title: Computed-goto patch -> Computed-goto patch for RE engine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:55:23 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2009 15:55:23 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1262188523.63.0.532574691285.issue7487@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:19:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 16:19:50 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262189990.83.0.97693132776.issue7593@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/issue7593>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:22:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Dec 2009 16:22:12 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1262190132.82.0.260696124953.issue7487@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was caused by an old version of Pygments being used for building
the docs; I installed a new one in the external repo in r77144.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:24:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 16:24:18 +0000
Subject: [issue7534] float('nan')**2 != nan. float('nan')**2 error 33 on
	windows
In-Reply-To: <1261075376.97.0.838897228999.issue7534@psf.upfronthosting.co.za>
Message-ID: <1262190258.62.0.411784922724.issue7534@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k in r77146.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7534>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:36:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 16:36:49 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262191009.99.0.231958610495.issue7593@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On the principle nothing looks wrong. There are some tabs-vs-spaces
issues in _sre.c. Can some out-of-bounds crash be triggered if an opcode
is greater than 33?

It needs some benchmarks to know whether it's efficient. Also, I think
it would be nice to include regeneration of the opcode table in the
build process. Since it's very light-weight it can be done
unconditionally (I suppose it will be done from setup.py, right?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:38:59 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 16:38:59 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262191139.1.0.382685361437.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking a bit more at the patch:

+                /* miss: check if previous character is part of pattern */
+                if (!(mask & (1 << (s[i-1] & 0x1F))))

>From what I understand, this should be s[i-m]. Same here:

+                /* skip: check if previous character is part of pattern */
+                if (!(mask & (1 << (s[i-1] & 0x1F))))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:41:25 2009
From: report at bugs.python.org (=?utf-8?b?Sm96ZWYgR8OhYm9yw61r?=)
Date: Wed, 30 Dec 2009 16:41:25 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>


New submission from Jozef G?bor?k <jozef.gaborik at gmail.com>:

I installed python 3.1.1 on Ubuntu 9.10. When I wrote "make test" I got:

...
test_cmd
test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/
test_cmd_line.py", line 181, in test_large_PYTHONPATH
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True

test_cmd_line_script
...

AND:

...
test_xml_etree
test_xml_etree_c
test_xmlrpc
Traceback (most recent call last):
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/xmlrpc/server.py", 
line 448, in do_POST
    size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line 
281, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line 
307, in process_request
    self.finish_request(request, client_address)
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line 
320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/socketserver.py", line 
614, in __init__
    self.handle()
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line 
352, in handle
    self.handle_one_request()
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line 
346, in handle_one_request
    method()
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/xmlrpc/server.py", 
line 472, in do_POST
    self.send_header("X-traceback", traceback.format_exc())
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/http/server.py", line 
410, in send_header
    self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII', 
'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in 
position 78: ordinal not in range(128)
test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/test_xmlrpc.py", 
line 555, in test_fail_with_info
    p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:47884/RPC2: 
500 Internal Server Error>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gaborik/Stiahnut?/Python-3.1.1/Lib/test/test_xmlrpc.py", 
line 562, in test_fail_with_info
    self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True

test_xmlrpc_net
test_xmlrpc_net skipped -- Use of the `network' resource not enabled
test_zipfile
test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a 
long time to run
test_zipimport
test_zipimport_support
test_zlib
310 tests OK.
2 tests failed:
    test_cmd_line test_xmlrpc
23 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_kqueue
    test_nis test_normalization test_ossaudiodev test_pep277
    test_smtpnet test_socketserver test_startfile test_timeout test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
Those skips are all expected on linux2.

----------
components: Installation
messages: 97040
nosy: sadhak
severity: normal
status: open
title: Installation - 2 tests failed: test_cmd_line test_xmlrpc
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7601>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:49:34 2009
From: report at bugs.python.org (Martina Oefelein)
Date: Wed, 30 Dec 2009 16:49:34 +0000
Subject: [issue4046] test_formatdate_usegmt fails on non-englisch locale
In-Reply-To: <1223210837.43.0.59197631848.issue4046@psf.upfronthosting.co.za>
Message-ID: <1262191774.12.0.370986851391.issue4046@psf.upfronthosting.co.za>


Martina Oefelein <Martina at oefelein.de> added the comment:

Apple doesn't ship py3k yet. I observed the issue originally with my own build of 3.0 RC1 (No particular build settings 
were used, just ./configure ; make ; make test). It also happens with the build of Python 3.0.1 that is installed on my 
machine (this should be the official MacOS X build from Python.org), on MacOS X 10.6.2.

It doesn't happen with Python 3.1 anymore (and neither with 2.6.1 and 2.7 Alpha 1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4046>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:03:32 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Dec 2009 17:03:32 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262192612.81.0.281013906148.issue7601@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's certainly because python is installed in a directory with non-ascii
characters.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7601>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:07:39 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 17:07:39 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262192859.97.0.957619699546.issue7596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I can reproduce this on OS X 10.6 with:

./python.exe Lib/test/regrtest.py test_lib2to3 test_logging

The failure doesn't happen if I run these two tests in the opposite order.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7596>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:13:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 17:13:34 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262193214.62.0.530105414498.issue7596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r77106 seems to be the change that triggered this.  Benjamin, any ideas?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7596>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:17:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 17:17:43 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262192859.97.0.957619699546.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262193509.3331.8.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I can reproduce this on OS X 10.6 with:
> 
> ./python.exe Lib/test/regrtest.py test_lib2to3 test_logging

Same here!
The failure report in verbose mode is:

======================================================================
FAIL: test_filter (test.test_logging.BasicFilterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 290, in test_filter
    ('spam.eggs.fish', 'INFO', '3'),
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 114, in assert_log_lines
    self.assertEquals(len(actual_lines), len(expected_values))
AssertionError: 4 != 2

======================================================================
FAIL: test_handler_filter (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 390, in test_handler_filter
    ('Silent', '10'),
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 114, in assert_log_lines
    self.assertEquals(len(actual_lines), len(expected_values))
AssertionError: 10 != 5

======================================================================
FAIL: test_specific_filters (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 416, in test_specific_filters
    self.assert_log_lines(first_lines)
  File "/home/antoine/py3k/__svn__/Lib/test/test_logging.py", line 114, in assert_log_lines
    self.assertEquals(len(actual_lines), len(expected_values))
AssertionError: 10 != 9

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7596>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:26:18 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 17:26:18 +0000
Subject: [issue7602] Doc: make clean and make update do not delete or update
	Doc/tools
In-Reply-To: <1262193978.06.0.511943108668.issue7602@psf.upfronthosting.co.za>
Message-ID: <1262193978.06.0.511943108668.issue7602@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

In the Doc/ directory, the "make ..." commands do not behave as expected.

*make clean*
It should remove all tools in "tools" directory: docutils, jinja2,
pygments, sphinx.
Currently it removes only "tools/sphinx"

*make update*
It is supposed to "update the Subversion checkouts in `tools/`".
Basically, it does "svn update" for each 4 external tools.
But it is pointless, since these directory are sticked to tag versions.
IMHO, it should be an alias for:
"make clean && make checkout" (if *make clean* is fixed)

----------
assignee: georg.brandl
components: Build, Documentation
messages: 97046
nosy: flox, georg.brandl
severity: normal
status: open
title: Doc: make clean and make update do not delete or update Doc/tools
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/issue7602>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:34:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 30 Dec 2009 17:34:59 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1262194499.4.0.964427619212.issue7487@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thank you.

Doc/README.txt and Doc/make.bat need update too.


Note: issue7602 is a follow up regarding the *make clean* and *make
update* commands.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:33:36 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Dec 2009 18:33:36 +0000
Subject: [issue7487] doc: Code is not always colored
In-Reply-To: <1260650618.54.0.0150574477038.issue7487@psf.upfronthosting.co.za>
Message-ID: <1262198016.4.0.692165218432.issue7487@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r77151.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7487>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:36:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Dec 2009 18:36:18 +0000
Subject: [issue7602] Doc: make clean and make update do not delete or update
	Doc/tools
In-Reply-To: <1262193978.06.0.511943108668.issue7602@psf.upfronthosting.co.za>
Message-ID: <1262198178.48.0.443020462395.issue7602@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r77152.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7602>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:44:09 2009
From: report at bugs.python.org (Thomas Oldbury)
Date: Wed, 30 Dec 2009 18:44:09 +0000
Subject: [issue7603] There is no 'seq' type
In-Reply-To: <1262198649.61.0.804746779448.issue7603@psf.upfronthosting.co.za>
Message-ID: <1262198649.61.0.804746779448.issue7603@psf.upfronthosting.co.za>


New submission from Thomas Oldbury <thomas at tgohome.com>:

I find myself often writing the following code:

   if isinstance(var, (tuple, list, basestring)):

to determine if a var is indexable and iterable. 

It would be simpler if there were a 'seq' type which is subclassed into 
mutableseq and immutableseq (or something like that). Tuples and strings 
would be children of immutableseq. Lists would be children of 
mutableseq. Then I can do:

   if isinstance(var, seq):

Or to determine if I can edit values I can:

   if isinstance(var, mutableseq):

Actually this should probably not be a bug, maybe a PEP... or something.

This is the only thing I can presently think I would really like to 
correct in Python, because so far Python is the best language I've ever 
had the pleasure to write programs for. Thanks to everyone involved. :)

----------
messages: 97050
nosy: tom66
severity: normal
status: open
title: There is no 'seq' type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7603>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:46:49 2009
From: report at bugs.python.org (Brian Harring)
Date: Wed, 30 Dec 2009 18:46:49 +0000
Subject: [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
Message-ID: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>


New submission from Brian Harring <ferringb at gmail.com>:

Everything I've read about __slots__, seen w/ them, etc, they're
effectively just a change in the underlying allocation- yes they can
limit the attributes, but that's about it.

Specifically, for general attribute access/mangling, best I can tell,
they're *supposed* to be exactly equivalent when manipulating the
object- the only difference being the backing store.

That said, delattr against slotted objects vs non slotted differs in a
rather buggy way- even worse, the behaviour differs on slotted classes
dependant on if you're delattr'ing a slotted attr or a nonslotted-
consider the following code.

class nonslotted(object):
  pass

class slotted(object):
  __slots__ = ("monkeys",)

try:
  ns = nonslotted()
  assert not hasattr(ns, 'monkeys')
  del ns.monkeys
  raise AssertionError("this is unreachable")
except AttributeError:
  pass
try:
  s = slotted()
  assert not hasattr(s, 'monkeys')
  del s.monkeys
  print "slotting causes delattr to not throw an AttributeError"
  # and now for the kicker
  del s.some_attr_that_is_not_slotted
except AttributeError:
  print "so... delattr results in AttributeError on a non-slotted attr,
but throws no AttributeError on a slotted attr..."


I'm guessing this isn't intentional/desired?

Confirmed on py2.6/py3.1 also; that said, I'd assume it affects all
versions of python that support __slots__...

----------
components: Interpreter Core
messages: 97051
nosy: ferringb
severity: normal
status: open
title: delattr __slots__ inconsistancy
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:46:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 18:46:52 +0000
Subject: [issue7603] There is no 'seq' type
In-Reply-To: <1262198649.61.0.804746779448.issue7603@psf.upfronthosting.co.za>
Message-ID: <1262198812.04.0.306895008309.issue7603@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Take a swing by the abc module.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7603>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:47:22 2009
From: report at bugs.python.org (Brian Harring)
Date: Wed, 30 Dec 2009 18:47:22 +0000
Subject: [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
Message-ID: <1262198842.54.0.036166578648.issue7604@psf.upfronthosting.co.za>


Changes by Brian Harring <ferringb at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:54:27 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 30 Dec 2009 18:54:27 +0000
Subject: [issue6651] Py3k's posixpath.relpath not compatible with
	ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1262199267.21.0.767174228702.issue6651@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

How does this patch look? 

For the sake of consistency it changes back to start=curdir. Then, if
the `path` parameter is type bytes and the `start` parameter equals
`curdir`, `start` is set to the bytes version of `curdir`.

----------
keywords: +patch
nosy: +brian.curtin
type: performance -> behavior
versions:  -Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15702/issue6651.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6651>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:02:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2009 19:02:43 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262199763.41.0.954668388987.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a slightly modified version of Trevor's patch:

 - update to apply cleanly to trunk
 - fix misplaced twodigits cast described above
 - add 'PyLong_' prefix to BASE, MASK and SHIFT
 - no need for _PyLong_Copy in l_invmod:  just copy and INCREF the
   pointers
 - don't calculate d - q*c by hand in l_invmod, since l_divmod computes
   the remainder already
 - simplify reference counting in l_invmod
 - add a '* 1U' to a digit-by-digit multiplication, to avoid possible
   (in theory;  unlikely in practice) undefined behaviour resulting
   from signed integer overflow.

The rest of the patch looks fine to me, modulo some minor style issues.

Two points:

- it seems that l_invmod is only ever used to compute the inverse of a 
single-digit long modulo PyLong_BASE.  Mightn't it be more efficient to 
simply do a twodigit/digit-based calculation here instead, to reduce the 
overhead of setting up the Montgomery reductions?

- the current algorithm for three-argument pow involves many allocations 
and deallocations of integers;  it seems to me that these could almost 
all be eliminated:  for pow(a, b, c) with c an n-digit PyLong, just 
allocate 2*n (or possibly 2*n+1) digits of workspace to begin with and 
use that to store intermediate products;  the Montgomery reduction could 
then be done more-or-less in place.  This doesn't work with the non-
Montgomery method, though, since l_divmod doesn't operate in place.

----------
Added file: http://bugs.python.org/file15703/long_pow_2009_12_30.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:36:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 19:36:08 +0000
Subject: [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
Message-ID: <1262201768.73.0.818632422924.issue7604@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thank you for the report. Fixed in r77157.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:36:27 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Dec 2009 19:36:27 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1262201787.99.0.602225393657.issue4814@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:46:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 19:46:12 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262202372.59.0.699190534392.issue7596@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77158.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7596>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:55:06 2009
From: report at bugs.python.org (Brian Harring)
Date: Wed, 30 Dec 2009 19:55:06 +0000
Subject: [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262198809.47.0.401971406829.issue7604@psf.upfronthosting.co.za>
Message-ID: <1262202906.6.0.237122979927.issue7604@psf.upfronthosting.co.za>


Brian Harring <ferringb at gmail.com> added the comment:

Any chance of this landing in py2.7?  It's really a nasty wrench in the
works for some a mapping object essentially maps onto __slots__ for
memory efficiency...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:58:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 19:58:26 +0000
Subject: [issue7604] delattr __slots__ inconsistancy
In-Reply-To: <1262202906.6.0.237122979927.issue7604@psf.upfronthosting.co.za>
Message-ID: <1afaf6160912301158x4cb57484ga17e98ef6c198055@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/12/30 Brian Harring <report at bugs.python.org>:
>
> Brian Harring <ferringb at gmail.com> added the comment:
>
> Any chance of this landing in py2.7? ?It's really a nasty wrench in the
> works for some a mapping object essentially maps onto __slots__ for
> memory efficiency...

It will be in 2.6.5, 2.7, 3.1.2, and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7604>
_______________________________________

From report at bugs.python.org  Wed Dec 30 21:52:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 20:52:03 +0000
Subject: [issue4046] test_formatdate_usegmt fails on non-englisch locale
In-Reply-To: <1223210837.43.0.59197631848.issue4046@psf.upfronthosting.co.za>
Message-ID: <1262206323.35.0.706349771127.issue4046@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In that case, since 3.0 is no longer in maintenance, I'm closing this
bug as out of date.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4046>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:14:49 2009
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 30 Dec 2009 21:14:49 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1262207689.78.0.104539826211.issue7579@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch for py3k. It uses the same contents as before but with
changes to the str/bytes wording on getch_doc, putch_doc, and
ungetch_doc. Includes updates to the msvcrt.rst file. Let me know if the
wording seems correct (or if I left anything out).

I went ahead and added docstrings to the debug-only functions as a bonus.

----------
Added file: http://bugs.python.org/file15704/issue7579_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7579>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:33:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:33:49 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1262208829.85.0.770817151637.issue4814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks good, of course. Perhaps you want to add a test, if it isn't
too difficult to do so.

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:44:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:44:36 +0000
Subject: [issue7605] test_cmd_line fails with non-ascii path
In-Reply-To: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>
Message-ID: <1262209476.63.0.735770885688.issue7605@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I configured my buildbot to use a non-ascii path to the interpreter and
test_cmd_line fails as follows:

======================================================================
FAIL: test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_cmd_line.py",
line 181, in test_large_PYTHONPATH
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 97062
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_cmd_line fails with non-ascii path
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7605>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:46:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:46:36 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I configured my buildbot to use a non-ascii path to the interpreter and
test_xmlrpc fails as follows:

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59091)
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py",
line 448, in do_POST
    size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 281, in _handle_request_noblock
    self.process_request(request, client_address)
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 307, in process_request
    self.finish_request(request, client_address)
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/socketserver.py",
line 614, in __init__
    self.handle()
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 352, in handle
    self.handle_one_request()
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 346, in handle_one_request
    method()
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py",
line 472, in do_POST
    self.send_header("X-traceback", traceback.format_exc())
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/http/server.py",
line 410, in send_header
    self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII',
'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in
position 93: ordinal not in range(128)
----------------------------------------

======================================================================
FAIL: test_fail_with_info (test.test_xmlrpc.FailingServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_xmlrpc.py",
line 555, in test_fail_with_info
    p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:57828/RPC2:
500 Internal Server Error>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs4-nonascii-???/3.1.pitrou-ubuntu-wide/build/Lib/test/test_xmlrpc.py",
line 562, in test_fail_with_info
    self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 97063
nosy: loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_xmlrpc fails with non-ascii path
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:47:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 21:47:46 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262209666.07.0.815643449713.issue7591@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Wed Dec 30 23:03:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Dec 2009 22:03:06 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <4B3BCE18.9060902@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>     self.send_header("X-traceback", traceback.format_exc())

That's fairly tricky. send_header expects two strings (bytes are
not acceptable), and also requires these strings to be ASCII.
This is why it breaks: format_exc returns a non-ASCII string.

I see two options:
a) allow non-Unicode values for keyword and value in send_header,
   and have xmlrpc.server encode the header itself, or
b) properly MIME-encode value if it contains non-ASCII characters
   (keyword really must be ASCII, I think).

Not sure whether there is any precedence for UTF-8 in HTTP
headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Wed Dec 30 23:23:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 22:23:19 +0000
Subject: [issue7607] stringlib fastsearch could be improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The fastsearch algorithm uses a 32-bit mask for the boyer-moore
compression table but stores it as a long.
Since longs can be wider than 32 bits on some platforms (especially,
most 64-bit Unixes), the actual mask width could be platform-dependant
so as to improve the efficiency of the algorithm. Using the SIZEOF_LONG
constant would probably do the trick.

----------
components: Interpreter Core
messages: 97065
nosy: flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: stringlib fastsearch could be improved on 64-bit builds
type: performance
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7607>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:09:29 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:09:29 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1262214569.6.0.371048645588.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

It looks like that crash is caused by some bug in the implementation of
PyUnicode_FromFormat(). I rewrote my patch to avoid it and added some
additional unit tests.

----------
Added file: http://bugs.python.org/file15705/backport_dictviews-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:16:54 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:16:54 +0000
Subject: [issue7608] PyUnicode_FromFormatV handles %R and %S incorrectly.
In-Reply-To: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>
Message-ID: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

It seems PyUnicode_FromFormatV wrongly assumes that the return value of
PyObject_Str and PyObject_Repr is a unicode object. It looks like  the
%S and %R feature was backported from 3.x without updating the code for 2.x.


PyObject *
PyUnicode_FromFormatV(const char *format, va_list vargs)
{
...
            case 'S':
            {
                PyObject *obj = va_arg(count, PyObject *);
                PyObject *str;
                assert(obj);
                str = PyObject_Str(obj);
                if (!str)
                    goto fail;
                n += PyUnicode_GET_SIZE(str);
                /* Remember the str and switch to the next slot */
                *callresult++ = str;
                break;
            }
            case 'R':
            {
                PyObject *obj = va_arg(count, PyObject *);
                PyObject *repr;
                assert(obj);
                repr = PyObject_Repr(obj);
                if (!repr)
                    goto fail;
                n += PyUnicode_GET_SIZE(repr);
                /* Remember the repr and switch to the next slot */
                *callresult++ = repr;
                break;
            }
...
}

----------
components: Interpreter Core, Library (Lib)
messages: 97067
nosy: alexandre.vassalotti
severity: normal
stage: test needed
status: open
title: PyUnicode_FromFormatV handles %R and %S incorrectly.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7608>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:20:18 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:20:18 +0000
Subject: [issue7608] PyUnicode_FromFormatV handles %R and %S incorrectly.
In-Reply-To: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>
Message-ID: <1262215218.99.0.466385582874.issue7608@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> PyUnicode_FromFormat broken and not documented for 2.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7608>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:20:38 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:20:38 +0000
Subject: [issue7608] PyUnicode_FromFormatV handles %R and %S incorrectly.
In-Reply-To: <1262215014.59.0.531536027959.issue7608@psf.upfronthosting.co.za>
Message-ID: <1262215238.99.0.527160577647.issue7608@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
stage: test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7608>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:30:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Dec 2009 23:30:34 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262215834.16.0.930788579359.issue7606@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A little googling came up with this page:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc/am61_webseal_admin570.htm

Their solution is to uri encode the UTF8 encoded data.

However, this article references the RFCs, which look like they call for
rfc2047 (MIME) encoded words:

http://stackoverflow.com/questions/324470/http-headers-encoding-decoding-in-java

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:38:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Dec 2009 23:38:04 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262216284.33.0.767863126071.issue7606@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If it's only about transmitting the string representation of the
traceback, perhaps we can simply use "replace" or "ignore" as the error
handler?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:39:08 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 30 Dec 2009 23:39:08 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1262216348.83.0.639044992895.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The tests were missing in my last patch. So, here's a new one.

----------
Added file: http://bugs.python.org/file15706/backport_dictviews-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:49:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Dec 2009 23:49:25 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262216965.73.0.255021516016.issue7606@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

David: I think it's a little bit more complicated. RFC 2616 says that
the value of a header is *TEXT, which is defined as

   The TEXT rule is only used for descriptive field contents and values 
   that are not intended to be interpreted by the message parser. Words 
   of *TEXT MAY contain characters from character sets other than 
   ISO-8859-1 only when encoded according to the rules of RFC 2047

So I think send_header should change in the following way:

a) if isinstance(value, bytes): send value as-is
b) if value can be encoded in latin-1: encode in latin-1, then send as-is
c) otherwise: MIME-encode as UTF-8, using the following algorithm
   1. count the number of non-ascii characters, by encoding with
      ascii, ignore, and comparing result lengths
   2. if there are less than 10% non-ascii character, use the Q encoding
   3. otherwise, use the B encoding

The purpose of the algorithm in c) would be that text containing a few
non-latin characters still comes out right even if the receiver fails to
decode the header.

The same change would also apply to the client-side of sending headers.
On the receiving side, we should offer an option to decode headers (both
for client and server); this should be an option because senders may not
comply with RFC 2616. Reading should then proceed as follows:
1. check whether there are MIME markers in the text
2. if so, MIME-decode
3. if not, decode as latin-1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Thu Dec 31 00:51:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Dec 2009 23:51:07 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1262217067.03.0.516096452277.issue7606@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Antoine: sure, to fix the issue at hand, we can work-around.

However, the issue of sending non-ASCII headers in HTTP remains, and
should also be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Thu Dec 31 01:12:54 2009
From: report at bugs.python.org (Andrew Straw)
Date: Thu, 31 Dec 2009 00:12:54 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1262218374.52.0.570841435755.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

As of stdeb 0.5.0, the setuptools dependency has been removed. Now stdeb
requires only plain distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Thu Dec 31 02:25:04 2009
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 31 Dec 2009 01:25:04 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1262222704.36.0.908455820017.issue5115@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/issue5115>
_______________________________________

From report at bugs.python.org  Thu Dec 31 03:05:47 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 31 Dec 2009 02:05:47 +0000
Subject: [issue7609] Add --with-system-expat option
In-Reply-To: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
Message-ID: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

`configure` should support --with-system-expat option (similarly to --
internal copy of expat. It will be useful for some distributions (e.g.
Gentoo), which prefer to use system libraries instead internal copies.

----------
components: Build
files: python-system-expat.patch
keywords: patch
messages: 97074
nosy: Arfrever
severity: normal
status: open
title: Add --with-system-expat option
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15707/python-system-expat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________

From report at bugs.python.org  Thu Dec 31 03:09:17 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 31 Dec 2009 02:09:17 +0000
Subject: [issue7609] Add --with-system-expat option
In-Reply-To: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
Message-ID: <1262225357.89.0.190386587161.issue7609@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Some fragment of my initial comment disappeared :( .

This option will be similar to '--with-system-ffi' option.
It will cause using system expat instead of internal copy of expat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:17:37 2009
From: report at bugs.python.org (Kan-Ru Chen)
Date: Thu, 31 Dec 2009 03:17:37 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1262229457.31.0.503303731675.issue7089@psf.upfronthosting.co.za>


Changes by Kan-Ru Chen <kanru at kanru.info>:


----------
nosy: +kanru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:17:38 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Dec 2009 03:17:38 +0000
Subject: [issue7609] Add --with-system-expat option
In-Reply-To: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
Message-ID: <1262229458.23.0.432126238708.issue7609@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r77169.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:57:06 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 31 Dec 2009 03:57:06 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1262231826.41.0.52440075387.issue6687@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77174. Thank you for reviewing!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Thu Dec 31 05:13:42 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 04:13:42 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262232822.62.0.63861835055.issue7601@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/issue7601>
_______________________________________

From report at bugs.python.org  Thu Dec 31 05:26:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 04:26:53 +0000
Subject: [issue7596] test_logging sometimes fails
In-Reply-To: <1262121483.71.0.771852703011.issue7596@psf.upfronthosting.co.za>
Message-ID: <1262233613.75.0.427839354241.issue7596@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/issue7596>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:52:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 07:52:56 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262245976.04.0.270979374205.issue7601@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #7605 for test_cmd_line and #7606 for test_xmlrpc.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7601>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:00:04 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 08:00:04 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1262246404.45.0.553520432347.issue7089@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ferringb
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:03:35 2009
From: report at bugs.python.org (lucifer)
Date: Thu, 31 Dec 2009 08:03:35 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
Message-ID: <1262246615.05.0.213512245217.issue7610@psf.upfronthosting.co.za>


Changes by lucifer <luyuntao at yahoo.com.cn>:


----------
components: Extension Modules
nosy: lucifer
severity: normal
status: open
title: Cannot use both read and readline method in same ZipExtFile object
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:11:23 2009
From: report at bugs.python.org (lucifer)
Date: Thu, 31 Dec 2009 08:11:23 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>


New submission from lucifer <luyuntao at yahoo.com.cn>:

open a file in the zip file through ZipFile.open method, if invoke read 
method after readline method in the ZipExtFile object, the data is not 
correct.

I was trying to get a ZipExtFile and pass it to pickle.load(f), a 
exception was thrown.

The reason is readline will keep a linebuffer, but read only use 
readbuffer. After invoke readline, there will be some missing data in 
linebuffer when invoke read method

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:37:01 2009
From: report at bugs.python.org (Jan David Mol)
Date: Thu, 31 Dec 2009 08:37:01 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1262248621.89.0.184742501526.issue7089@psf.upfronthosting.co.za>


Jan David Mol <jjdmol at gmail.com> added the comment:

As there seems to be some interest, I've continued working on patching
this issue.

Attached is an improved version of the patch, including additions to
test_shlex.py. Improved in the sense that newlines after a comment are
not considered to be actually part of the comment (according to POSIX),
which makes a difference when newlines are tokens.

To accomplish this, I had to add an ungetc buffer to shlex, in order to
push back any newlines read by the readline() routine used when a
comment is encountered.

@Gabriel: the test case of no newline at the end of the file after a
comment is addressed.

Relevant POSIX sections are
Shell & Utilities 2.3(10)
Rationale C.2.3

----------
Added file: http://bugs.python.org/file15708/lexer-newline-tokens-patch-2.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7089>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:42:43 2009
From: report at bugs.python.org (Jan David Mol)
Date: Thu, 31 Dec 2009 08:42:43 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>


New submission from Jan David Mol <jjdmol at gmail.com>:

The shlex parser parses "foo#bar" as "foo", discarding the rest as a
comment. This is actually one of the test cases, even in POSIX mode.

However, POSIX (see below) only allows comments to start at the
beginning of a token, so "foo#bar" has to result in a "foo#bar" token.
To easily see this, do "echo foo#bar" in bash, versus "echo foo #bar".

Fixing this might break some applications that rely on this broken
behaviour, even though they're not strictly POSIX compliant.

POSIX 2008, Rationale C.2.3 (which refers to Shell & Utilities 2.3(10)):

The (10) rule about '#' as the current character is the first in the
sequence in which a new token is being assembled. The '#' starts a
comment only when it is at the beginning of a token. This rule is also
written to indicate that the search for the end-of-comment does not
consider escaped <newline> specially, so that a comment cannot be
continued to the next line.

----------
components: Library (Lib)
messages: 97081
nosy: jjdmol2
severity: normal
status: open
title: shlex not posix compliant when parsing "foo#bar"
type: behavior
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/issue7611>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:48:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 08:48:25 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1262249305.41.0.231444749681.issue7611@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ferringb
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:10:36 2009
From: report at bugs.python.org (Jan David Mol)
Date: Thu, 31 Dec 2009 09:10:36 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1262250636.68.0.794284185992.issue7611@psf.upfronthosting.co.za>


Jan David Mol <jjdmol at gmail.com> added the comment:

Attached a program which shows the relevant behaviour:

import shlex

tests = [ "foo#bar", "foo #bar" ]

for t in tests:
  print "%s -> %s" % (t,[x for x in shlex.shlex(t,posix=True)])

results in

$ python lexer_test.py
foo#bar -> ['foo']
foo #bar -> ['foo']

(expected of course is ['foo#bar'] on the first line).

----------
versions: +Python 2.5
Added file: http://bugs.python.org/file15709/lexer_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7611>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:51:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 31 Dec 2009 09:51:30 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262253090.97.0.669059040811.issue7591@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's related to Ronald last change. I am adding him in the loop

----------
assignee: tarek -> ronaldoussoren
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Thu Dec 31 11:03:46 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 31 Dec 2009 10:03:46 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262253826.13.0.505980552757.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I checked the code, and it is the right thing:

Example 1 (fastsearch):

s, p = "ABCDEABCF", "BCD"
s.rfind(p)

# i = 6  is first candidate, but "BCF" != "BCD"
# then s[i-1] = "A" is not part of pattern
# so we skip 3 chars: next loop is i = 2
# etc...


Example 2 (msg97039):

s, p = "ABCDBCBCF", "BCB"
s.rfind(p)

# i = 6  is first candidate, but "BCF" != "BCB"
# then s[i-m] = "D" is not part of pattern
# so we skip 3 chars: next loop is i = 2.. and it fails!

I've tested many examples to understand and verify the algorithm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Thu Dec 31 12:27:11 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 31 Dec 2009 11:27:11 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262258831.85.0.039907350109.issue7591@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I will look at this in the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:16:47 2009
From: report at bugs.python.org (Yitz Gale)
Date: Thu, 31 Dec 2009 12:16:47 +0000
Subject: [issue7612] Fix "pass and object" typo in Library Reference /
	Built-in Types / Sequence Types
In-Reply-To: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>
Message-ID: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>


New submission from Yitz Gale <gale at sefer.org>:

Change "if you pass and object of the wrong type"
to "if you pass an object of the wrong type"
in stdtypes.rst.

----------
assignee: georg.brandl
components: Documentation
files: typo_pass_and_object.patch
keywords: patch
messages: 97086
nosy: georg.brandl, ygale
severity: normal
status: open
title: Fix "pass and object" typo in Library Reference / Built-in Types / Sequence Types
versions: Python 3.1
Added file: http://bugs.python.org/file15710/typo_pass_and_object.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7612>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:25:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Dec 2009 12:25:16 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1262253826.13.0.505980552757.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262262365.3400.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I checked the code, and it is the right thing:

Indeed, you are right. My bad!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:27:09 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 12:27:09 +0000
Subject: [issue7612] Fix "pass and object" typo in Library Reference /
	Built-in Types / Sequence Types
In-Reply-To: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>
Message-ID: <1262262429.86.0.852714091945.issue7612@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77176 (py3k) and r77177 (release31-maint), thanks!

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7612>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:27:32 2009
From: report at bugs.python.org (Nir Aides)
Date: Thu, 31 Dec 2009 12:27:32 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262262452.71.0.994363935214.issue7610@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/issue7610>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:28:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 12:28:13 +0000
Subject: [issue7612] Fix "pass and object" typo in Library Reference /
	Built-in Types / Sequence Types
In-Reply-To: <1262261807.24.0.177394158823.issue7612@psf.upfronthosting.co.za>
Message-ID: <1262262493.32.0.827478183748.issue7612@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7612>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:29:22 2009
From: report at bugs.python.org (Shahar Or)
Date: Thu, 31 Dec 2009 12:29:22 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1262262563.0.0.375239706862.issue6135@psf.upfronthosting.co.za>


Changes by Shahar Or <email at shahar-or.co.il>:


----------
nosy: +DawnLight

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:29:38 2009
From: report at bugs.python.org (Shahar Or)
Date: Thu, 31 Dec 2009 12:29:38 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1262262578.74.0.569341879034.issue1759845@psf.upfronthosting.co.za>


Changes by Shahar Or <email at shahar-or.co.il>:


----------
nosy: +DawnLight

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:51:27 2009
From: report at bugs.python.org (Ettl Martin)
Date: Thu, 31 Dec 2009 12:51:27 +0000
Subject: [issue7613] [cppcheck] found a regression : Invalid number of
	character ((). Can't process file.
In-Reply-To: <1262263887.86.0.671145516418.issue7613@psf.upfronthosting.co.za>
Message-ID: <1262263887.86.0.671145516418.issue7613@psf.upfronthosting.co.za>


New submission from Ettl Martin <ettl.martin at gmx.de>:

during a check with the static code analysis tool cppcheck
(http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page)
the tool found a missing ')' in python-svn/Modules/flmodule.c that leads
to a regression.

Please refer the attached patch that fixes the issue.

Best regards

Ettl Martin

----------
components: None
files: regression1.patch
keywords: patch
messages: 97089
nosy: ettl.martin
severity: normal
status: open
title: [cppcheck] found a regression : Invalid number of character ((). Can't process file.
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15711/regression1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7613>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:58:15 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 31 Dec 2009 12:58:15 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1262264295.32.0.478693706994.issue6135@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

I agree with Florian Mayer that the encoding handling should be
stream-specific. You could easily be reading the stdout of some third
party program that uses, say, latin1, but want to do your own output in,
say, utf-8.

One solution that builds on what Amaury Forgeot d'Arc has done (i.e.,
the encoding and errors parameters) by allowing those parameters to
accept either a single string (as now), or a dict with keys 'stdin',
'stdout', 'stderr'. Of course it is possible that the client might not
specify all the dict's keys in which case those would use the normal
default (local 8-bit etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:03:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 31 Dec 2009 13:03:12 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262264592.16.0.452763305865.issue7591@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:16:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 31 Dec 2009 13:16:04 +0000
Subject: [issue7591] test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1262265364.92.0.180313088396.issue7591@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:30:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 31 Dec 2009 13:30:48 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1262266248.37.0.761556762982.issue6135@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't understand. How is the subprocess stdout related to the main
program output?
Stream-specific encoding could be useful for subprocesses that expect
latin-1 from stdin but write utf-8 to stdout. I'm not sure we should
support this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:43:19 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 31 Dec 2009 13:43:19 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1262266248.37.0.761556762982.issue6135@psf.upfronthosting.co.za>
Message-ID: <326c4f990912310543y3695747do7438786036010944@mail.gmail.com>


Mark Summerfield <mark at qtrac.eu> added the comment:

On Thu, Dec 31, 2009 at 1:30 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> I don't understand. How is the subprocess stdout related to the main
> program output?
> Stream-specific encoding could be useful for subprocesses that expect
> latin-1 from stdin but write utf-8 to stdout. I'm not sure we should
> support this.

Yes, you're right.

(What I had in mind was a scenario where you read one process's stdout
and wrote to another process's stdin; but of course using your errors
& encoding arguments this will work because there'll be two separate
process objects each of which can have its encoding and errors set
separately.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:53:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 13:53:41 +0000
Subject: [issue7613] [cppcheck] found a regression : Invalid number of
	character ((). Can't process file.
In-Reply-To: <1262263887.86.0.671145516418.issue7613@psf.upfronthosting.co.za>
Message-ID: <1262267621.61.0.679488677405.issue7613@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The regression has been introduced in r46534, it's now fixed in r77181
(trunk) and r77182 (release26-maint), thanks!

----------
assignee:  -> ezio.melotti
components: +Extension Modules -None
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7613>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:25:42 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 31 Dec 2009 14:25:42 +0000
Subject: [issue4814] ftplib does not honour "timeout" parameter for active
	data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1262269542.1.0.738880203371.issue4814@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

This time it's not easy as I see no way to distinguish whether the 
timeout exception gets raised by the command or the control socket, as 
makeport() method implementation deals with both:

<snippet>
        host = self.sock.getsockname()[0] 
        if self.af == socket.AF_INET:
            resp = self.sendport(host, port)  # socket.timeout can be 
raised here
        else:
            resp = self.sendeprt(host, port)   # ...here
        if self.timeout is not _GLOBAL_DEFAULT_TIMEOUT:
            sock.settimeout(self.timeout)    # or here
</snippet>

I think the best we can do is add a test which checks the timeout 
applied to the data socket resulting from a PASV/PORT request.
That doesn't cover this specific bug at all but it's something which is 
currently missing and that it would be nice to have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4814>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:51:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 31 Dec 2009 14:51:17 +0000
Subject: [issue7609] Add --with-system-expat option
In-Reply-To: <1262225147.39.0.152461484795.issue7609@psf.upfronthosting.co.za>
Message-ID: <1262271077.99.0.980298355045.issue7609@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The comment "Usage of a system shared libexpat.so/expat.dll is not
advised." just above the change should probably be revised.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:54:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 31 Dec 2009 14:54:17 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1262271257.67.0.953826184096.issue7593@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

_sre is listed in Modules/Setup, so it will be a built-in module by default.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Thu Dec 31 16:20:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 15:20:27 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262272827.64.0.843056495255.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a second revision of Trevor's patch:

 - factor out the code for creating Montgomery representatives;  this
   simplifies the changes to the main long_pow function
 - get rid of l_invmod and use a simple function for computing the
   negation of an inverse of a single digit modulo PyLong_BASE instead
 - Montgomery reduction wasn't being used for multidigit exponent b if
   the last digit of the exponent is small.  Fix this.
 - add 'static' qualifier to mont_reduce function
 - use type Py_ssize_t instead of int for digit indices in mont_reduce
 - various other unimportant style fixes

----------
Added file: http://bugs.python.org/file15712/long_pow_2009_12_31.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Thu Dec 31 16:26:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 15:26:36 +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: <1262273196.71.0.491546291603.issue2636@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 31 16:33:42 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 31 Dec 2009 15:33:42 +0000
Subject: [issue2100] unit test UnicodeWarning
In-Reply-To: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>
Message-ID: <1262273622.31.0.253319874493.issue2100@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing as "out of date".

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2100>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:28:43 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Dec 2009 16:28:43 +0000
Subject: [issue7609] Add --with-system-expat option
In-Reply-To: <1262271077.99.0.980298355045.issue7609@psf.upfronthosting.co.za>
Message-ID: <1afaf6160912310828n1bc492b8n7d9b1b4c3595048b@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/12/31 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> The comment "Usage of a system shared libexpat.so/expat.dll is not
> advised." just above the change should probably be revised.

Good point. Done in r77186.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7609>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:32:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 16:32:26 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262277146.81.0.779227874247.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some timings on my machine (OS X 10.6, 64-bit nondebug build, trunk r77157).  These are just 
doing an RSA-like powmod pow(c, d, n), with n the product of two similarly-sized primes, d the 
inverse of 7 modulo eulerPhi(n), and c of similar magnitude to n.

Without the patch:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe ../time_powmod.py
64-bit modulus: 0.000031
253-bit modulus: 0.000274
1023-bit modulus: 0.008032

With the patch:

Mark-Dickinsons-MacBook-Pro:trunk-issue936813 dickinsm$ ./python.exe ../time_powmod.py
64-bit modulus: 0.000025
253-bit modulus: 0.000209
1023-bit modulus: 0.006717

So I'm seeing a speedup of 20-30%.

I've attached the (rather primtive) timing script. Anyone else want to contribute timings?

----------
Added file: http://bugs.python.org/file15713/time_powmod.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:39:23 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 16:39:23 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262277563.71.0.115322069118.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  For smaller inputs, I'm actually getting significant slowdowns:

Unpatched:

>>> timeit('pow(123, 123456789, 123456789L)')
7.355183839797974

Patched:

>>> timeit('pow(123, 123456789, 123456789L)')
8.873976945877075

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:50:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Dec 2009 16:50:32 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262278232.07.0.614622598231.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I will take a last look at it and commit if I see nothing wrong.

----------
assignee:  -> pitrou
priority:  -> normal
stage: patch review -> commit review
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:59:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 16:59:40 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262278780.95.0.838927681538.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more lot of timings, from Trevor's pow_benchmark.txt:

Unpatched
---------
1024 bits: 0.008256
2048 bits: 0.052324
3072 bits: 0.159689
4096 bits: 0.357264

Patched (percent speedup)
-------
1024 bits: 0.006576  (+25.5%)
2048 bits: 0.045878  (+14.1%)
3072 bits: 0.135740  (+17.6%)
4096 bits: 0.310756  (+15.0%)

I'm not quite sure why I'm not seeing the same level of speedup that Trevor originally 
reported.  Perhaps this a result of some of the other optimizations that have been 
applied to the long implementation (30-bit digits, a reworked division algorithm), or 
perhaps the same level of speedup isn't available on 64-bit machines for some reason.  
I hope I haven't somehow negated the effects of the patch in my refactoring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Thu Dec 31 18:51:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Dec 2009 17:51:09 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262281869.94.0.925627607146.issue7462@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Are there any simple, common cases that are made slower by this patch? 
IIRC, that was the reason this wasn't implemented previously.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Thu Dec 31 18:57:59 2009
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 31 Dec 2009 17:57:59 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262282279.24.0.871269194403.issue7462@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The benchmark tests show significant improvements in most cases up to 10
times faster.

And I found no test case which show performance regression (using the
"stringbench" benchmark from GvR, and additional tests).

Moreover, the very same algorithm is already implemented for
find/index/partition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7462>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:04:55 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Thu, 31 Dec 2009 19:04:55 +0000
Subject: [issue7412] distutils install race condition
In-Reply-To: <1259571666.51.0.555227768726.issue7412@psf.upfronthosting.co.za>
Message-ID: <1262286295.46.0.820306560693.issue7412@psf.upfronthosting.co.za>


Rene Dudfield <illume at users.sourceforge.net> added the comment:

Hi Tarek,


moving a package into place right at the end is the best thing to do I
think.

It solves a couple common problems:
    - broken packages after an install is stopped half way for one of
many common reasons.
    - old files left around will not be there, since they would be
moved.  numpy 1.4 breaks for example if installing over an old version
first and not removing the old version.  So did pygame in the past...
and likely other packages.
    - race condition whilst installing (not so common, but happens).

I'm not sure I did say something like 'this race condition can happen
even if you copy the file in some temp dir, then move them to python.'.
 But now I see a problem... if the existing directory has files in it,
you can not move another directory over the top of it atomically.

I don't think there is a way to solve this completely, without changing
the packaging system quite dramatically.  However we can make it much
more likely we will win the race!!!  First trying to install into a temp
directory, then if on the same file system, moving the old directory to
a backup one, then moving the directory into place, finally removing the
old directory.

This would reduce the time of the race condition to a fraction of a
second(0.01 seconds on my box) compared to many seconds on average, and
longer for big packages with big files.

Packages not installing correctly is a big problem for C/C++ packages
more so than simply python packages.

Fixing this will mean distutils becomes more robust, and also will stop
a security issue.


I tried a method similar to this pseudo code as a work around:
python setup.py install --home=/tmp/apackagetmp
move temp package into place...

Here is a script I started on... for pygame installs on ubuntu karmic koala.
http://rene.f0o.com/~rene/stuff/safer_install.py

I thought I'd try it out as a separate thing first to try and get it
right before trying a patch with distutils.  There's still a bunch of
issues with it, and it needs tests written.
- when installing to a root place the permissions are not correct.  They
are the ones of the user it is ran as.  ie, 'chmod -R root:staff dest'
would probably fix it.
- it would be good to extract the paths for various things from
distutils... rather than guessing.  For example the dist-packages
directory, where the include files are etc etc.
- I'm going to put in a test step.  So it installs to the temp directory
first, then tries to run the package tests before installing.  The idea
being that if all the tests past *then* install.  This should make it
more robust still.  It will probably try as a separate process with
"python -m apackage.tests.__main__" or something like that.
- it always copies in all of the files.  Which is good and bad.  It
means that there won't be old files, but it also means that it can't
avoid work... like say only one file changes.
- probably many other issues...


cheers,

ps. happy new year!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7412>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:39:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 19:39:36 +0000
Subject: [issue936813] fast modular exponentiation
Message-ID: <1262288376.86.0.891609214377.issue936813@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, I retested the original patch without any of my refactoring (besides 
fixing the twodigits cast), and got pretty much the same numbers.

On a 32-bit non-debug trunk build (still on OS X 10.6), I get:

Unpatched
---------

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe 
../pow_benchmark.py 
1024 bits: 0.033691
2048 bits: 0.224796
3072 bits: 0.712510
4096 bits: 1.691484
Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe ../time_powmod.py
64-bit modulus: 0.000054
253-bit modulus: 0.000981
1023-bit modulus: 0.034314

Patched
-------

Mark-Dickinsons-MacBook-Pro:trunk-issue936813 dickinsm$ ./python.exe 
../pow_benchmark.py 
1024 bits: 0.027317  (+23.3%)
2048 bits: 0.181053  (+24.2%)
3072 bits: 0.571688  (+24.6%)
4096 bits: 1.251051  (+35.2%)
Mark-Dickinsons-MacBook-Pro:trunk-issue936813 dickinsm$ ./python.exe 
../time_powmod.py
64-bit modulus: 0.000045 (+20.0%)
253-bit modulus: 0.000773 (+26.9%)
1023-bit modulus: 0.026983 (+27.2%)

I must admit I was hoping for a bit more than this.  IMO, these speedups 
aren't big enough to justify the extra complexity for what's really a bit 
of a niche function, so I'm going to reject this 3rd part and close this 
issue (but marking it as 'accepted' because most of the original 2004 
patch went in).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue936813>
_______________________________________

From report at bugs.python.org  Thu Dec 31 22:33:14 2009
From: report at bugs.python.org (ttsiod)
Date: Thu, 31 Dec 2009 21:33:14 +0000
Subject: [issue7614] Python 2.6.4 segfaults
In-Reply-To: <1262295194.3.0.0100824369598.issue7614@psf.upfronthosting.co.za>
Message-ID: <1262295194.3.0.0100824369598.issue7614@psf.upfronthosting.co.za>


New submission from ttsiod <ttsiodras at gmail.com>:

I found a nice yield-based implementation of the sieve of Eratosthenes.

I tried to find the last prime number less than 1.000.000 (1M) - so I 
had to increase the recursion limit (via sys.setrecursionlimit).
It seemed to work - but after running for about 3 minutes, the
Python interpreter (2.6.4) crashed with a segmentation fault.

I am attaching the code - it uses no libraries except for "sys"
(it needs it to set the recursionlimit).

----------
components: None
files: sieve.py
messages: 97109
nosy: ttsiod
severity: normal
status: open
title: Python 2.6.4 segfaults
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15714/sieve.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7614>
_______________________________________

From report at bugs.python.org  Thu Dec 31 22:58:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2009 21:58:45 +0000
Subject: [issue7614] Python 2.6.4 segfaults
In-Reply-To: <1262295194.3.0.0100824369598.issue7614@psf.upfronthosting.co.za>
Message-ID: <1262296725.85.0.0261749345107.issue7614@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The recursion limit exists precisely so that Python can avoid overflowing 
the C stack and hence crashing.  So if you increase the recursion limit 
without also increasing the stack space assigned to the process, you 
should expect a crash.

Closing as won't fix.

----------
nosy: +mark.dickinson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7614>
_______________________________________