From report at bugs.python.org  Sun Mar  1 11:30:26 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2009 10:30:26 +0000
Subject: [New-bugs-announce] [issue5397] PEP 372:  OrderedDict
In-Reply-To: <1235903426.27.0.376128912816.issue5397@psf.upfronthosting.co.za>
Message-ID: <1235903426.27.0.376128912816.issue5397@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Here is a working patch implementing PEP372 ordered dictionaries.

----------
components: Library (Lib)
files: od.diff
keywords: patch
messages: 82955
nosy: rhettinger
severity: normal
stage: patch review
status: open
title: PEP 372:  OrderedDict
versions: Python 3.1
Added file: http://bugs.python.org/file13217/od.diff

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

From report at bugs.python.org  Sun Mar  1 13:40:02 2009
From: report at bugs.python.org (t.steinruecken)
Date: Sun, 01 Mar 2009 12:40:02 +0000
Subject: [New-bugs-announce] [issue5398] strftime("%B") returns a String
	unusable with unicode
In-Reply-To: <1235911202.21.0.141647308098.issue5398@psf.upfronthosting.co.za>
Message-ID: <1235911202.21.0.141647308098.issue5398@psf.upfronthosting.co.za>


New submission from t.steinruecken <t.steinruecken at service4every1.de>:

import locale
import datetime

locale.setlocale(locale.LC_ALL, ('de_DE', 'UTF8'))
print u""+datetime.datetime( 2009, 3, 1 ).strftime("%B")
--------------------------------------
Traceback (most recent call last):
    print u""+datetime.datetime( 2009, 3, 1 ).strftime("%B")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1:
ordinal not in range(128)

----------
messages: 82958
nosy: t.steinruecken
severity: normal
status: open
title: strftime("%B") returns a String unusable with unicode
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Mar  1 16:26:43 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 01 Mar 2009 15:26:43 +0000
Subject: [New-bugs-announce] [issue5399] wer
In-Reply-To: <1235921203.6.0.529176853043.issue5399@psf.upfronthosting.co.za>
Message-ID: <1235921203.6.0.529176853043.issue5399@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

234

----------
messages: 82965
nosy: ajaksu2
severity: normal
status: open
title: wer

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

From report at bugs.python.org  Sun Mar  1 23:07:20 2009
From: report at bugs.python.org (Piotr Meyer)
Date: Sun, 01 Mar 2009 22:07:20 +0000
Subject: [New-bugs-announce] [issue5400] patches for multiprocessing module
	on NetBSD
In-Reply-To: <1235945240.08.0.454455099363.issue5400@psf.upfronthosting.co.za>
Message-ID: <1235945240.08.0.454455099363.issue5400@psf.upfronthosting.co.za>


New submission from Piotr Meyer <aniou at smutek.pl>:

Multiprocessing module needs some patches to succesfully builing
and running on NetBSD. I made this patch and test on NetBSD 5rc2
(upcoming release).

1. we need working socket module (Modules/socketmodule.c)

2. mremap under NetBSD has different semantics:
   (Modules/mmapmodule.c)

3. finally, we need settings for netbsd in setup.py:
   (setup.py)  

After patching and building:

netbsd5#  ./python -bb -E Lib/test/regrtest.py test_multiprocessing
test_multiprocessing
1 test OK.

----------
components: Build
files: py-netbsd-multiprocessing.diff
keywords: patch
messages: 82991
nosy: aniou
severity: normal
status: open
title: patches for multiprocessing module on NetBSD
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file13224/py-netbsd-multiprocessing.diff

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

From report at bugs.python.org  Mon Mar  2 00:48:02 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 01 Mar 2009 23:48:02 +0000
Subject: [New-bugs-announce] [issue5401] mimetypes.MAGIC_FUNCTION
	implementation clusterfuck
In-Reply-To: <1235951282.21.0.0432661498186.issue5401@psf.upfronthosting.co.za>
Message-ID: <1235951282.21.0.0432661498186.issue5401@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Sorry for the harsh words, but when I found that code I nearly freaked
out.  For all those years I was using "from mimetypes import guess_type"
until today I found out that this has horrendous performance problems
due to the fact that the mimetype database is re-parsed on each call.

The reason for this is that mimetypes.guess_type is implemented like this:

def guess_type(...):
    global guess_type
    init()
    guess_type = new_guess_type
    return guess_type(...)

Obviously if the function was imported from the module and not looked up
via standard attribute lookup before each call (by calling it like
mimetypes.guess_type(...)) init() would be called over and over again.

What's the performance impact?  In a small WSGI middleware that serves
static files the *total* performance impact (including HTTP header
parsing, file serving etc.) was 1000%.  Just for guess_type() versus
mimetypes.guess_type() which was called just once per request.

I attached a workaround for that problem that tries to avoid init()
calls after the thing was initialized.

If this is intended behaviour it should be documented but I doubt that
this is a good idea as people don't read documentation it stuff seems to
work.

And google tells me I'm not the first one who invoked guess_type that
way: http://google.com/codesearch?q="from+mimetypes+import+guess_type"

----------
components: Library (Lib)
files: mimetypes-speedup.diff
keywords: easy, needs review, patch, patch
messages: 82992
nosy: aronacher
priority: critical
severity: normal
stage: patch review
status: open
title: mimetypes.MAGIC_FUNCTION implementation clusterfuck
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/file13225/mimetypes-speedup.diff

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

From report at bugs.python.org  Mon Mar  2 05:10:55 2009
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 02 Mar 2009 04:10:55 +0000
Subject: [New-bugs-announce] [issue5402] MutableMapping code smell (see
	OrderedDict)
In-Reply-To: <1235967055.01.0.234624648736.issue5402@psf.upfronthosting.co.za>
Message-ID: <1235967055.01.0.234624648736.issue5402@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at users.sourceforge.net>:

Copy of issue 5397

In python 3, UserDict (and DictMixin) are gone; presumably they should 
be replaced by either a dict subclass or the ABC MutableMapping.

Unfortunately, there doesn't seem to be a clean way to inherit from 
both.  

In python 2.x, you could write

  class MyDict(DictMixin, dict): ...

but with

  class MyDict(MutableMapping, dict): ...

MutableMapping explicitly overrides __getitem__, __setitem__, and 
__delitem__ to raise a KeyError.

The OrderedDict implementation in issue 5397 puts the concrete class 
first, and then handles composite methods manually, by either rewriting 
them (repr, copy) or explicitly delegating past dict and straight to 
MutableMapping (setdefault, update, etc.)

Both solutions seem fragile.  

Unfortunately, the closest I come to a solution is to split the ABC 
into a Mixin portion and an ABC enforcer.

    # The concrete methods of the current ABC
    class MapMixin: 

    # The abstract methods that get checked
    class MutableMapping(MapMixin):

# Trust that dict will always implement 
# all required concrete methods for us
class MyDict(MapMixin, dict):

----------
components: Library (Lib)
messages: 82999
nosy: aronacher, georg.brandl, jimjjewett, pitrou, rhettinger
severity: normal
status: open
title: MutableMapping code smell (see OrderedDict)
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar  2 06:46:08 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 02 Mar 2009 05:46:08 +0000
Subject: [New-bugs-announce] [issue5403] test_md5 segfault
In-Reply-To: <1235972768.83.0.536109179608.issue5403@psf.upfronthosting.co.za>
Message-ID: <1235972768.83.0.536109179608.issue5403@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed test_md5 and test_multiprocessing crashed on trunk. I hope
attached patch will fix this issue. (Maybe the patch can be simplified
with goto)

----------
components: Extension Modules
files: fix_md5_without_goto.patch
keywords: patch
messages: 83002
nosy: ocean-city
priority: release blocker
severity: normal
status: open
title: test_md5 segfault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file13226/fix_md5_without_goto.patch

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

From report at bugs.python.org  Mon Mar  2 10:03:49 2009
From: report at bugs.python.org (Joshua Kinard)
Date: Mon, 02 Mar 2009 09:03:49 +0000
Subject: [New-bugs-announce] [issue5404] Cross-compiling Python
In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za>
Message-ID: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za>


New submission from Joshua Kinard <kumba at gentoo.org>:

I'm attempting to get Python to cross-compile, and I'm not sure if this
is an actual flaw in the build system or not, but thought I'd detail
what I can here and seek comment from those in the know.

What happens is under a cross-environment setup on a Gentoo installation
(using our sys-devel/crossdev and sys-devel/crossdev-wrappers package),
when cross-compiling from x86_64-pc-linux-gnu to
mipsel-unknown-linux-gnu, the Python build process fails to build
several modules/extensions.

I believe that part of the problem with building the extensions is on
our end, and is a separate item I'll track down myself.  But there is
one module in particular that looks tied to Python's core that's getting
a cross-compile error: _socket.

What happens is, somehow, the configure script (or setup.py) is defining
HAVE_SYS_PARAM_H, which pulls in sys/param.h -- I think this is normal,
but for socketmodule.c, that particular call by the Makefile passes in
-I/usr/include along with the other -I calls defining the cross-include
directories.  The mipsel cross-compiler then references x86_64-specific
assembler code within the sys/param.h copy in /usr/include, and fails.

Generally, our crossdev-wrappers package sets up the buil environment
and overrides a lot of the common variables to use the cross-toolchain.
 So far, it looks like only socketmodule.c is affected with the rogue
-I/usr/include getting pulled in.  I haven't had much luck trying to
track down just how Python's build system is tied into autotools to see
where it's picking up /usr/include from.  Already tried patching
setup.py some, as well as passing --oldincludedir to configure, but
neither approach worked.

I'm hoping that this is either a minor bug in the build system, or we're
missing a specific variable to be passed to the make process so that
-I/usr/include doesn't get defined.  Not sure which, so if there's any
other ideas to try, I'm all ears!

----------
components: Build
messages: 83008
nosy: kumba
severity: normal
status: open
title: Cross-compiling Python
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Mon Mar  2 11:37:02 2009
From: report at bugs.python.org (Paul Moore)
Date: Mon, 02 Mar 2009 10:37:02 +0000
Subject: [New-bugs-announce] [issue5405] There is no way of determining
	which ABCs a class is registered against
In-Reply-To: <1235990222.31.0.178922023306.issue5405@psf.upfronthosting.co.za>
Message-ID: <1235990222.31.0.178922023306.issue5405@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

There is no way to determine the list of classes for which issubclass(C,
x) is true. The MRO of the class is fine for normal inheritance, but for
ABCs it is possible to register classes which don't inherit from the
ABC, so that you have a situation where issubclass (C, MyABC) can be
true without MyABC being in C.__mro__:

>>> import abc
>>> class MyABC(object):
...     __metaclass__ = abc.ABCMeta
...
>>> class C(object):
...     pass
...
>>> MyABC.register(C)
>>> issubclass(C, MyABC)
True
>>> C.__mro__
(<class '__main__.C'>, <type 'object'>)
>>>

This means that ABCs do not play well with the type of introspection
required to implement such features as generic functions - namely
enumeration of the (logical) superclasses of a class.

----------
components: Interpreter Core
messages: 83011
nosy: pmoore
priority: normal
severity: normal
status: open
title: There is no way of determining which ABCs a class is registered against
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Mar  2 19:46:29 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 02 Mar 2009 18:46:29 +0000
Subject: [New-bugs-announce] [issue5406] asyncore  doc issue
In-Reply-To: <1236019589.34.0.225430476333.issue5406@psf.upfronthosting.co.za>
Message-ID: <1236019589.34.0.225430476333.issue5406@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

About asyncore.loop()'s count parameter:

> The count parameter defaults to None, resulting in the loop 
> terminating only when all channels have been closed

This is incorrect and it's not what count parameter actually does.
I'd come up with a patch but I'm sure a native English speaker can do a
lot better than me.

----------
messages: 83033
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asyncore  doc issue
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  2 23:08:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Mar 2009 22:08:24 +0000
Subject: [New-bugs-announce] [issue5407] Broken Py3.1 release build in
	Visual Studio 2005
In-Reply-To: <1236031704.37.0.216105327736.issue5407@psf.upfronthosting.co.za>
Message-ID: <1236031704.37.0.216105327736.issue5407@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The build crashes and it seems related to io.py.  This started about two
weeks ago.  Before that, it built fine.


------ Build started: Project: _ssl, Configuration: Release Win32 ------
Performing Pre-Build Event...
Traceback (most recent call last):
  File "C:\py31\lib\io.py", line 222, in open
  File "C:\py31\lib\io.py", line 619, in __init__
OSError: [Errno 9] Bad file descriptor
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Project : error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..."
Build log was saved at
"file://C:\py31\PC\VS8.0\Win32-temp-Release\_ssl\BuildLog.htm"
_ssl - 1 error(s), 0 warning(s)
------ Skipped Build: Project: bdist_wininst, Configuration: Release
Win32 ------
Project not selected to build for this solution configuration 
------ Build started: Project: _hashlib, Configuration: Release Win32 ------
Performing Pre-Build Event...
Traceback (most recent call last):
  File "C:\py31\lib\io.py", line 222, in open
  File "C:\py31\lib\io.py", line 619, in __init__
OSError: [Errno 9] Bad file descriptor
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Project : error PRJ0019: A tool returned an error code from "Performing
Pre-Build Event..."
Build log was saved at
"file://C:\py31\PC\VS8.0\Win32-temp-Release\_hashlib\BuildLog.htm"
_hashlib - 1 error(s), 0 warning(s)

----------
assignee: pitrou
components: Library (Lib)
messages: 83042
nosy: pitrou, rhettinger
severity: normal
status: open
title: Broken Py3.1 release build in Visual Studio 2005
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  3 00:17:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Mar 2009 23:17:06 +0000
Subject: [New-bugs-announce] [issue5408] test_osx_env failing
In-Reply-To: <1236035826.81.0.76995170361.issue5408@psf.upfronthosting.co.za>
Message-ID: <1236035826.81.0.76995170361.issue5408@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Mac OS 10.4 PPC debug build

test_osx_env
[31492 refs]
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8
test test_osx_env failed -- Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_osx_env.py", line 27, in
test_pythonexecutable_sets_sys_executable
    self._check_sys('PYTHONEXECUTABLE', '==', 'sys.executable')
  File "/temp/python/py3k/Lib/test/test_osx_env.py", line 24, in _check_sys
    self.assertEqual(rc, 2, "expected %s %s %s" % (ev, cond, sv))
AssertionError: expected PYTHONEXECUTABLE == sys.executable

----------
assignee: ronaldoussoren
components: Tests
messages: 83046
nosy: benjamin.peterson, ronaldoussoren
severity: normal
status: open
title: test_osx_env failing
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  3 06:37:13 2009
From: report at bugs.python.org (Sylvain Rabot)
Date: Tue, 03 Mar 2009 05:37:13 +0000
Subject: [New-bugs-announce] [issue5409] ConfigParser get<int/float/boolean>
	methods broken
In-Reply-To: <1236058633.76.0.532067455493.issue5409@psf.upfronthosting.co.za>
Message-ID: <1236058633.76.0.532067455493.issue5409@psf.upfronthosting.co.za>


New submission from Sylvain Rabot <nihil.is at free.fr>:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.

    ****************************************************************
    Personal firewall software may warn about the connection IDLE
    makes to its subprocess using this computer's internal loopback
    interface.  This connection is not visible on any external
    interface and no data is sent to or received from the Internet.
    ****************************************************************
    
IDLE 3.0      
>>> from configparser import ConfigParser
>>> config = ConfigParser()
>>> config.add_section("popo")
>>> config.set("popo", "int", 123)
>>> config.getint("popo", "int")
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    config.getint("popo", "int")
  File "c:\Python30\lib\configparser.py", line 340, in getint
    return self._get(section, int, option)
  File "c:\Python30\lib\configparser.py", line 337, in _get
    return conv(self.get(section, option))
  File "c:\Python30\lib\configparser.py", line 545, in get
    return self._interpolate(section, option, value, d)
  File "c:\Python30\lib\configparser.py", line 585, in _interpolate
    if "%(" in value:
TypeError: argument of type 'int' is not iterable
>>> config.set("popo", "bool", True)
>>> config.getboolean("popo", "bool")
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    config.getboolean("popo", "bool")
  File "c:\Python30\lib\configparser.py", line 349, in getboolean
    v = self.get(section, option)
  File "c:\Python30\lib\configparser.py", line 545, in get
    return self._interpolate(section, option, value, d)
  File "c:\Python30\lib\configparser.py", line 585, in _interpolate
    if "%(" in value:
TypeError: argument of type 'bool' is not iterable
>>> config.set("popo", "float", 3.21)
>>> config.getfloat("popo", "float")
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    config.getfloat("popo", "float")
  File "c:\Python30\lib\configparser.py", line 343, in getfloat
    return self._get(section, float, option)
  File "c:\Python30\lib\configparser.py", line 337, in _get
    return conv(self.get(section, option))
  File "c:\Python30\lib\configparser.py", line 545, in get
    return self._interpolate(section, option, value, d)
  File "c:\Python30\lib\configparser.py", line 585, in _interpolate
    if "%(" in value:
TypeError: argument of type 'float' is not iterable

Same things with python 2.6

----------
components: Library (Lib)
messages: 83055
nosy: Absynthe
severity: normal
status: open
title: ConfigParser get<int/float/boolean> methods broken
type: crash
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Mar  3 12:56:15 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 03 Mar 2009 11:56:15 +0000
Subject: [New-bugs-announce] [issue5410] msvcrt bytes cleanup
In-Reply-To: <1236081375.11.0.544682804494.issue5410@psf.upfronthosting.co.za>
Message-ID: <1236081375.11.0.544682804494.issue5410@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I came from issue5391. Here is quote of Victor's message.

>* msvcrt.putch(char), msvcrt.ungetch(char): msvcrt has also:
>  - msvcrt.getch()->byte string of 1 byte
>  - msvcrt.getwch()->unicode string of 1 character
>  - msvcrt.putwch(unicode string of 1 character)
>  - msvcrt_ungetwch(unicode string of 1 character)
>  Hum, putch(), ungetch(), getch() use inconsistent types 
>(unicode/bytes) and should be fixed. Another issue should be open for 
>that.
>
>Notes: msvcrt.putwch() accepts string of length > 1 and 
>msvcrt.ungetwch() doesn't check string length (and so may crash with 
>length=0 or length > 1?).

And msvcrt.ungetwch() calls _ungetch not _ungetwch. Here is the patch
hopefully fixing these issue. (I cannot test wide version of functions
because VC6 don't have them)

----------
components: Extension Modules, Windows
files: py3k_fix_msvcrt.patch
keywords: patch
messages: 83071
nosy: ocean-city
severity: normal
status: open
title: msvcrt bytes cleanup
versions: Python 3.1
Added file: http://bugs.python.org/file13233/py3k_fix_msvcrt.patch

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

From report at bugs.python.org  Tue Mar  3 12:56:26 2009
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 03 Mar 2009 11:56:26 +0000
Subject: [New-bugs-announce] [issue5411] add xz compression support to
	distutils
In-Reply-To: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>
Message-ID: <1236081386.1.0.884971889723.issue5411@psf.upfronthosting.co.za>


New submission from Per ?yvind Karlsen <peroyvind at mandriva.org>:

Here's a patch that adds support for xz compression:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/python/current/SOURCES/Python-2.6.1-distutils-xz-support.patch?view=log

----------
assignee: tarek
components: Distutils
messages: 83072
nosy: proyvind, tarek
severity: normal
status: open
title: add xz compression support to distutils
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar  3 16:14:36 2009
From: report at bugs.python.org (Jeff Kaufman)
Date: Tue, 03 Mar 2009 15:14:36 +0000
Subject: [New-bugs-announce] [issue5412] extend configparser to support []
	syntax
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>


New submission from Jeff Kaufman <jkaufman at bbn.com>:

This is a patch against the configparser in the cvs version of 3.1 to
support [] notation:

>>> import configparser_patched
>>> config = configparser_patched.SafeConfigParser()
>>> config.add_section("spam")
>>> config["spam", "eggs"] = "yummy"
>>> config["spam", "eggs"]
'yummy'
>>> del config["spam", "eggs"]
>>> 

The functions are just syntactic sugar for the simple forms of "get",
"set", and "remove_option".

----------
components: Library (Lib)
files: configparser.patch
keywords: patch
messages: 83075
nosy: jkaufman
severity: normal
status: open
title: extend configparser to support [] syntax
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13234/configparser.patch

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

From report at bugs.python.org  Wed Mar  4 00:55:44 2009
From: report at bugs.python.org (Attila Soki)
Date: Tue, 03 Mar 2009 23:55:44 +0000
Subject: [New-bugs-announce] [issue5413] urllib ctypes error on Mac OS X
	Server 10.5
In-Reply-To: <1236124544.96.0.577290884621.issue5413@psf.upfronthosting.co.za>
Message-ID: <1236124544.96.0.577290884621.issue5413@psf.upfronthosting.co.za>


New submission from Attila Soki <atiware at gmx.net>:

i trying to compile Python 2.6.1 from scratch on Mac OS X Server (ppc).
After configure/make/make install i test the compiled python with
the followig file (t.py) (example from
http://docs.python.org/library/urllib.html):


Contents of /tmp/t.py:
-------------
import urllib
params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
f = urllib.urlopen("http://www.musi-cal.com/cgi-bin/query", params)
print f.read()
-------------

and i get this error:

python /tmp/t.py 
Traceback (most recent call last):
  File "/tmp/t.py", line 3, in <module>
    f = urllib.urlopen("http://www.musi-cal.com/cgi-bin/query", params)
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 82, in urlopen
    opener = FancyURLopener()
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 611, in
__init__
    URLopener.__init__(self, *args, **kwargs)
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 129, in
__init__
    proxies = getproxies()
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 1555, in
getproxies
    return getproxies_environment() or getproxies_macosx_sysconf()
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 1449, in
getproxies_macosx_sysconf
    _CFSetup(sc)
  File "/usr/local/test/python/lib/python2.6/urllib.py", line 1330, in
_CFSetup
    sc.CFStringCreateWithCString.argtypes = [ c_void_p, c_char_p, c_int32 ]
  File "/usr/local/test/python/lib/python2.6/ctypes/__init__.py", line
366, in __getattr__
    func = self.__getitem__(name)
  File "/usr/local/test/python/lib/python2.6/ctypes/__init__.py", line
371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, CFStringCreateWithCString): symbol
not found
Exception AttributeError: "FancyURLopener instance has no attribute
'tempcache'" in <bound method FancyURLopener.__del__ of
<urllib.FancyURLopener instance at 0x3743a0>> ignored


than tested it whit this code (Thanks to Ned Deily)
See the mailinglist thread at:
http://mail.python.org/pipermail/python-list/2009-March/703067.html

Contents of /tmp/tt.py:
-----------------------
from ctypes import cdll
from ctypes.util import find_library
sc = cdll.LoadLibrary(find_library("SystemConfiguration"))
x = sc.CFStringCreateWithCString(0, "HTTPEnable", 0)
-----------------------
/usr/local/test/python/bin/python2.6 /tmp/tt.py
Traceback (most recent call last):
  File "/tmp/tt.py", line 4, in <module>
    x = sc.CFStringCreateWithCString(0, "HTTPEnable", 0)
  File "/usr/local/test/python/lib/python2.6/ctypes/__init__.py", line
366,
in __getattr__
    func = self.__getitem__(name)
  File "/usr/local/test/python/lib/python2.6/ctypes/__init__.py", line
371,
in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, CFStringCreateWithCString): symbol
not
found

Both test fails on my PPC Mac and runs without error on my Intel MacBook

Some detailed info about the macs:

ppc:
Model Name: Xserve G5
Model Identifier: RackMac3,1
Processor Name: PowerPC G5  (3.1)
Processor Speed: 2.3 GHz
Number Of CPUs: 2
L2 Cache (per CPU): 512 KB
Boot ROM Version: 5.1.7f2
System Version: Mac OS X Server 10.5.6 (9G55)
Kernel Version: Darwin 9.6.0


intel:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.4 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Bus Speed: 800 MHz
Boot ROM Version: MBP31.0070.B07
SSC Version: 1.16f8
System Version: Mac OS X 10.5.6 (9G55)
Kernel Version: Darwin 9.6.0


I recompiled Python-2.6.1 with MACOSX_DEPLOYMENT_TARGET=10.3, but no
change..
I updated developertools to xcode312_2621, no change..

Btw.. Python-2.5.4 compiled from scratch works fine.

I dig a bit deeper with otool and discover some differences:

Intel MacOS.so: Carbon, libSystem.B.dylib, CoreServices,
ApplicationServices

PPC MacOS.so: Carbon, libmx.A.dylib, libSystem.B.dylib

Intel _ctypes.so: libSystem.B.dylib
PPC _ctypes.so: libmx.A.dylib, libSystem.B.dylib

-----------
Intel with deploymant target 10.3, xcode312:
-----------
sh-3.2# otool
-L /usr/local/test/python/lib/python2.6/lib-dynload/MacOS.so
/usr/local/test/python/lib/python2.6/lib-dynload/MacOS.so:
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 136.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version
111.1.3)
    
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 32.0.0)
    
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Applicat
ionServices (compatibility version 1.0.0, current version 34.0.0)

-------

sh-3.2# otool
-L /usr/local/test/python/lib/python2.6/lib-dynload/_ctypes.so
/usr/local/test/python/lib/python2.6/lib-dynload/_ctypes.so:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version
111.1.3)

----------
PPC with deployment_target 10.3, xcode312_2621
----------

otool -L /usr/local/test/python/lib/python2.6/lib-dynload/MacOS.so
/usr/local/test/python/lib/python2.6/lib-dynload/MacOS.so:
    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 136.0.0)
    /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version
47.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version
111.1.3)

-------


otool -L /usr/local/test/python/lib/python2.6/lib-dynload/_ctypes.so
/usr/local/test/python/lib/python2.6/lib-dynload/_ctypes.so:
    /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version
47.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version
111.1.3)


How i compiled it:

export MACOSX_DEPLOYMENT_TARGET=10.5
configure --prefix=/usr/local/test/python
make
make install

How i test:

export
PYTHONPATH=/usr/local/test/python:/usr/local/test/python/lib/python2.6/site-packages
/usr/local/test/python/bin/ is in the PATH
python /tmp/t.py

----------
assignee: theller
components: Macintosh, ctypes
messages: 83111
nosy: atiware at gmx.net, theller
severity: normal
status: open
title: urllib ctypes error on Mac OS X Server 10.5
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar  4 06:16:49 2009
From: report at bugs.python.org (David Majnemer)
Date: Wed, 04 Mar 2009 05:16:49 +0000
Subject: [New-bugs-announce] [issue5414] asciibin.a2b_uu returns unexpected
	values on non ascii data
In-Reply-To: <1236143809.26.0.796935135561.issue5414@psf.upfronthosting.co.za>
Message-ID: <1236143809.26.0.796935135561.issue5414@psf.upfronthosting.co.za>


New submission from David Majnemer <david.majnemer at gmail.com>:

Note that binascii.a2b_uu("\0") returns
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'.
This appears to be the same as binascii.a2b_uu() which is most likely
not the intention.
Also, binascii.a2b_uu("\0\0") returns an exception, "Illegal char",
which makes sense.

----------
components: Library (Lib)
messages: 83114
nosy: dmajnemer
severity: normal
status: open
title: asciibin.a2b_uu returns unexpected values on non ascii data
type: behavior

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

From report at bugs.python.org  Wed Mar  4 08:29:00 2009
From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Puls?=)
Date: Wed, 04 Mar 2009 07:29:00 +0000
Subject: [New-bugs-announce] [issue5415] uuid module generates incorrect
	values for uuid3 (and possibly uuid5)
In-Reply-To: <1236151740.35.0.183499583743.issue5415@psf.upfronthosting.co.za>
Message-ID: <1236151740.35.0.183499583743.issue5415@psf.upfronthosting.co.za>


New submission from Ren? Puls <rene.puls at repro-mayr.de>:

I am trying to recreate the sample output from appendix B of RFC 4122.

http://www.ietf.org/rfc/rfc4122.txt

In that document, a version 3 UUID is created using the DNS namespace 
(6ba7b810-9dad-11d1-80b4-00c04fd430c8, same as uuid.NAMESPACE_DNS in 
Python) and the name 'www.widgets.com'.

The result according to the RFC should be:

e902893a-9d22-3c7e-a7b8-d6e313b71d9f

Here is the output from the Python uuid module:

>>> import uuid
>>> uuid.NAMESPACE_DNS
UUID('6ba7b810-9dad-11d1-80b4-00c04fd430c8')
>>> uuid.uuid3(uuid.NAMESPACE_DNS, 'www.widgets.com')
UUID('3d813cbb-47fb-32ba-91df-831e1593ac29')

I couldn't find any test cases for the Python module. Did I use it 
incorrectly, or is the calculation really off?

----------
components: Library (Lib)
messages: 83118
nosy: pwr
severity: normal
status: open
title: uuid module generates incorrect values for uuid3 (and possibly uuid5)
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Mar  4 11:52:11 2009
From: report at bugs.python.org (David Majnemer)
Date: Wed, 04 Mar 2009 10:52:11 +0000
Subject: [New-bugs-announce] [issue5416] str.replace does strange things
	when given a negative count
In-Reply-To: <1236163931.77.0.818123555808.issue5416@psf.upfronthosting.co.za>
Message-ID: <1236163931.77.0.818123555808.issue5416@psf.upfronthosting.co.za>


New submission from David Majnemer <david.majnemer at gmail.com>:

str.replace("", "", "asdf", -1) returns "asdf", I believe this is not
correct and strictly speaking not up to the documentation posted. I am
of the opinion that it should function like str.replace("", "", "asdf",
0) which returns ""

----------
components: Interpreter Core
messages: 83119
nosy: dmajnemer
severity: normal
status: open
title: str.replace does strange things when given a negative count
versions: Python 2.5

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

From report at bugs.python.org  Wed Mar  4 22:21:59 2009
From: report at bugs.python.org (Ruth Aydt)
Date: Wed, 04 Mar 2009 21:21:59 +0000
Subject: [New-bugs-announce] [issue5417] Reference to missing(?) function in
	Extending & Embedding Document
In-Reply-To: <1236201719.81.0.524909062224.issue5417@psf.upfronthosting.co.za>
Message-ID: <1236201719.81.0.524909062224.issue5417@psf.upfronthosting.co.za>


New submission from Ruth Aydt <aydt at hdfgroup.org>:

Section 1.6 "Calling Python Functions from C" in the Extending and
Embedding Python, 2.6.1 guide talks about "PyEval_CallObject".  But, I
can't find it anywhere else in the 2.6 doc set.   

I did see in PEP 3100 that the function is to be removed in 3.0.  I
suspect section 1.6 in doc needs to be updated to use a different
function in the example & text.

----------
assignee: georg.brandl
components: Documentation
messages: 83134
nosy: aydt, georg.brandl
severity: normal
status: open
title: Reference to missing(?) function in Extending & Embedding Document
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar  5 01:58:40 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 05 Mar 2009 00:58:40 +0000
Subject: [New-bugs-announce] [issue5418] urllib.response.addinfourl does not
	support __exit__
In-Reply-To: <1236214720.46.0.00736247638438.issue5418@psf.upfronthosting.co.za>
Message-ID: <1236214720.46.0.00736247638438.issue5418@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

response = urllib.request.open(someURL)
    page = response.read()

close() be called on response after the read(), right?  Experimentation 
shows that I can repeatedly read from response until I close it, getting 
back empty bytes objects.

Thinking that anything with a close() should support the with statement, 
I tried putting  the code inside one but got
        AttributeError: 'addinfourl' object has no attribute '__exit__'
so I can see that it doesn't support with. It seems like it should.

----------
components: Library (Lib)
messages: 83174
nosy: MLModel
severity: normal
status: open
title: urllib.response.addinfourl does not support __exit__
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar  5 02:21:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 05 Mar 2009 01:21:26 +0000
Subject: [New-bugs-announce] [issue5419] urllib.request.open(someURL).read()
	returns a bytes object so writing it requires binary mode
In-Reply-To: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>
Message-ID: <1236216086.62.0.687528545638.issue5419@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

There needs to be something somewhere in the documentation that makes 
the simple point that data coming in from the web is bytes not strings, 
which is a big change from Python 2, and that it needs to be manipulated 
as such, including writing in binary mode.

I am not sure what documentation should be changed, but I do think 
something is missing, because I just ran around in circles on this one 
for quite some time. Perhaps the Unicode HOWTO needs more information; 
possibly urllib.request does; maybe a combination of things have to be 
added to several documentation files. Here's what happened:

I wanted to read from a web page, make some string replacements, and 
save to a file, so I wrote code that boils down to something like:

    with open('url.html', 'w') as fil:
        fil.write(urllib.request.open(aURL).read()).replace(str1, str2)

The first thing that happened was an error telling me that I can't write 
bytes to a text stream, so I realized that read() was returning a bytes 
object, which makes sense.

So I converted it to a string, but that put a b' at the beginning of the 
file and a ' at the end! Bad.

Instead of str(thebytes) I did the proper thing: thebytes.decode(), and 
wrote that to the file.

But then I found that Non-ASCII characters created problems -- they were 
saved in the file as \xNN\xNN or even three \x's, then displayed as 
garbage when the page was opened in a browser. 

So I tried decoding using different codecs but couldn't find one that 
worked for the ? and the emdash that were in the response.

Finally I realized that the whole thing was a delusion: obviously 
urlopen responses have to return bytes objects, and adding 'b' to the 
'w' when opening the output file fixed everything. (I also had to change 
my replacement strings to bytes.)

I went back to the relevant documentation multiple times, including 
after I figured everything out, and I can't convince myself that it 
makes the connection anywhere between bytes coming in, manipulating the 
bytes as bytes, and writing out in binary. Yes, in retrospect this all 
makes sense and perhaps even should have been obvious, but I am quite 
sure I won't be the only experienced Python 2 programmer to trip over 
this when making the transition to Python 3.

I apologize in advance if the requested documentation exists and I 
didn't find it, in which case I would appreciate a pointer to where it 
is lies.

----------
assignee: georg.brandl
components: Documentation
messages: 83179
nosy: MLModel, georg.brandl
severity: normal
status: open
title: urllib.request.open(someURL).read() returns a  bytes object so writing it requires binary mode
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar  5 03:02:37 2009
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Thu, 05 Mar 2009 02:02:37 +0000
Subject: [New-bugs-announce] [issue5420] Queue deprecation warning patch
In-Reply-To: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za>
Message-ID: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za>


New submission from Tennessee Leeuwenburg <tleeuwenburg at gmail.com>:

A very tiny patch which places a DeprecationWarning inside Queue.empty
and Queue.full

----------
components: Library (Lib)
files: queue_patch.txt
messages: 83180
nosy: tleeuwenburg at gmail.com
severity: normal
status: open
title: Queue deprecation warning patch
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13245/queue_patch.txt

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

From report at bugs.python.org  Thu Mar  5 11:15:03 2009
From: report at bugs.python.org (Manuel Hermann)
Date: Thu, 05 Mar 2009 10:15:03 +0000
Subject: [New-bugs-announce] [issue5421] Irritating error message by
	socket's sendto method
In-Reply-To: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>
Message-ID: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>


New submission from Manuel Hermann <manuel-hermann at gmx.net>:

When sending unexpected data via a socket's sentdo method, a TypeError
is raised with the fallowing message: "sendto() takes exactly 3
arguments (2 given)". But two arguments are sufficient.

Examples for Python 2.x:
import socket
my_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# this will succeed
my_socket.sendto("Foobar", ("localhost", 514))

# these will fail with above error message
my_socket.sendto(u"Umlaut ?", ("localhost", 514))
my_socket.sendto(1, ("localhost", 514))


Examples for Python 3:
import socket
my_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# this will succeed
my_socket.sendto("No Umlaut".encode("ascii"), ("localhost", 514))

# these will fail with above error message
my_socket.sendto("No Umlaut", ("localhost", 514))
my_socket.sendto(1, ("localhost", 514))

----------
components: Library (Lib)
messages: 83187
nosy: helduel
severity: normal
status: open
title: Irritating error message by socket's sendto method
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Mar  5 13:14:38 2009
From: report at bugs.python.org (=?utf-8?q?=E5=BE=90=E6=B4=B2?=)
Date: Thu, 05 Mar 2009 12:14:38 +0000
Subject: [New-bugs-announce] [issue5422] load pyc file with mbcs file system
	in update_compiled_module
In-Reply-To: <1236255278.63.0.0210000378211.issue5422@psf.upfronthosting.co.za>
Message-ID: <1236255278.63.0.0210000378211.issue5422@psf.upfronthosting.co.za>


New submission from ?? <x_o at 163.com>:

py3k 3.01

static int
update_compiled_module(PyCodeObject *co, char *pathname)
{
	PyObject *oldname, *newname;

	if (!PyUnicode_CompareWithASCIIString(co->co_filename, 
pathname))
		return 0;

/* string pathname related with FILE SYSTEM !!! 
 * old code is :
 * newname = PyUnicode_FromString(pathname); 
 */
	newname = PyUnicode_DecodeFSDefault(pathname);
	if (newname == NULL)
		return -1;

	oldname = co->co_filename;
	Py_INCREF(oldname);
	update_code_filenames(co, oldname, newname);
	Py_DECREF(oldname);
	Py_DECREF(newname);
	return 1;
}

----------
components: Windows
messages: 83190
nosy: joexo
severity: normal
status: open
title: load pyc file with mbcs file system in update_compiled_module
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu Mar  5 14:01:13 2009
From: report at bugs.python.org (Chris Withers)
Date: Thu, 05 Mar 2009 13:01:13 +0000
Subject: [New-bugs-announce] [issue5423] Exception raised when attempting to
	call set_charset on an email.mime.multipart once sub-parts
	have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

Hi All,

I'm splitting this out from [Issue1823] as it's a separate issue.

Here's a minimal case to reproduce:

>>> from email.MIMEMultipart import MIMEMultipart
>>> from email.MIMEText import MIMEText
>>> msg = MIMEMultipart()
>>> msg.attach(MIMEText('foo','plain'))
>>> msg.set_charset('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python24\lib\email\Message.py", line 260, in set_charset
    self._payload = charset.body_encode(self._payload)
  File "C:\python24\lib\email\Charset.py", line 366, in body_encode
    return email.base64MIME.body_encode(s)
  File "C:\python24\lib\email\base64MIME.py", line 136, in encode
    enc = b2a_base64(s[i:i + max_unencoded])
TypeError: b2a_base64() argument 1 must be string or read-only buffer, 
not list

NB: The exception raised can vary depending on the character set used:

>>> msg.set_charset('iso-8859-15')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python24\lib\email\Message.py", line 260, in set_charset
    self._payload = charset.body_encode(self._payload)
  File "C:\python24\lib\email\Charset.py", line 368, in body_encode
    return email.quopriMIME.body_encode(s)
  File "C:\python24\lib\email\quopriMIME.py", line 180, in encode
    body = fix_eols(body)
  File "C:\python24\lib\email\Utils.py", line 62, in fix_eols
    s = re.sub(r'(?<!\r)\n', CRLF, s)
  File "C:\python24\lib\sre.py", line 142, in sub
    return _compile(pattern, 0).sub(repl, string, count)
TypeError: expected string or buffer

Chris

----------
messages: 83193
nosy: Sharebear, barry, christian.heimes, cjw296, loewis
severity: normal
status: open
title: Exception raised when attempting to call set_charset on an email.mime.multipart once sub-parts have been attached

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

From report at bugs.python.org  Thu Mar  5 14:37:17 2009
From: report at bugs.python.org (Philipp Hagemeister)
Date: Thu, 05 Mar 2009 13:37:17 +0000
Subject: [New-bugs-announce] [issue5424] Packed IPaddr conversion tests
	should be extended
In-Reply-To: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>
Message-ID: <1236260237.37.0.149966249724.issue5424@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister <phihag at phihag.de>:

Currently, the testStringToIPv6 and testIPv6ToStrings tests in
Lib/test/test_socket.py only check for variants 1 and 2 (but not 3) from
RFC 4291 2.2.

Furthermore, there are no assertions that check wrong inputs are
appropriately refused in any of the packed IP conversion tests.

The attached patch adds a number of assertions covering those.

----------
components: Tests
files: extend-packed-ip-tests-trunk2.x.diff
keywords: patch
messages: 83195
nosy: phihag
severity: normal
status: open
title: Packed IPaddr conversion tests should be extended
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13247/extend-packed-ip-tests-trunk2.x.diff

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

From report at bugs.python.org  Thu Mar  5 15:48:51 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 05 Mar 2009 14:48:51 +0000
Subject: [New-bugs-announce] [issue5425] 2to3 wrong for types.StringTypes
In-Reply-To: <1236264531.78.0.371254009899.issue5425@psf.upfronthosting.co.za>
Message-ID: <1236264531.78.0.371254009899.issue5425@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

In Python 2.6 we have

>>> types.StringTypes
(<type 'str'>, <type 'unicode'>)

but 2to3 translates "types.StringTypes" into "str", which is obviously
wrong. The attached patch changes it into "(str, bytes)".

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_StringTypes.patch
keywords: patch
messages: 83198
nosy: hagen
severity: normal
status: open
title: 2to3 wrong for types.StringTypes
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13248/2to3_StringTypes.patch

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

From report at bugs.python.org  Thu Mar  5 17:44:30 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 05 Mar 2009 16:44:30 +0000
Subject: [New-bugs-announce] [issue5426] README slight error re OSX
In-Reply-To: <1236271470.07.0.217969645755.issue5426@psf.upfronthosting.co.za>
Message-ID: <1236271470.07.0.217969645755.issue5426@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Line 136 of the 3.0 README and line 179 of the 3.1 README state that the 
executable on OSX is called python.exe. It's not.

----------
assignee: georg.brandl
components: Documentation
messages: 83203
nosy: MLModel, georg.brandl
severity: normal
status: open
title: README slight error re OSX
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar  5 19:36:18 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 05 Mar 2009 18:36:18 +0000
Subject: [New-bugs-announce] [issue5427] OSX framework make error: ld:
	duplicate symbol _PyExc_BlockingIOError in
	libpython3.1.a(_iobase.o) and libpython3.1.a(io.o)
In-Reply-To: <1236278178.06.0.131400949439.issue5427@psf.upfronthosting.co.za>
Message-ID: <1236278178.06.0.131400949439.issue5427@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Trying to build 3.1 in recent 'svn update's on OSX 10.5 after
    make clean
    configure --enable-framework
I get the following error near the end of the build:
    ld: duplicate symbol _PyExc_BlockingIOError in 
libpython3.1.a(_iobase.o) and libpython3.1.a(io.o)

I even tried deleting all the files and checking them out again, but I got 
the same error.

----------
components: Build
messages: 83211
nosy: MLModel
severity: normal
status: open
title: OSX framework make error: ld: duplicate symbol _PyExc_BlockingIOError in libpython3.1.a(_iobase.o) and libpython3.1.a(io.o)
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar  5 23:05:07 2009
From: report at bugs.python.org (Michel Weinachter)
Date: Thu, 05 Mar 2009 22:05:07 +0000
Subject: [New-bugs-announce] [issue5428] Pyshell history management error
In-Reply-To: <1236290707.1.0.232132211255.issue5428@psf.upfronthosting.co.za>
Message-ID: <1236290707.1.0.232132211255.issue5428@psf.upfronthosting.co.za>


New submission from Michel Weinachter <michel at weinachter.com>:

I have created a variable named "liste_de_courses" when I use Alt-P to 
gather a previous command and modify it I have the following error:

------------
>>> liste_de_courses.append(?b')
			
SyntaxError: invalid character in identifier (<pyshell#21>, line 1)
------------

There is no issue in the command line.

----------
components: IDLE
messages: 83223
nosy: datamoc
severity: normal
status: open
title: Pyshell history management error
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Mar  6 00:53:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Mar 2009 23:53:14 +0000
Subject: [New-bugs-announce] [issue5429] Core dumps on the Solaris buildbot
In-Reply-To: <1236297194.7.0.256831518198.issue5429@psf.upfronthosting.co.za>
Message-ID: <1236297194.7.0.256831518198.issue5429@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It has been happening for a few days now... may be related to the IO-C
merge.
http://www.python.org/dev/buildbot/3.x.stable/

----------
components: Tests
messages: 83227
nosy: benjamin.peterson, pitrou
priority: high
severity: normal
status: open
title: Core dumps on the Solaris buildbot
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Mar  6 08:51:17 2009
From: report at bugs.python.org (Memeplex)
Date: Fri, 06 Mar 2009 07:51:17 +0000
Subject: [New-bugs-announce] [issue5430] Must not replace LF or CR by CRLF
	in literals
In-Reply-To: <1236325877.36.0.637700625895.issue5430@psf.upfronthosting.co.za>
Message-ID: <1236325877.36.0.637700625895.issue5430@psf.upfronthosting.co.za>


New submission from Memeplex <carlosjosepita at gmail.com>:

For example, after that "normalization", quoted printable encoded
headers (as described at rfc 2047) longer than 76 characters are
splitted in two different ill-formed headers because the soft LF line
break becomes a "hard" CRLF one. This is clearly wrong.

rfc 2060 specifically allows CR and LF inside literals:

"""
A literal is a sequence of zero or more octets (including CR and LF),
prefix-quoted with an octet count in the form of an open brace ("{"),
the number of octets, close brace ("}"), and CRLF.
"""

----------
components: Library (Lib)
messages: 83241
nosy: memeplex
severity: normal
status: open
title: Must not replace LF or CR by CRLF in literals
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar  6 14:22:34 2009
From: report at bugs.python.org (Nigel Galloway)
Date: Fri, 06 Mar 2009 13:22:34 +0000
Subject: [New-bugs-announce] [issue5431] cmpfunc in Python 3.0.1 windows
	installer
In-Reply-To: <1236345754.09.0.226629136415.issue5431@psf.upfronthosting.co.za>
Message-ID: <1236345754.09.0.226629136415.issue5431@psf.upfronthosting.co.za>


New submission from Nigel Galloway <nigel_galloway at yahoo.com>:

C:\Users\Nigel\myPython\iajaar>C:\Users\Nigel\swigwin-1.3.38\swig -
c++ -python -py3  NigelzGLPK.swg

generated a C++ wrapper and a Python file. When I attempted to compile 
the wrapper against Python 3.0.1 it failed see the output log at the 
end of this message.


I decided to modify object.h from C:\Python30\include:

typedef PyObject *(*getattrofunc)(PyObject *, PyObject *);
typedef int (*setattrfunc)(PyObject *, char *, PyObject *);
typedef int (*setattrofunc)(PyObject *, PyObject *, PyObject *);
typedef PyObject *(*reprfunc)(PyObject *);


typedef PyObject *(*getattrofunc)(PyObject *, PyObject *);
typedef int (*setattrfunc)(PyObject *, char *, PyObject *);
typedef int (*cmpfunc)(PyObject *, PyObject *);
typedef int (*setattrofunc)(PyObject *, PyObject *, PyObject *);
typedef PyObject *(*reprfunc)(PyObject *);


adding the typedef for cmpfunc. It then compiles fine, AND appears to 
work.

C:\Users\Nigel\myPython\iajaar\Python>c:\Python30\python 
sample.iajaar.3.py
*     0: obj =  0.000000000e+000  infeas = 0.000e+000 (0)
*     2: obj =  7.333333333e+002  infeas = 0.000e+000 (0)
OPTIMAL SOLUTION FOUND
Z =  733.333333333 ; x1 =  33.3333333333 ; x2 =  66.6666666667 ; x3 =  
0.0


Is this good, or should I do something else?



Compile Log:

Build Log      Rebuild started: Project: nigelzGLPK, Configuration: 
Release|Win32
 Command Lines      Creating temporary 
file "c:\Users\Nigel\Documents\Visual Studio 2008
\Projects\nigelzGLPK\nigelzGLPK\Release\RSP00001137523960.rsp" with 
contents
[
/O2 /Oi /GL /I "C:\Users\Nigel\Documents\Visual Studio 2008
\Projects\glpk\include" /I "C:\Python30
\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "NIGELZG
LPK_EXPORTS" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Gy 
/Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /c /Zi /TP "..\..\..\..\..\myP
ython\iajaar\NigelzGLPK_wrap.cxx"
]
Creating command line "cl.exe @"c:\Users\Nigel\Documents\Visual Studio 
2008
\Projects\nigelzGLPK\nigelzGLPK\Release\RSP00001137523960.rsp" /nologo 
/errorReport:prompt"
 Output Window      Compiling...
NigelzGLPK_wrap.cxx
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1772) : error 
C2065: 'cmpfunc' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1772) : error 
C2146: syntax error : missing '}' before 
identifier 'SwigPyObject_compare'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1772) : error 
C2146: syntax error : missing ';' before 
identifier 'SwigPyObject_compare'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1817) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1818) : error 
C2065: 'tmp' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1825) : error 
C2059: syntax error : 'return'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1943) : error 
C2065: 'cmpfunc' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1943) : error 
C2146: syntax error : missing '}' before 
identifier 'SwigPyPacked_compare'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1943) : error 
C2146: syntax error : missing ';' before 
identifier 'SwigPyPacked_compare'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1988) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1989) : error 
C2065: 'tmp' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1996) : error 
C2059: syntax error : 'return'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1997) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1997) : error 
C2143: syntax error : missing ';' before '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(1997) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2001) : error 
C2143: syntax error : missing ';' before '{'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2001) : error 
C2447: '{' : missing function header (old-style formal list?)
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2400) : error 
C3861: 'SwigPyPacked_New': identifier not found
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2635) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2635) : error 
C2143: syntax error : missing ';' before '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2635) : error 
C2059: syntax error : '}'
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(2674) : error 
C2065: 'swig_types' : undeclared identifier
c:\users\nigel\mypython\iajaar\iajaar.h(59) : warning C4290: C++ 
exception specification ignored except to indicate a function is not 
__declspec(nothrow)
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3176) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3191) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3207) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3226) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3253) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3277) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3277) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3296) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3318) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3324) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3340) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3346) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3362) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3368) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3383) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3399) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3415) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3442) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3461) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3476) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3492) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3508) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3535) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3560) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3587) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3606) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3621) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3637) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3653) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3680) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3705) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3732) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3757) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3784) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3809) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3836) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3861) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3888) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3913) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3940) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3965) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(3992) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4017) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4044) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4069) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4096) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4121) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4148) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4173) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4200) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4225) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4252) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4277) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4282) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4311) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4317) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4330) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4345) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4361) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4377) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4404) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4429) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4456) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4481) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4508) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4533) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4560) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4585) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4612) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4637) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4664) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4689) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4716) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4741) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4768) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4793) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4820) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4845) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4872) : error 
C2065: 'swig_types' : undeclared identifier
..\..\..\..\..\myPython\iajaar\NigelzGLPK_wrap.cxx(4872) : fatal error 
C1003: error count exceeds 100; stopping compilation
 Results      Build log was saved 
at "file://c:\Users\Nigel\Documents\Visual Studio 2008
\Projects\nigelzGLPK\nigelzGLPK\Release\BuildLog.htm"
nigelzGLPK - 102 error(s), 1 warning(s)

----------
files: BuildLog.htm
messages: 83242
nosy: Nigel Galloway
severity: normal
status: open
title: cmpfunc in Python 3.0.1 windows installer
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file13254/BuildLog.htm

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

From report at bugs.python.org  Fri Mar  6 19:53:41 2009
From: report at bugs.python.org (Jim Correia)
Date: Fri, 06 Mar 2009 18:53:41 +0000
Subject: [New-bugs-announce] [issue5432] plistlib contains unescaped hex
	sequence in doc string
In-Reply-To: <1236365621.57.0.647888417793.issue5432@psf.upfronthosting.co.za>
Message-ID: <1236365621.57.0.647888417793.issue5432@psf.upfronthosting.co.za>


New submission from Jim Correia <jim.correia at pobox.com>:

The module doc string contains an example with hex escape sequences (see 
below). They are converted to their literal values by pydoc, which 
results in an unexpected encoding for the output of pydoc.

(raw string, or proper escaping solves the problem)

Relevant chunk of the file:

            anotherString="<hello & hi there!>",
            aUnicodeValue=u'M\xe4ssig, Ma\xdf',
            aTrueValue=True,
            aFalseValue=False,
        ),
        someData = Data("<binary gunk>"),
        someMoreData = Data("<lots of binary gunk>" * 10),
        aDate = 
datetime.datetime.fromtimestamp(time.mktime(time.gmtime())),
    )
    # unicode keys are possible, but a little awkward to use:
    pl[u'\xc5benraa'] = "That was a unicode key."

----------
components: Library (Lib)
messages: 83251
nosy: jim.correia
severity: normal
status: open
title: plistlib contains unescaped hex sequence in doc string
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar  7 00:06:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Mar 2009 23:06:42 +0000
Subject: [New-bugs-announce] [issue5433] Excessive optimization in
	IncrementalNewlineDecoder
In-Reply-To: <1236380802.95.0.0574474328629.issue5433@psf.upfronthosting.co.za>
Message-ID: <1236380802.95.0.0574474328629.issue5433@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is with the io-c code:

>>> dec = io.IncrementalNewlineDecoder(None, translate=False)
>>> dec.newlines
>>> dec.decode("\u0A00")
'\u0a00'
>>> dec.newlines
'\n'

dec.newlines should have remained equal to None. It only affects the
computation of the newlines property and shouldn't produce incorrect
decoding results.

----------
assignee: pitrou
components: Extension Modules
messages: 83258
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Excessive optimization in IncrementalNewlineDecoder
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Mar  7 06:04:50 2009
From: report at bugs.python.org (Jess Austin)
Date: Sat, 07 Mar 2009 05:04:50 +0000
Subject: [New-bugs-announce] [issue5434] datetime.MonthDelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>


New submission from Jess Austin <jess.austin at gmail.com>:

datetime is a wonderful module.  Perhaps the only inconvenient aspect of
using it is dealing with month calculations and comparisons.  This patch
adds a simple class, monthdelta, which represents date offsets in terms
of months.  It supports basic integer-like arithmetic, and also it may
be added to dates and datetimes.  It deals sensibly with leap-year and
month-length issues.  Also provided is a function, monthmod (named by
imperfect analogy to divmod), which allows round-tripping: that is,
taking 2 dates and returning a (monthdelta, timedelta) tuple that
represents the interim between the dates.

Note: I have named the class "monthdelta", but in light of recent
python-dev discussions I should probably rename this to "MonthDelta".

----------
components: Library (Lib)
messages: 83272
nosy: jess.austin
severity: normal
status: open
title: datetime.MonthDelta
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Sat Mar  7 06:37:20 2009
From: report at bugs.python.org (Michael Zamot)
Date: Sat, 07 Mar 2009 05:37:20 +0000
Subject: [New-bugs-announce] [issue5435] test_httpservers on Debian Testing
In-Reply-To: <1236404239.81.0.966059506466.issue5435@psf.upfronthosting.co.za>
Message-ID: <1236404239.81.0.966059506466.issue5435@psf.upfronthosting.co.za>


New submission from Michael Zamot <michael at zamotcr.net>:

Hi, im trying to compile Python 3.0.1 under Debian Testing, and i get an
error in the step make test. 
test_https fails with errno 13. The atach file has the full output.
So, what is missing in my computer or what i need to do, to compile it,
thanks and sorry for my english.

----------
components: None
files: bug.txt
messages: 83274
nosy: zamotcr
severity: normal
status: open
title: test_httpservers on Debian Testing
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file13259/bug.txt

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

From report at bugs.python.org  Sat Mar  7 18:15:28 2009
From: report at bugs.python.org (Martina Oefelein)
Date: Sat, 07 Mar 2009 17:15:28 +0000
Subject: [New-bugs-announce] [issue5436] test_distutils fails with official
	Mac OS X Installer Disk Image (3.0.1)
In-Reply-To: <1236446128.5.0.33521760843.issue5436@psf.upfronthosting.co.za>
Message-ID: <1236446128.5.0.33521760843.issue5436@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

Majestix:~ martina$ python3.0 -m test.regrtest test_distutils
Could not find '/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test' in sys.path to remove it
test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/tests/test_sysconfig.py", line 45, in 
test_get_python_inc
    self.assert_(os.path.isdir(inc_dir), inc_dir)
AssertionError: /Users/ronald/Projects/python/bld/r301/Include

1 test failed:
    test_distutils

----------
assignee: tarek
components: Distutils, Macintosh, Tests
messages: 83283
nosy: oefe, tarek
severity: normal
status: open
title: test_distutils fails with official Mac OS X Installer Disk Image (3.0.1)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Mar  8 02:19:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2009 01:19:52 +0000
Subject: [New-bugs-announce] [issue5437] Singleton MemoryError can hold
	traceback data and locals indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The PyExc_MemoryErrorInst object is persistent and its members never get
cleared. This means any local variable which gets caught in the
traceback isn't deallocated until the next MemoryError (!). Sample
script demonstrates this.

(this doesn't seem to affect 2.x because the traceback isn't attached to
the exception instance)

----------
files: memerr.py
messages: 83292
nosy: amaury.forgeotdarc, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Singleton MemoryError can hold traceback data and locals indefinitely
type: resource usage
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13261/memerr.py

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

From report at bugs.python.org  Sun Mar  8 02:25:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2009 01:25:15 +0000
Subject: [New-bugs-announce] [issue5438] test_bigmem.test_from_2G_generator
	uses more memory than expected
In-Reply-To: <1236475515.92.0.849329057425.issue5438@psf.upfronthosting.co.za>
Message-ID: <1236475515.92.0.849329057425.issue5438@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems test_from_2G_generator doesn't respect its announced memory
consumption. I launched test_bigmem with "-M 12G" on a 16GB machine, and
the interpreter process got killed by the OOM killer (Out Of Memory)
while running this test case.

----------
components: Tests
messages: 83295
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_bigmem.test_from_2G_generator uses more memory than expected
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar  8 06:28:15 2009
From: report at bugs.python.org (Dongwook Jang)
Date: Sun, 08 Mar 2009 05:28:15 +0000
Subject: [New-bugs-announce] [issue5439] string.strip behaves strangly
In-Reply-To: <1236490094.86.0.622716526425.issue5439@psf.upfronthosting.co.za>
Message-ID: <1236490094.86.0.622716526425.issue5439@psf.upfronthosting.co.za>


New submission from Dongwook Jang <jang.dongwook at gmail.com>:

Python 2.4.2 (#1, Mar  4 2008, 22:56:43)
[GCC 3.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> temp = "a/b/c"
>>> temp.strip("a")
'/b/c'
>>> temp.strip("a/")
'b/c'
>>> temp.strip("a/b")
'c'
>>> temp.strip("a/b/")
'c'
>>>


So, in the second command from the last, I expected '/c' but it gives
only 'c'.
Why? Is it a bug or a feature that I don't understand?

Thanks,
DW

----------
components: Interpreter Core
messages: 83300
nosy: dwjang
severity: normal
status: open
title: string.strip behaves strangly
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Sun Mar  8 06:28:19 2009
From: report at bugs.python.org (Dongwook Jang)
Date: Sun, 08 Mar 2009 05:28:19 +0000
Subject: [New-bugs-announce] [issue5440] string.strip behaves strangly
In-Reply-To: <1236490099.52.0.543395696191.issue5440@psf.upfronthosting.co.za>
Message-ID: <1236490099.52.0.543395696191.issue5440@psf.upfronthosting.co.za>


New submission from Dongwook Jang <jang.dongwook at gmail.com>:

Python 2.4.2 (#1, Mar  4 2008, 22:56:43)
[GCC 3.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> temp = "a/b/c"
>>> temp.strip("a")
'/b/c'
>>> temp.strip("a/")
'b/c'
>>> temp.strip("a/b")
'c'
>>> temp.strip("a/b/")
'c'
>>>


So, in the second command from the last, I expected '/c' but it gives
only 'c'.
Why? Is it a bug or a feature that I don't understand?

Thanks,
DW

----------
components: Interpreter Core
messages: 83301
nosy: dwjang
severity: normal
status: open
title: string.strip behaves strangly
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Sun Mar  8 07:02:27 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Mar 2009 06:02:27 +0000
Subject: [New-bugs-announce] [issue5441] Convenience API for timeit.main
In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za>
Message-ID: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

For quick and dirty benchmarking, timeit.main() is one of the handiest
tools out there, but calling it from Python code is a little tedious
since you need to construct a fake list of command line arguments in
order to call it.

What would be nice is a convenience function that accepted appropriate
arguments, with timeit.main being refactored to parse the command line
arguments and then call the new convenience function.

Possible API:

def measure(stmt="pass", setup="pass", timer=default_timer,
            repeat=default_repeat, number=default_number,
            verbosity=0, precision=3)

The new function would cover the latter section of the current main()
function, starting from the line "t = Timer(stmt, setup, timer)".

----------
components: Library (Lib)
keywords: easy
messages: 83305
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Convenience API for timeit.main
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Mar  8 13:59:20 2009
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 08 Mar 2009 12:59:20 +0000
Subject: [New-bugs-announce] [issue5442] [3.1alpha1] test_importlib fails on
	Mac OSX 10.5.6
In-Reply-To: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>
Message-ID: <1236517160.74.0.61108619715.issue5442@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Two failures in test_importlib:

======================================================================
FAIL: test_case_insensitivity 
(importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensi
tivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Downloads/Python-
3.1a1/Lib/importlib/test/extension/test_case_sensitivity.py", line 29, 
in test_case_insensitivity
    self.assert_(hasattr(loader, 'load_module'))
AssertionError: None

======================================================================
FAIL: test_insensitive 
(importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Downloads/Python-
3.1a1/Lib/importlib/test/source/test_case_sensitivity.py", line 49, in 
test_insensitive
    self.assert_(hasattr(insensitive, 'load_module'))
AssertionError: None

----------------------------------------------------------------------

----------
message_count: 1.0
messages: 83308
nosy: cartman
nosy_count: 1.0
severity: normal
status: open
title: [3.1alpha1] test_importlib fails on Mac OSX 10.5.6
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar  8 17:57:49 2009
From: report at bugs.python.org (Lorenz Quack)
Date: Sun, 08 Mar 2009 16:57:49 +0000
Subject: [New-bugs-announce] [issue5443] trivial typo in itertools
	documentation
In-Reply-To: <1236531469.71.0.843632021292.issue5443@psf.upfronthosting.co.za>
Message-ID: <1236531469.71.0.843632021292.issue5443@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

In the docs:
"http://docs.python.org/library/itertools.html#module-itertools"
In the table: "Iterators terminating on the shortest input sequence:"
In row: "imap()" and "starmap()"
In the column: "Results"

It says "fun()" instead of "func()"

----------
assignee: georg.brandl
components: Documentation
message_count: 1.0
messages: 83314
nosy: donlorenzo, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: trivial typo in itertools documentation
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar  8 20:18:54 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 08 Mar 2009 19:18:54 +0000
Subject: [New-bugs-announce] [issue5444] .chm build process on Windows
	doesn't use the right filename
In-Reply-To: <1236539934.85.0.997903417745.issue5444@psf.upfronthosting.co.za>
Message-ID: <1236539934.85.0.997903417745.issue5444@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

doc/make.bat on Windows doesn't correctly build the right .chm 
filename. 
This patch does the same as the unix Makefile: run patchlevel.py and 
set the output as the DISTVERSION environment variable, so it can be 
used in the final file name.

----------
assignee: georg.brandl
components: Documentation
files: make.diff
keywords: patch
message_count: 1.0
messages: 83320
nosy: gagenellina, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: .chm build process on Windows doesn't use the right filename
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13266/make.diff

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

From report at bugs.python.org  Sun Mar  8 20:31:16 2009
From: report at bugs.python.org (Daniel Lescohier)
Date: Sun, 08 Mar 2009 19:31:16 +0000
Subject: [New-bugs-announce] [issue5445] codecs.StreamWriter.writelines
	problem when passed generator
In-Reply-To: <1236540676.96.0.036576866383.issue5445@psf.upfronthosting.co.za>
Message-ID: <1236540676.96.0.036576866383.issue5445@psf.upfronthosting.co.za>


New submission from Daniel Lescohier <daniel.lescohier at cbs.com>:

This is the implementation of codecs.Streamwriter.writelines for all 
Python versions that I've checked:

    def writelines(self, list):

        """ Writes the concatenated list of strings to the stream
            using .write().
        """
        self.write(''.join(list))

This may be a problem if the 'list' parameter is a generator. The 
generator may be returning millions of values, which the join will 
concatenate in memory. It can surprise the programmer with large 
memory use. I think join should only be used when you know the size of 
your input, and this method does not know this. I think the safe 
implementation of this method would be:

    def writelines(self, list):

        """ Writes the concatenated list of strings to the stream
            using .write().
        """
        write = self.write
        for value in list:
            write(value)

If a caller knows that it's input list would use a reasonable amount 
of memory, it can get the same functionality as before by doing 
stream.write(''.join(list)).

----------
components: Library (Lib)
message_count: 1.0
messages: 83322
nosy: dlesco
nosy_count: 1.0
severity: normal
status: open
title: codecs.StreamWriter.writelines problem when passed generator
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Sun Mar  8 20:41:27 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 08 Mar 2009 19:41:27 +0000
Subject: [New-bugs-announce] [issue5446] doc building progress on Windows
	doesn't show any color
In-Reply-To: <1236541287.43.0.597624783432.issue5446@psf.upfronthosting.co.za>
Message-ID: <1236541287.43.0.597624783432.issue5446@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

The documentation building progress on Windows doesn't show any 
colorized output, unlike the linux environment.
This patch to console.py provides minimal color support on Windows.

----------
assignee: georg.brandl
components: Documentation
files: console.diff
keywords: patch
message_count: 1.0
messages: 83324
nosy: gagenellina, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: doc building progress on Windows doesn't show any color
type: feature request
Added file: http://bugs.python.org/file13267/console.diff

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

From report at bugs.python.org  Sun Mar  8 21:11:32 2009
From: report at bugs.python.org (Poor Yorick)
Date: Sun, 08 Mar 2009 20:11:32 +0000
Subject: [New-bugs-announce] [issue5447] future unicode literals and r'\u'
In-Reply-To: <1236543092.99.0.796172268474.issue5447@psf.upfronthosting.co.za>
Message-ID: <1236543092.99.0.796172268474.issue5447@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

from __future__ import unicode_literals
print(r'\u.bug')

SyntaxError: (unicode error) truncated \uXXXX

----------
components: Interpreter Core
message_count: 1.0
messages: 83326
nosy: pooryorick
nosy_count: 1.0
severity: normal
status: open
title: future unicode literals and r'\u'
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar  8 21:23:45 2009
From: report at bugs.python.org (Daniel Lescohier)
Date: Sun, 08 Mar 2009 20:23:45 +0000
Subject: [New-bugs-announce] [issue5448] Add precision property to
	decimal.Decimal
In-Reply-To: <1236543825.99.0.833291294426.issue5448@psf.upfronthosting.co.za>
Message-ID: <1236543825.99.0.833291294426.issue5448@psf.upfronthosting.co.za>


New submission from Daniel Lescohier <daniel.lescohier at cbs.com>:

I would like to get the decimal precision of decimal.Decimal objects 
(for my application, in order to validate whether a Decimal value will 
fit in the defined decimal precision of a database field). The way I 
found to get it was with:

precision = len(value._int)

where value is a decimal.Decimal object.

However, this uses a private API (_int). I would like to have a public 
API to get the decimal precision of a Decimal.  I propose we add the 
following to the decimal.Decimal class:

    @property
    def precision(self):
        """The precision of this Decimal value."""
        return len(self._int)

decimal.Context has a precision for calculations. 
decimal.Decimal.precision is the minimum precision needed to represent 
that value, not the precision that was used in calculating it.  If one 
wants to, one can actually use Decimal.precision to set your Context's 
precision:

d1 = decimal.Decimal('999')
d2 = d1
context.prec = d1.precision + d2.precision
d3 = d1 * d2

Open for debate is whether to name it Decimal.prec to mirror 
Context.prec.  We'd have to choose one or the other or both:

    @property
    def precision(self):
        """The precision of this Decimal value."""
        return len(self._int)
    prec = precision

----------
components: Library (Lib)
message_count: 1.0
messages: 83328
nosy: dlesco
nosy_count: 1.0
severity: normal
status: open
title: Add precision property to decimal.Decimal
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  9 00:53:00 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sun, 08 Mar 2009 23:53:00 +0000
Subject: [New-bugs-announce] [issue5449] bug fix to prevent io.BytesIO from
	accepting arbitrary keyword arguments
In-Reply-To: <1236556380.35.0.110625961105.issue5449@psf.upfronthosting.co.za>
Message-ID: <1236556380.35.0.110625961105.issue5449@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I noticed that it was possible to specify arbitrary arguments to 
io.BytesIO:

>>> io.BytesIO(b'foo', foo=1)
<_io.BytesIO object at 0x430150>

But io.StringIO doesn't:

>>> io.StringIO('foo', foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'foo' is an invalid keyword argument for this function

So, I've attached a little patch that uses the same technique 3.1a1 uses 
to parse the arguments. One thing to be aware of is that I named the 
kwarg "intial_bytes" just like http://docs.python.org/3.0/library/io.html#io.BytesIO instead of 
"inital_value" like io.StringIO. I'm not sure if it'd be desirable to be 
consistent between the two.

----------
components: Library (Lib)
files: 0001-Fix-io.BytesIO-to-not-accept-arbitrary-keywords.patch
keywords: patch
message_count: 1.0
messages: 83337
nosy: erickt
nosy_count: 1.0
severity: normal
status: open
title: bug fix to prevent io.BytesIO from accepting arbitrary keyword arguments
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13271/0001-Fix-io.BytesIO-to-not-accept-arbitrary-keywords.patch

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

From report at bugs.python.org  Mon Mar  9 01:06:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2009 00:06:55 +0000
Subject: [New-bugs-announce] [issue5450] test_tcl testLoadTk fails if
	DISPLAY defined but connect fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

If the DISPLAY environment variable is set, the test_tcl test
'testLoadTk' gives a traceback.  In the same circumstance, test_tk and
test_ttkguionly display the error and are skipped.  Although this is a
nit rather than a problem, for consistencies sake I think the testLoadTk
test should also be skipped rather than show up as a failure.  I've
attached a patch against the trunk that does this, with the caveat that
it is an individual testcase being skipped so it doesn't get recorded in
the 'skipped tests' summary.  I don't think this is a problem since
test_tk will likely show up in the skipped tests if this one is skipped,
and also there are circumstances in which testLoadTkFailure is skipped
completely silently.

Perhaps the real problem is that the tk tests should be in test_tk
instead of test_tcl?

----------
components: Tests, Tkinter
files: test_tcl.patch
keywords: patch
message_count: 1.0
messages: 83339
nosy: bitdancer
nosy_count: 1.0
severity: normal
status: open
title: test_tcl testLoadTk fails if DISPLAY defined but connect fails, instead of being skipped
type: behavior
versions: Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13273/test_tcl.patch

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

From report at bugs.python.org  Mon Mar  9 01:09:54 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 09 Mar 2009 00:09:54 +0000
Subject: [New-bugs-announce] [issue5451] patch to make io.StringIO
	consistent with open with respect to newlines
In-Reply-To: <1236557394.75.0.991537518962.issue5451@psf.upfronthosting.co.za>
Message-ID: <1236557394.75.0.991537518962.issue5451@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I noticed that io.StringIO is inconsistent with open on how newlines are 
handled. The default approach open uses is universal newlines:

>>> with open('foo', 'w') as f:
...   f.write('hello hi\r\nla la\r\n')
... 
17
>>> open('foo').readlines()
['hello hi\n', 'la la\n']

io.StringIO, however, defaults to just treating \n as newlines:

>>> io.StringIO('hello hi\r\nla la \r\n').readlines()
['hello hi\r\n', 'la la \r\n']

The attached patch changes this so that if the newline keyword isn't 
specified, then StringIO will act just like open with respect to 
keywords. It will then produce this:

>>> io.StringIO('hello hi\r\nla la \r\n').readlines()
['hello hi\n', 'la la \n']

----------
components: Library (Lib)
files: 0001-Make-StringIO-consistent-with-open-wrt-newlines.patch
keywords: patch
message_count: 1.0
messages: 83341
nosy: erickt
nosy_count: 1.0
severity: normal
status: open
title: patch to make io.StringIO consistent with open with respect to newlines
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13276/0001-Make-StringIO-consistent-with-open-wrt-newlines.patch

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

From report at bugs.python.org  Mon Mar  9 02:03:12 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 09 Mar 2009 01:03:12 +0000
Subject: [New-bugs-announce] [issue5452] Documentation for io.StringIO has
	wrong info for arguments
In-Reply-To: <1236560592.13.0.29473692422.issue5452@psf.upfronthosting.co.za>
Message-ID: <1236560592.13.0.29473692422.issue5452@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

(this is redirecting from http://bugs.python.org/issue5451). The 
documentation for io.StringIO is incorrect on the arguments. First off, it 
doesn't actually accept the "encoding" and "errors" arguments. Second, 
it's not stated that the default "newline" argument is "\n", as opposed to 
it's parent class TextIOWrapper, which defaults to None.

----------
assignee: georg.brandl
components: Documentation
message_count: 1.0
messages: 83345
nosy: erickt, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: Documentation for io.StringIO has wrong info for arguments
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar  9 03:02:26 2009
From: report at bugs.python.org (dariusp)
Date: Mon, 09 Mar 2009 02:02:26 +0000
Subject: [New-bugs-announce] [issue5453] pydoc -k fails (release30-maint
	patch)
In-Reply-To: <1236564146.1.0.579118375216.issue5453@psf.upfronthosting.co.za>
Message-ID: <1236564146.1.0.579118375216.issue5453@psf.upfronthosting.co.za>


New submission from dariusp <dariusp at internode.on.net>:

pydoc -k fails for both release30-maint and py3k.

In release30-maint the python io module (or more accurately the
underlying codecs module used by the io module) raises a
LookupError if the encoding is invalid.  There is a test module
with a deliberate encoding misspelled as "uft-8".  In py3k the C
io module doesn't raise this exception.

In addition both release30-maint and py3k raise a SyntaxError if
the BOM is invalid.  Again there is a test module with an invalid
BOM.

The only difference between the patch for release30-maint and the
patch for py3k is that py3k doesn't catch LookupError since the C
io module doesn't raise it.

Apart from that, pkgutil.py handles SyntaxError the same as
ImportError and returns None.  pydoc.py handles receiving the
None and also handles the LookupError the same as
UnicodeDecodeError.

A test was added to test_pydoc.py to ensure that a keyword search
sends text to stdout and nothing to stderr.


Before (release30-maint):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/local/lib/python3.0/pydoc.py", line 2260, in cli
    apropos(val)
  File "/usr/local/lib/python3.0/pydoc.py", line 1966, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "/usr/local/lib/python3.0/pydoc.py", line 1928, in run
    source = loader.get_source(modname)
  File "/usr/local/lib/python3.0/pkgutil.py", line 293, in get_source
    self.source = self.file.read()
  File "/usr/local/lib/python3.0/io.py", line 1724, in read
    decoder = self._decoder or self._get_decoder()
  File "/usr/local/lib/python3.0/io.py", line 1509, in _get_decoder
    make_decoder = codecs.getincrementaldecoder(self._encoding)
  File "/usr/local/lib/python3.0/codecs.py", line 960, in
getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: uft-8


After (release30-maint):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
test.test_colorsys 
test.test_largefile - Test largefile support on system where this makes
sense.
test.test_sys 
test.test_syslog 
warnings - Python part of the warnings subsystem.
syslog 


Before (py3k):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
importlib.test.import_.test_caching - Test that sys.modules is used
properly by import.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/local/lib/python3.1/pydoc.py", line 2260, in cli
    apropos(val)
  File "/usr/local/lib/python3.1/pydoc.py", line 1966, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "/usr/local/lib/python3.1/pydoc.py", line 1925, in run
    loader = importer.find_module(modname)
  File "/usr/local/lib/python3.1/pkgutil.py", line 183, in find_module
    file, filename, etc = imp.find_module(subname, path)
SyntaxError: encoding problem: with BOM


After (py3k):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
importlib.test.import_.test_caching - Test that sys.modules is used
properly by import.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
test.test_colorsys 
test.test_largefile - Test largefile support on system where this makes
sense.
test.test_sys 
test.test_syslog 
warnings - Python part of the warnings subsystem.
syslog

----------
components: Library (Lib)
files: pydoc-keyword-search-patch-release30-maint.diff
keywords: patch
message_count: 1.0
messages: 83347
nosy: dariusp
nosy_count: 1.0
severity: normal
status: open
title: pydoc -k fails (release30-maint patch)
type: crash
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13277/pydoc-keyword-search-patch-release30-maint.diff

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

From report at bugs.python.org  Mon Mar  9 03:06:20 2009
From: report at bugs.python.org (dariusp)
Date: Mon, 09 Mar 2009 02:06:20 +0000
Subject: [New-bugs-announce] [issue5454] pydoc -k fails (py3k patch)
In-Reply-To: <1236564380.19.0.502429557812.issue5454@psf.upfronthosting.co.za>
Message-ID: <1236564380.19.0.502429557812.issue5454@psf.upfronthosting.co.za>


New submission from dariusp <dariusp at internode.on.net>:

Apologies for the duplicate issue, but I wanted to supply two
patches (one for release30-maint and one for py3k) and appears
that each issue can only have one file.


pydoc -k fails for both release30-maint and py3k.

In release30-maint the python io module (or more accurately the
underlying codecs module used by the io module) raises a
LookupError if the encoding is invalid.  There is a test module
with a deliberate encoding misspelled as "uft-8".  In py3k the C
io module doesn't raise this exception.

In addition both release30-maint and py3k raise a SyntaxError if
the BOM is invalid.  Again there is a test module with an invalid
BOM.

The only difference between the patch for release30-maint and the
patch for py3k is that py3k doesn't catch LookupError since the C
io module doesn't raise it.

Apart from that, pkgutil.py handles SyntaxError the same as
ImportError and returns None.  pydoc.py handles receiving the
None and also handles the LookupError the same as
UnicodeDecodeError.

A test was added to test_pydoc.py to ensure that a keyword search
sends text to stdout and nothing to stderr.


Before (release30-maint):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/local/lib/python3.0/pydoc.py", line 2260, in cli
    apropos(val)
  File "/usr/local/lib/python3.0/pydoc.py", line 1966, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "/usr/local/lib/python3.0/pydoc.py", line 1928, in run
    source = loader.get_source(modname)
  File "/usr/local/lib/python3.0/pkgutil.py", line 293, in get_source
    self.source = self.file.read()
  File "/usr/local/lib/python3.0/io.py", line 1724, in read
    decoder = self._decoder or self._get_decoder()
  File "/usr/local/lib/python3.0/io.py", line 1509, in _get_decoder
    make_decoder = codecs.getincrementaldecoder(self._encoding)
  File "/usr/local/lib/python3.0/codecs.py", line 960, in
getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: uft-8


After (release30-maint):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
test.test_colorsys 
test.test_largefile - Test largefile support on system where this makes
sense.
test.test_sys 
test.test_syslog 
warnings - Python part of the warnings subsystem.
syslog 


Before (py3k):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
importlib.test.import_.test_caching - Test that sys.modules is used
properly by import.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/local/lib/python3.1/pydoc.py", line 2260, in cli
    apropos(val)
  File "/usr/local/lib/python3.1/pydoc.py", line 1966, in apropos
    ModuleScanner().run(callback, key, onerror=onerror)
  File "/usr/local/lib/python3.1/pydoc.py", line 1925, in run
    loader = importer.find_module(modname)
  File "/usr/local/lib/python3.1/pkgutil.py", line 183, in find_module
    file, filename, etc = imp.find_module(subname, path)
SyntaxError: encoding problem: with BOM


After (py3k):

$ pydoc -k sys
errno - This module makes available standard errno system symbols.
posix - This module provides access to operating system functionality
that is
sys - This module provides access to some objects used or maintained by the
colorsys - Conversion functions between RGB and other color systems.
distutils.sysconfig - Provide access to Python's configuration
information.  The specific
distutils.tests.test_sysconfig - Tests for distutils.dist.
importlib.test.import_.test_caching - Test that sys.modules is used
properly by import.
lib2to3.fixes.fix_sys_exc - Fixer for sys.exc_{type, value, traceback}
os - OS routines for Mac, NT, or Posix depending on what system we're on.
site - Append module search paths for third-party packages to sys.path.
test.test_colorsys 
test.test_largefile - Test largefile support on system where this makes
sense.
test.test_sys 
test.test_syslog 
warnings - Python part of the warnings subsystem.
syslog

----------
components: Library (Lib)
files: pydoc-keyword-search-patch-py3k.diff
keywords: patch
message_count: 1.0
messages: 83349
nosy: dariusp
nosy_count: 1.0
severity: normal
status: open
title: pydoc -k fails (py3k patch)
type: crash
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13278/pydoc-keyword-search-patch-py3k.diff

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

From report at bugs.python.org  Mon Mar  9 03:48:39 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 09 Mar 2009 02:48:39 +0000
Subject: [New-bugs-announce] [issue5455] csv module no longer works as
	expected when file opened in binary mode
In-Reply-To: <1236566919.88.0.376307932068.issue5455@psf.upfronthosting.co.za>
Message-ID: <1236566919.88.0.376307932068.issue5455@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I just discovered that the csv module's reader class in 3.x doesn't work
as expected when used as documented.  The requirement has always been
that the CSV file is opened in binary mode so that embedded newlines in
fields are screwed up.  Alas, in 3.x files opened in binary mode return
their contents as bytes, not unicode strings which are apparently not
allowed by the next() builtin:

% python3.1
Python 3.1a0 (py3k:70084M, Feb 28 2009, 20:46:48) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv    
>>> next(csv.reader(open("f.csv", "rb")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_csv.Error: iterator should return strings, not bytes (did you open the 
file in text mode?)
>>> next(csv.reader(open("f.csv", "r")))
['col1', 'col2', 'color']

At the very least the documentation for the csv.reader class is no
longer correct.  However, I can't see how you can open a CSV file in
text mode and not screw up embedded newlines.  I think binary mode
*has* to stay and some other way of dealing with bytes has to be found.

----------
components: Library (Lib)
message_count: 1.0
messages: 83350
nosy: skip.montanaro
nosy_count: 1.0
severity: normal
status: open
title: csv module no longer works as expected when file opened in binary mode
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  9 04:05:31 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 09 Mar 2009 03:05:31 +0000
Subject: [New-bugs-announce] [issue5456] io.StringIO's universal newlines
	support is broken in 3.0.1
In-Reply-To: <1236567931.99.0.98085182563.issue5456@psf.upfronthosting.co.za>
Message-ID: <1236567931.99.0.98085182563.issue5456@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Python version 3.0.1's io.StringIO has a bug when trying to use 
universal newlines on the mac. It's fixed in 3.1a1 though. Here's the 
exception:

>>> io.StringIO('hello there\r\nlela\r\n', newline=None).readlines()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 536, in readlines
    return list(self)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 523, in __next__
    line = self.readline()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 2110, in readline
    more_line = self.read(self._CHUNK_SIZE)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 2007, in read
    res = self._decode_newlines(self._read(n), True)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 1953, in _decode_newlines
    return output
UnboundLocalError: local variable 'output' referenced before assignment


The broken code is this:

            if self._readtranslate:
                if crlf:
                    output = input.replace("\r\n", "\n")
                if cr:
                    output = input.replace("\r", "\n")
            else:
                output = input

It appears to fix the problem if we do this:

            output = input
            if self._readtranslate:
                if crlf:
                    output = output.replace("\r\n", "\n")
                if cr:
                    output = output.replace("\r", "\n")

----------
components: Library (Lib)
message_count: 1.0
messages: 83352
nosy: erickt
nosy_count: 1.0
severity: normal
status: open
title: io.StringIO's universal newlines support is broken in 3.0.1
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Mar  9 10:38:32 2009
From: report at bugs.python.org (Christian Theune)
Date: Mon, 09 Mar 2009 09:38:32 +0000
Subject: [New-bugs-announce] [issue5457] ZipFile writes incorrect
	modification time (second is off-by-one)
In-Reply-To: <1236591512.01.0.852258757862.issue5457@psf.upfronthosting.co.za>
Message-ID: <1236591512.01.0.852258757862.issue5457@psf.upfronthosting.co.za>


New submission from Christian Theune <ct at gocept.com>:

See the attached unit test. On seconds that are > 0 and < 60 the written
second is reduced by 1.

(The test doesn't explicitly prove that this happens during writing, but
we checked this manually. The read function is fine.)

----------
components: Library (Lib)
files: zipbug.py
message_count: 1.0
messages: 83364
nosy: ctheune
nosy_count: 1.0
severity: normal
status: open
title: ZipFile writes incorrect modification time (second is off-by-one)
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13281/zipbug.py

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

From report at bugs.python.org  Mon Mar  9 11:31:13 2009
From: report at bugs.python.org (Eyal Gordon)
Date: Mon, 09 Mar 2009 10:31:13 +0000
Subject: [New-bugs-announce] [issue5458] threading.Thread.join()
	documentation: missing 'from version' for RuntimeError exceptions
In-Reply-To: <1236594673.49.0.326177093971.issue5458@psf.upfronthosting.co.za>
Message-ID: <1236594673.49.0.326177093971.issue5458@psf.upfronthosting.co.za>


New submission from Eyal Gordon <eyal.gordon at gmail.com>:

In threading documentation:
http://www.python.org/doc/current/library/threading.html?highlight=threading#threading.Thread.join

It is not specified from which python version the join() call raises the
RuntimeError exception. In python version 2.4.3 join asserts on such
conditions.

----------
assignee: georg.brandl
components: Documentation
message_count: 1.0
messages: 83367
nosy: eyal.gordon, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: threading.Thread.join() documentation: missing 'from version' for RuntimeError exceptions
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar  9 20:00:14 2009
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 09 Mar 2009 19:00:14 +0000
Subject: [New-bugs-announce] [issue5460] Python 3.0 grammar is ambiguous
	with the addition of star_expr
In-Reply-To: <1236625214.13.0.530481898617.issue5460@psf.upfronthosting.co.za>
Message-ID: <1236625214.13.0.530481898617.issue5460@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Note: A discussion related to this bug was raised on:
http://mail.python.org/pipermail/python-dev/2009-March/086939.html

The following constructs are ambiguous in the Python 3.0 grammar:

arglist: (argument ',')*
                        (argument [',']
                         |'*' test (',' argument)* [',' '**' test]
                         |'**' test
                         )

argument: test [comp_for]
test: or_test
or_test: and_test
and_test: not_test
not_test: 'not' not_test | comparison
comparison: star_expr
star_expr: ['*'] expr


So, with that construct, having call(arglist) in a format:

call(*test), the grammar would find it to be consumed in the argument
construction (because of the star_expr) and not in the arglist in the
'*' test.

Python seems to be lucky in this because it seems to be getting in the
correct choice, when that's not really possible from the grammar --
maybe it tries the 2nd construct before the 1st and succeeds because of
that? It seems to me that this could actually be a bug in the Python
grammar generator. 

It doesn't seem possible to disambiguate that without semantic actions
later on, but the grammar could be changed to disambiguate that.

I've used the constructs below in a JavaCC grammar successfully (and I
think Python could use the same constructs):

expr_stmt: testlist_star_expr (augassign (yield_expr|testlist) |
                     ('=' (yield_expr|testlist_star_expr))*)
					 
testlist_star_expr: (test|star_expr) (',' test|star_expr)* [',']

star_expr: '*' expr

----------
components: Interpreter Core
message_count: 1.0
messages: 83395
nosy: fabioz
nosy_count: 1.0
severity: normal
status: open
title: Python 3.0 grammar is ambiguous with the addition of star_expr
type: feature request
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  9 20:22:43 2009
From: report at bugs.python.org (David Ripton)
Date: Mon, 09 Mar 2009 19:22:43 +0000
Subject: [New-bugs-announce] [issue5461] python3 symlink
In-Reply-To: <1236626563.57.0.797071883805.issue5461@psf.upfronthosting.co.za>
Message-ID: <1236626563.57.0.797071883805.issue5461@psf.upfronthosting.co.za>


New submission from David Ripton <d+python at ripton.net>:

When Python 2.x is manually installed on Linux, a python2 symlink is
created, like this:

lrwxrwxrwx 1 root root 9 Jan 24 00:03 /usr/bin/python2 -> python2.6

("make install" updates the symlink; "make altinstall" does not).

When Python 3.x is installed, no python3 symlink is created.

For Python 2.x, one had a choice of #!/usr/bin/python,
#!/usr/bin/python2, or #!/usr/bin/python2.6 for shebang line.

For Python 3.x, the middle choice is lost.  This seems like a small
regression.

----------
components: Installation
message_count: 1.0
messages: 83400
nosy: dripton
nosy_count: 1.0
severity: normal
status: open
title: python3 symlink
type: feature request
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  9 21:47:55 2009
From: report at bugs.python.org (Julie Earls)
Date: Mon, 09 Mar 2009 20:47:55 +0000
Subject: [New-bugs-announce] [issue5462] Pythonwin Vista Compatibility
In-Reply-To: <1236631675.9.0.0916261345881.issue5462@psf.upfronthosting.co.za>
Message-ID: <1236631675.9.0.0916261345881.issue5462@psf.upfronthosting.co.za>


New submission from Julie Earls <jearls at mail.usf.edu>:

Hello-

I am trying to install a version of Python that includes Pythonwin and 
is compatible with a 32-bit Winsows Vista computer.  Can anyone tell me 
which version works?  I have tried several and so far no luck.

Thanks

----------
components: Windows
message_count: 1.0
messages: 83402
nosy: jearls
nosy_count: 1.0
severity: normal
status: open
title: Pythonwin Vista Compatibility
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar  9 22:17:20 2009
From: report at bugs.python.org (Andreas Schawo)
Date: Mon, 09 Mar 2009 21:17:20 +0000
Subject: [New-bugs-announce] [issue5463] Compiler warning get_ulong is never
	used 3.x
In-Reply-To: <1236633440.53.0.769324137007.issue5463@psf.upfronthosting.co.za>
Message-ID: <1236633440.53.0.769324137007.issue5463@psf.upfronthosting.co.za>


New submission from Andreas Schawo <andreas at schawo.de>:

When compiling the newest 3.x trunk I've got a compiler warning that
get_ulong is defined but never used.

I moved the function near the only place where it is used (disabled code).

Now I have no more warnings.

I don't know if it's of any use.

----------
components: Extension Modules
files: get_ulong_patch.diff
keywords: patch
message_count: 1.0
messages: 83406
nosy: andreas.schawo
nosy_count: 1.0
severity: normal
status: open
title: Compiler warning get_ulong is never used 3.x
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file13288/get_ulong_patch.diff

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

From report at bugs.python.org  Mon Mar  9 22:47:10 2009
From: report at bugs.python.org (Stephen George)
Date: Mon, 09 Mar 2009 21:47:10 +0000
Subject: [New-bugs-announce] [issue5464] msgfmt.py does not work with plural
	form
In-Reply-To: <1236635230.35.0.0644981096799.issue5464@psf.upfronthosting.co.za>
Message-ID: <1236635230.35.0.0644981096799.issue5464@psf.upfronthosting.co.za>


New submission from Stephen George <steve_geo at optusnet.com.au>:

It seems that C:\Python26\Tools\i18n\msgfmt.py does not work with PO
files that use plural form. Get the following error.
ERROR    Traceback (most recent call last):
  File "C:\Python26\Tools\i18n\msgfmt.py", line 203, in <module>
    main()
  File "C:\Python26\Tools\i18n\msgfmt.py", line 199, in main
    make(filename, outfile)
  File "C:\Python26\Tools\i18n\msgfmt.py", line 151, in make
    l = eval(l)
  File "<string>", line 1
    _plural "%d generations"
                          ^
SyntaxError: invalid syntax

----------
components: Demos and Tools
files: de.po
message_count: 1.0
messages: 83407
nosy: steve_geo
nosy_count: 1.0
severity: normal
status: open
title: msgfmt.py does not work with plural form
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13289/de.po

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

From report at bugs.python.org  Tue Mar 10 03:44:38 2009
From: report at bugs.python.org (Eddie Slimak)
Date: Tue, 10 Mar 2009 02:44:38 +0000
Subject: [New-bugs-announce] [issue5465] No edit in IDLE in right click
	context menu
In-Reply-To: <1236653078.99.0.544160626901.issue5465@psf.upfronthosting.co.za>
Message-ID: <1236653078.99.0.544160626901.issue5465@psf.upfronthosting.co.za>


New submission from Eddie Slimak <jeslimak at gmail.com>:

I was mucking around attempting to get WConio working and so had an
installation for both python 2.5 and 2.6 at the same time.  After I
uninstalled python 2.5 windows somehow stopped associating .py files
with python.

----------
components: IDLE, Windows
message_count: 1.0
messages: 83412
nosy: ESlim
nosy_count: 1.0
severity: normal
status: open
title: No edit in IDLE in right click context menu
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar 10 13:17:40 2009
From: report at bugs.python.org (Andrew Gregory)
Date: Tue, 10 Mar 2009 12:17:40 +0000
Subject: [New-bugs-announce] [issue5466] Tix.Balloon causes TCLError:
	unknown color name "{#ffff60}" in Python 2.6.1
In-Reply-To: <1236687460.92.0.36885933672.issue5466@psf.upfronthosting.co.za>
Message-ID: <1236687460.92.0.36885933672.issue5466@psf.upfronthosting.co.za>


New submission from Andrew Gregory <andrew.gregory at npl.co.uk>:

All programs using Tix.Balloon in Python 2.6.1 (Windows XP) crash when 
a Tix.Balloon object is created. The Balloon.py Tix demo is supplied as 
an example.

Andrew.

----------
components: Tkinter
files: Balloon.py
message_count: 1.0
messages: 83430
nosy: andrewp22
nosy_count: 1.0
severity: normal
status: open
title: Tix.Balloon causes TCLError: unknown color name "{#ffff60}" in Python 2.6.1
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13292/Balloon.py

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

From report at bugs.python.org  Tue Mar 10 15:11:55 2009
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Mar 2009 14:11:55 +0000
Subject: [New-bugs-announce] [issue5467] tools\msi\merge.py is sensitive to
	lack of config.py
In-Reply-To: <1236694315.39.0.154575641767.issue5467@psf.upfronthosting.co.za>
Message-ID: <1236694315.39.0.154575641767.issue5467@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

tools\msi\merge.py attempts to import config and fails with an
ImportError if it doesn't exist (which it doesn't by default). msi.py
catches this exception and ignores it.

The attached patch carries the same behaviour over to merge.py

----------
components: Installation
files: merge.patch
keywords: patch
message_count: 1.0
messages: 83433
nosy: tim.golden
nosy_count: 1.0
severity: normal
status: open
title: tools\msi\merge.py is sensitive to lack of config.py
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13293/merge.patch

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

From report at bugs.python.org  Tue Mar 10 15:45:16 2009
From: report at bugs.python.org (Dan Mahn)
Date: Tue, 10 Mar 2009 14:45:16 +0000
Subject: [New-bugs-announce] [issue5468] urlencode does not handle "bytes",
	and could easily handle alternate encodings
In-Reply-To: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>
Message-ID: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>


New submission from Dan Mahn <dan.mahn at digidescorp.com>:

urllib.parse.urlencode() uses quote_plus() extensively to create a
complete query string, but doesn't effectively/properly take advantage
of the flexibility built into quote_plus().  Namely:

1) Instances of type "bytes" are not properly encoded, as str() is used
prior to passing to quote_plus().  This creates a nonsensical string
such as b'1234', while quote_plus() can handle these types properly if
passed intact.  The ability to encode this type is particularly useful
for putting binary data into the query string, or for pre-encoded text
which you may want to encode in a non-standard character encoding.

2) Sometimes it would be desirable to encode query strings entirely in
"latin-1" or possibly "ascii" instead of "utf-8".  Adding the extra
parameters now present on quote_plus() can easily give that extra
functionality.

I have attached a new version of urlencode() that provides both of the
above fixes/enhancements.  Additionally, an unused codepath in the
existing function has been eliminated/cleaned up.  Some doctests are
included as well.

----------
components: Library (Lib)
files: new_urlencode.py
message_count: 1.0
messages: 83434
nosy: dmahn
nosy_count: 1.0
severity: normal
status: open
title: urlencode does not handle "bytes", and could easily handle alternate encodings
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13294/new_urlencode.py

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

From report at bugs.python.org  Tue Mar 10 17:59:50 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 10 Mar 2009 16:59:50 +0000
Subject: [New-bugs-announce] [issue5469] Reference paragraph about the
	constructs that bind names needs updating for Python 3
In-Reply-To: <1236704390.32.0.698658997265.issue5469@psf.upfronthosting.co.za>
Message-ID: <1236704390.32.0.698658997265.issue5469@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the Python Language Reference, in the Naming and binding section of 
Execution Model, there is a paragraph that states:

The following constructs bind names: formal parameters to functions, 
import statements, class and function definitions (these bind the class 
or function name in the defining block), and targets that are 
identifiers if occurring in an assignment, for loop header, or in the 
second position of an except clause header. The import statement of the 
form ?from ...import *? binds all names defined in the imported module, 
except those beginning with an underscore. This form may only be used at 
the module level.

This misdescribes the except clause, which now uses "as", and omits the 
"with ... as" construct which also binds names.

----------
assignee: georg.brandl
components: Documentation
message_count: 1.0
messages: 83439
nosy: MLModel, georg.brandl
nosy_count: 2.0
severity: normal
status: open
title: Reference paragraph about the constructs that bind names needs updating for Python 3
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 10 18:05:13 2009
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Mar 2009 17:05:13 +0000
Subject: [New-bugs-announce] [issue5470] MSI installer misses zipdir.zip
	file in Lib\test
In-Reply-To: <1236704713.71.0.795823631214.issue5470@psf.upfronthosting.co.za>
Message-ID: <1236704713.71.0.795823631214.issue5470@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

The msi.py determines which files to carry over into the installer for
the lib\test directory. zipdir.zip was added recently for test_zipfile
and this isn't picked up. The attached patch adds it in.

----------
components: Installation
files: msi-zipdir.patch
keywords: patch
message_count: 1.0
messages: 83440
nosy: tim.golden
nosy_count: 1.0
severity: normal
status: open
title: MSI installer misses zipdir.zip file in Lib\test
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13295/msi-zipdir.patch

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

From report at bugs.python.org  Tue Mar 10 20:16:15 2009
From: report at bugs.python.org (pancake)
Date: Tue, 10 Mar 2009 19:16:15 +0000
Subject: [New-bugs-announce] [issue5471] os.path.expanduser('~') doesnt
	works correctly when HOME is '/'
In-Reply-To: <1236712575.55.0.379860744016.issue5471@psf.upfronthosting.co.za>
Message-ID: <1236712575.55.0.379860744016.issue5471@psf.upfronthosting.co.za>


New submission from pancake <pancake at nopcode.org>:

When the HOME path is just '/' python says that the home path is ""
(zero length string)

I was able to reproduce this issue in 2.5.2 and 2.6 (no idea about 3.0)

Here's an example:

$ HOME=/ python -c 'import os;print os.path.expanduser("~")'

$ HOME=/tmp python -c 'import os;print os.path.expanduser("~")'
/tmp

$ HOME=a python -c 'import os;print os.path.expanduser("~")'
a

------8<----------

I just used "if !os.path.isdir(os.path.expanduser('~')):" check in
my application to avoid messing around the resulting paths when the
application runs.

The correct response should be '/' instead of ''.

----------
components: None
message_count: 1.0
messages: 83445
nosy: pancake
nosy_count: 1.0
severity: normal
status: open
title: os.path.expanduser('~') doesnt works correctly when HOME is '/'
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 11 00:16:38 2009
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Mar 2009 23:16:38 +0000
Subject: [New-bugs-announce] [issue5472] distutils.test_util fails to
	restore os.uname
In-Reply-To: <49B6F4D0.2020103@timgolden.me.uk>
Message-ID: <49B6F4D0.2020103@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

lib\distutils\tests\test_util.py, run as part of the full testsuite, 
creates a stub os.uname on an OS which doesn't support it natively.
However, it fails to restore it correctly -- ie fails to delete the
attribute. As a result, test_platform and test_pep352 fail when run
as a part of regrtest, since they rely on os.uname raising an
AttributeError on, eg, Windows.

Patch attached against r70302 of lib\distutils\tests\test_util.py

----------
files: test_util.patch
keywords: patch
messages: 83449
nosy: tim.golden
severity: normal
status: open
title: distutils.test_util fails to restore os.uname
Added file: http://bugs.python.org/file13299/test_util.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5472>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_util.patch
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20090310/be729a4e/attachment-0001.txt>

From report at bugs.python.org  Wed Mar 11 00:18:54 2009
From: report at bugs.python.org (Christian Taylor)
Date: Tue, 10 Mar 2009 23:18:54 +0000
Subject: [New-bugs-announce] [issue5473] round(float,
	ndigits<0) sometimes rounds to odd
In-Reply-To: <1236727134.95.0.532046507723.issue5473@psf.upfronthosting.co.za>
Message-ID: <1236727134.95.0.532046507723.issue5473@psf.upfronthosting.co.za>


New submission from Christian Taylor <dingo at chello.at>:

round(x, n) may unexpectedly round floats upwards to odd multiples of
10**(-n) if n is negative, depending on the system Python 3 is running
on. I think this is distinct from issue 1869.

Example:
>>> round(25.0, -1)
30.0

I used the following function to check 1000 cases for a given exponent
and yield the values where rounding to odd occurs:

def check(exponent):
    factor = 10**exponent
    for x in range(5, 5+20000, 20):
        if not round(float(x*factor), -1-exponent) < x*factor:
            yield float(x*factor)

On a Core2 Duo running Arch Linux (32bit):
Python 3.1a1+ (py3k:70302, Mar 10 2009, 21:43:09)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [len(list(check(exponent))) for exponent in range(10)]
[1000, 1000, 1000, 1000, 1000, 0, 0, 1000, 1000, 1000]

On an Athlon XP running Slackware (32bit):
Python 3.1a1+ (py3k:70302, Mar 11 2009, 01:01:18)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [len(list(check(exponent))) for exponent in range(10)]
[1000, 1000, 1000, 1000, 1000, 0, 0, 1000, 1000, 1000]

On an Athlon 64 running Debian (32bit):
Python 3.1a1+ (py3k:70302, Mar 10 2009, 22:45:59)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [len(list(check(exponent))) for exponent in range(10)]
[0, 0, 0, 0, 630, 0, 0, 0, 195, 0]
>>> next(check(4))
650000.0
>>> next(check(8))
14500000000.0

----------
components: Interpreter Core
messages: 83450
nosy: dingo
severity: normal
status: open
title: round(float, ndigits<0) sometimes rounds to odd
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Mar 11 05:15:19 2009
From: report at bugs.python.org (Rudd-O)
Date: Wed, 11 Mar 2009 04:15:19 +0000
Subject: [New-bugs-announce] [issue5474] distutils produces invalid RPM
	packages of prerelease python packages
In-Reply-To: <1236744919.07.0.603710480384.issue5474@psf.upfronthosting.co.za>
Message-ID: <1236744919.07.0.603710480384.issue5474@psf.upfronthosting.co.za>


New submission from Rudd-O <rudd-o at rudd-o.com>:

Description of problem:

Building pre-release python distutils packages with python setup.py
bdist_rpm
works, but the version number is "RPM-higher" than the official release
package
that is released later.

This constitutes a problem because many of the components in major
Python apps
like Zope -- distributed as cheese shop eggs and downloadable via pip or
buildout -- are pre-release packages which, when turned into RPMs, contain
RPM-invalid version numbers.  The RPMs build, but the pre-release
packages are
considered "newer" by yum, so you can imagine the havoc that breaks.

How reproducible:

always


Steps to Reproduce:
1. python setup.py bdist_rpm
2. inspect version / release number of resulting RPMs, find out it's wrong
3. do not profit!

Actual results:

distutils package version: 1.4a
rpm package version: 1.4a


Expected results:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release

Additional info:

patch attached.  works against python 2.4, may apply fine to python 2.5
or 2.6
too since distutils hasn't undergone that big of a rewrite.  

Ojo: the patch has been tested with distutils AND setuptools.

----------
assignee: tarek
components: Distutils
files: distutils-bdist_rpm-prereleaseversion.patch
keywords: patch
messages: 83454
nosy: Rudd-O, tarek
severity: normal
status: open
title: distutils produces invalid RPM packages of prerelease python packages
versions: Python 2.4
Added file: http://bugs.python.org/file13300/distutils-bdist_rpm-prereleaseversion.patch

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

From report at bugs.python.org  Wed Mar 11 11:14:55 2009
From: report at bugs.python.org (Tim Michelsen)
Date: Wed, 11 Mar 2009 10:14:55 +0000
Subject: [New-bugs-announce] [issue5475] urllib2.getproxies not documented
In-Reply-To: <1236766495.94.0.773728136477.issue5475@psf.upfronthosting.co.za>
Message-ID: <1236766495.94.0.773728136477.issue5475@psf.upfronthosting.co.za>


New submission from Tim Michelsen <timmichelsen at gmx-topmail.de>:

There is no documentation for the function 


in
http://docs.python.org/search.html?q=getproxies&check_keywords=yes&area=default

But the docstring shows:
ul.getproxies?
Type:           function
Base Class:     <type 'function'>
String Form:    <function getproxies at 0x01096EF0>
Namespace:      Interactive
File:           c:\programme\pythonxy\python\lib\urllib.py
Definition:     ul.getproxies()
Docstring:
    Return a dictionary of scheme -> proxy server URL mappings.

Returns settings gathered from the environment, if specified,
or the registry.

----------
assignee: georg.brandl
components: Documentation
messages: 83464
nosy: georg.brandl, timmie
severity: normal
status: open
title: urllib2.getproxies not documented
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 11 16:50:47 2009
From: report at bugs.python.org (Barron Henderson)
Date: Wed, 11 Mar 2009 15:50:47 +0000
Subject: [New-bugs-announce] [issue5476] datetime: timedelta(minutes = i)
	silently fails with numpy.int32 input
In-Reply-To: <1236786647.39.0.745171492116.issue5476@psf.upfronthosting.co.za>
Message-ID: <1236786647.39.0.745171492116.issue5476@psf.upfronthosting.co.za>


New submission from Barron Henderson <barronh at gmail.com>:

Initializing a timedelta object with numpy.int32 arguments give mixed
results; it fails for days keyword, gives bad results for minutes, and
give correct results for seconds/microseconds.  Failure confirmed on
Linux i686 (Py 2.5.2; numpy 1.2.1) and OS X 10.5.6 (Py 2.5.1;
1.2.1).Test case below:

from datetime import timedelta
from numpy import int32
from numpy import int32
from datetime import timedelta

assert timedelta(seconds = 36) == timedelta(seconds = int32(36))
print 'pass 36 sec'
assert timedelta(microseconds = 36) == timedelta(microseconds = int32(36))
print 'pass 36 usec'
assert timedelta(minutes = 35) == timedelta(minutes = int32(35))
print 'pass 35 min'
assert timedelta(minutes = 36) == timedelta(minutes = int32(36))
print 'pass 36 min' # returns bad value
assert timedelta(days = 36) == timedelta(days = int32(36))
print 'pass 36 days' # fails SystemError: Objects/longobject.c:223

----------
messages: 83470
nosy: barronh
severity: normal
status: open
title: datetime: timedelta(minutes = i) silently fails with numpy.int32 input

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

From report at bugs.python.org  Wed Mar 11 17:10:08 2009
From: report at bugs.python.org (Thomas Guest)
Date: Wed, 11 Mar 2009 16:10:08 +0000
Subject: [New-bugs-announce] [issue5477] Typo in itertools documentation
In-Reply-To: <1236787808.63.0.125744634711.issue5477@psf.upfronthosting.co.za>
Message-ID: <1236787808.63.0.125744634711.issue5477@psf.upfronthosting.co.za>


New submission from Thomas Guest <tag at wordaligned.org>:

http://docs.python.org/3.0/library/itertools.html says:

> The tools also work well with the high-speed functions in the operator
module. For example, the plus-operator can be mapped across two vectors
to form an efficient dot-product: sum(map(operator.add, vector1, vector2)).

I think there are two problems here.

1. I think this should read: "the multiplication operator ...
sum(map(operator.mul, vector1, vector2))."

2. This example has nothing to do with itertools! (At 3.n, map is a
built in function)

----------
assignee: georg.brandl
components: Documentation
messages: 83472
nosy: georg.brandl, thomasguest
severity: normal
status: open
title: Typo in itertools documentation
versions: Python 3.0

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

From report at bugs.python.org  Thu Mar 12 01:16:14 2009
From: report at bugs.python.org (Kouki Hashimoto)
Date: Thu, 12 Mar 2009 00:16:14 +0000
Subject: [New-bugs-announce] [issue5478] document mistake
	xml.dom.minidom.Element
In-Reply-To: <1236816974.37.0.966826029984.issue5478@psf.upfronthosting.co.za>
Message-ID: <1236816974.37.0.966826029984.issue5478@psf.upfronthosting.co.za>


New submission from Kouki Hashimoto <hsmtkk at gmail.com>:

I found mistake in python documentation about xml.dom.minidom.Element 
class.
http://docs.python.org/dev/py3k/library/xml.dom.html#module-xml.dom

I think it is NOT
Element.getElementsByTagNameNS(tagName)
It SHOULD be
Element.getElementsByTagNameNS(namespaceURI, tagName)

----------
assignee: georg.brandl
components: Documentation
messages: 83482
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: document mistake xml.dom.minidom.Element
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar 12 09:18:37 2009
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Thu, 12 Mar 2009 08:18:37 +0000
Subject: [New-bugs-announce] [issue5479] Add an easy way to provide total
	ordering now that __cmp__ is deprecated/gone
In-Reply-To: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>
Message-ID: <1236845917.79.0.765415316549.issue5479@psf.upfronthosting.co.za>


New submission from Mart S?mermaa <mrts at mrts.pri.ee>:

See http://mail.python.org/pipermail/python-dev/2009-March/087000.html
and http://code.activestate.com/recipes/576685/ .

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 83490
nosy: georg.brandl, mrts, rhettinger
severity: normal
status: open
title: Add an easy way to provide total ordering now that __cmp__ is deprecated/gone
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Mar 12 16:27:05 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 12 Mar 2009 15:27:05 +0000
Subject: [New-bugs-announce] [issue5480] ".egg-info" => ".pkg-info"
In-Reply-To: <1236871625.96.0.687827007763.issue5480@psf.upfronthosting.co.za>
Message-ID: <1236871625.96.0.687827007763.issue5480@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

The .egg-info files which are produced by distutils in Python >= 2.5 are
the only standard, cross-platform way for a Python package
("distribution") to declare its name and version number in a
machine-parseable way.  Unfortunately, these files are named ".egg-info"
even when the Python package in question was produced by distutils
without setuptools, was never packaged as an egg, and is not installed
as an egg.  It has nothing to do with "egg".  The fact that the file has
"egg" in its name causes most people to think that it has something to
do with eggs, which leads to all sorts of problems including people
removing the file and thus deleting the machine-parseable metadata about
the Python package's name and version number.

This ticket is a request that distutils start calling this file
".pkg-info" instead.  Obviously we can't just stop including them under
the name ".egg-info" since that would break existing usage, but we could
start producing files under the name ".pkg-info", and make ".egg-info"
be a symlink or a copy of ".pkg-info" for backwards compatibility.  Also
of course we can update the documentation (if there is any) of what the
.pkg-info file is.  Since the current problems are mostly problems of
communication and documentation, this simple change to the name of the
file might go a long way to improving things.

----------
assignee: tarek
components: Distutils
messages: 83492
nosy: tarek, zooko
severity: normal
status: open
title: ".egg-info" => ".pkg-info"
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 12 21:00:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Mar 2009 20:00:27 +0000
Subject: [New-bugs-announce] [issue5481] Expand Decimal.__format__() support
	to include "n"
In-Reply-To: <1236888027.08.0.305136534993.issue5481@psf.upfronthosting.co.za>
Message-ID: <1236888027.08.0.305136534993.issue5481@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

>>> from decimal import Decimal as D
>>> format(D('1234.5'), "n")
 . . .
ValueError: Invalid format specifier: n

----------
assignee: marketdickinson
components: Library (Lib)
messages: 83500
nosy: marketdickinson, rhettinger
severity: normal
status: open
title: Expand Decimal.__format__() support to include "n"
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Mar 13 12:27:33 2009
From: report at bugs.python.org (Rudd-O)
Date: Fri, 13 Mar 2009 11:27:33 +0000
Subject: [New-bugs-announce] [issue5482] RFC: improve distutils bdist_rpm so
	it builds pure python modules as single packages that works
	across architectures
In-Reply-To: <1236943653.87.0.451270681282.issue5482@psf.upfronthosting.co.za>
Message-ID: <1236943653.87.0.451270681282.issue5482@psf.upfronthosting.co.za>


New submission from Rudd-O <rudd-o at rudd-o.com>:

Hello, guys.  I am looking for feedback on the topic which I am going to
lay out.  First, sys.path:

-------------------
# python2.4
>>> import sys
>>> sys.path
['', '/home/rudd-o', '/usr/lib64/python24.zip', '/usr/lib64/python2.4',
'/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk',
'/usr/lib64/python2.4/lib-dynload',
'/usr/lib64/python2.4/site-packages',
'/usr/lib64/python2.4/site-packages/Numeric',
'/usr/lib64/python2.4/site-packages/PIL',
'/usr/lib64/python2.4/site-packages/gtk-2.0',
'/usr/lib/python2.4/site-packages', '/usr/lib64/site-python',
'/usr/lib/site-python']
------------------

Now: Currently, bdist_rpm target builds RPMs that install to
/usr/lib(64)/python2.X/site-packages/.  This is wasteful and inefficient
in the case of pure python modules for the following reasons:

1. It necessitates a rebuild of the python modules for at least 2
architectures -- 64-bit and 32-bit, since they go to different
directories.  Worst part is, the packages themselves are
indistinguishable by name (they are built as Noarch in all
architectures) so a package built in 64bit cannot function in 32bit BUT
it is *installable* by RPM.
2. It necessitates a rebuild for every python minor version out there,
2.4, 2.5, 2.6.  This is also problematic because packages need to be
rebuilt for every distribution release out there, instead of being able
to build a single RPM that works across distro releases (or, the holy
grail, across distros altogether).

Now, I have familiarized myself with distutils enough that I can make a
quick patch that

- detects if the package is a pure python module
- ensures that the install-purelib directive in the [install] section of
setup.cfg is absent

and if both conditions are present, then the package is automatically
installed into /usr/lib/site-python.

The benefits are clear:

- only a single RPM needs to be built across distro versions and
architectures
- it enables cheese shop packages to be quickly built on a machine and
then installed in another
- it eliminates the need for the tedious process of writing custom spec
files
- packages built this way can be loaded and run by virtually all 2.x
python interpreters out there right now
- it would be possible to even build python RPMs that work across
distributions

This patch is no more than a two-liner, and I am looking for input, to
see if someone agrees, or not, to flesh out any pitfalls before going
in.  So do your best and provide sensible reasons why I should not do
this, or else I will do it and submit a patch.

Clock's ticking.

----------
assignee: tarek
components: Distutils
messages: 83513
nosy: Rudd-O, tarek
severity: normal
status: open
title: RFC: improve distutils bdist_rpm so it builds pure python modules as single packages that works across architectures
type: feature request

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

From report at bugs.python.org  Fri Mar 13 14:12:05 2009
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 13 Mar 2009 13:12:05 +0000
Subject: [New-bugs-announce] [issue5483] [PATCH]Add FastDbfilenameShelf:
	shelf nerver sync cache even when writeback=True
In-Reply-To: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>
Message-ID: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>


New submission from Zhigang Wang <w1z2g3 at gmail.com>:

shelf without writeback=True is too slow, while shelves with
writeback=True takes too much time to close. And even worse, these codes
can not run:

$ cat test_shelve.py
#!/usr/bin/env python

import shelve

store = shelve.open("/tmp/shelve.db", writeback=True)

class Test(object):
    pass

def main():
    store["a"] = Test()

if __name__ == '__main__':
    main()

$ python test_shelve.py 
Exception cPickle.PicklingError: "Can't pickle <class '__main__.Test'>:
it's not the same object as __main__.Test" in  ignored

With this module, we can make it to run.

I think it's worth add this function to shelve. We can achieve great
improvement with some avoidable limitations.

The other approach to add this function is to add a extra option the
shelve.open(). We can discuss for which is better.

----------
components: Library (Lib)
files: fast_shelf.patch
keywords: patch
messages: 83516
nosy: zhigang
severity: normal
status: open
title: [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache even when writeback=True
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file13317/fast_shelf.patch

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

From report at bugs.python.org  Fri Mar 13 15:32:07 2009
From: report at bugs.python.org (Erik Sandberg)
Date: Fri, 13 Mar 2009 14:32:07 +0000
Subject: [New-bugs-announce] [issue5484] subprocess.call() fails for .bat
	files on Windows, if executable path contains parenthesis
In-Reply-To: <1236954727.06.0.0825252452212.issue5484@psf.upfronthosting.co.za>
Message-ID: <1236954727.06.0.0825252452212.issue5484@psf.upfronthosting.co.za>


New submission from Erik Sandberg <sandberg at virtutech.com>:

When subprocess.call is told to execute a .bat file on Windows, and the
path to the batch file is given as an absolute path, and the path
includes a left parenthesis ('('), then the call fails with a message
similar to the following; it appears that the parenthesis is incorrectly
quoted.

'c:\tmp\f' is not recognized as an internal or external command,
operable program or batch file.
Traceback (most recent call last):
  File "parenbug.py", line 7, in <module>
    subprocess.check_call(os.path.join(os.getcwd(), bat))
  File "c:\Python25\lib\subprocess.py", line 461, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'c:\tmp\f(o.bat' returned
non-zero exit status 1

I have reproduced this on Windows XP.

----------
components: Library (Lib), Windows
files: parenbug.py
messages: 83518
nosy: sandberg
severity: normal
status: open
title: subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file13319/parenbug.py

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

From report at bugs.python.org  Fri Mar 13 17:51:02 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 13 Mar 2009 16:51:02 +0000
Subject: [New-bugs-announce] [issue5485] pyexpat has no unit tests for
	UseForeignDTD functionality
In-Reply-To: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>
Message-ID: <1236963062.63.0.579203765421.issue5485@psf.upfronthosting.co.za>


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

Lacking unit tests for this (documented) functionality makes it harder
for alternate Python runtimes to correctly provide it.  Plus, if it's
not tested, it might not work.

I tried to write tests for the feature since I recently used it and
thought it would be pretty straightforward.  However, I failed.  expat
inscrutably refuses to call the external entity ref handler I provided
in my test.  Attached is my attempted, in case anyone feels like helping
complete it.

----------
components: Library (Lib), Tests, XML
files: use-foreign-dtd.patch
keywords: patch
messages: 83521
nosy: exarkun
severity: normal
status: open
title: pyexpat has no unit tests for UseForeignDTD functionality
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13320/use-foreign-dtd.patch

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

From report at bugs.python.org  Fri Mar 13 19:20:02 2009
From: report at bugs.python.org (DSM)
Date: Fri, 13 Mar 2009 18:20:02 +0000
Subject: [New-bugs-announce] [issue5486] doc copyedits
In-Reply-To: <1236968402.64.0.364958791658.issue5486@psf.upfronthosting.co.za>
Message-ID: <1236968402.64.0.364958791658.issue5486@psf.upfronthosting.co.za>


New submission from DSM <dsm001 at users.sourceforge.net>:

Handful of typos.  Patch against py3k trunk @ r70341.

I left howto/webservers.rst alone, despite a fair number of problems,
'cause it could do with a more serious rewrite than I have time for.

----------
assignee: georg.brandl
components: Documentation
files: py3k.typos.diff
keywords: patch
messages: 83524
nosy: dsm001, georg.brandl
severity: normal
status: open
title: doc copyedits
versions: Python 3.1
Added file: http://bugs.python.org/file13322/py3k.typos.diff

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

From report at bugs.python.org  Sat Mar 14 06:16:26 2009
From: report at bugs.python.org (oc)
Date: Sat, 14 Mar 2009 05:16:26 +0000
Subject: [New-bugs-announce] [issue5487] Parts of Tkinter missing (but not
	when running from IDLE)
In-Reply-To: <1237007786.64.0.764590527521.issue5487@psf.upfronthosting.co.za>
Message-ID: <1237007786.64.0.764590527521.issue5487@psf.upfronthosting.co.za>


New submission from oc <rstarfield at berkeley.edu>:

When running a script using Python 3.0.1 I get an error saying that
tkinter.messagebox doesn't exist. However when I run the same script
from within IDLE, it works fine.

This has led to my thinking I'd fixed the Python 2.6/3 compatibility
errors while testing in IDLE, but had end users say it didn't work.

----------
components: Tkinter
files: snippet.py
messages: 83572
nosy: oc
severity: normal
status: open
title: Parts of Tkinter missing (but not when running from IDLE)
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file13328/snippet.py

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

From report at bugs.python.org  Sat Mar 14 18:16:33 2009
From: report at bugs.python.org (Lorenz Quack)
Date: Sat, 14 Mar 2009 17:16:33 +0000
Subject: [New-bugs-announce] [issue5488] nb_inplace_divide slot is missing
	in docs
In-Reply-To: <1237050993.04.0.349296113477.issue5488@psf.upfronthosting.co.za>
Message-ID: <1237050993.04.0.349296113477.issue5488@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

http://docs.python.org/c-api/typeobj.html#PyNumberMethods lists the
slots in the PyNumberMethods struct used to implement the Number
Protocol for extension types.

The entry for "binaryfunc nb_inplace_divide;" is missing from this listing.
It belongs between "binaryfunc nb_inplace_multiply;" and "binaryfunc
nb_inplace_remainder;"

There is a patch against r70371 of the trunk attached.

----------
assignee: georg.brandl
components: Documentation
files: typeobj.rst.patch
keywords: patch
messages: 83595
nosy: donlorenzo, georg.brandl
severity: normal
status: open
title: nb_inplace_divide slot is missing in docs
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13333/typeobj.rst.patch

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

From report at bugs.python.org  Sat Mar 14 19:37:31 2009
From: report at bugs.python.org (JCoder)
Date: Sat, 14 Mar 2009 18:37:31 +0000
Subject: [New-bugs-announce] [issue5489] Broken DLL
In-Reply-To: <1237055851.94.0.0616888340997.issue5489@psf.upfronthosting.co.za>
Message-ID: <1237055851.94.0.0616888340997.issue5489@psf.upfronthosting.co.za>


New submission from JCoder <bcookman12 at gmail.com>:

The windows installer for Python 2.6 failed to install Python on 
Windows ME because a DLL required for installation could not be run.

----------
components: Installation
messages: 83596
nosy: JCoder
severity: normal
status: open
title: Broken DLL
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 14 20:36:41 2009
From: report at bugs.python.org (JCoder)
Date: Sat, 14 Mar 2009 19:36:41 +0000
Subject: [New-bugs-announce] [issue5490] Broken DLL
In-Reply-To: <1237059401.43.0.683662043097.issue5490@psf.upfronthosting.co.za>
Message-ID: <1237059401.43.0.683662043097.issue5490@psf.upfronthosting.co.za>


New submission from JCoder <bcookman12 at gmail.com>:

When I try to install Python 2.6 on Windows ME, I get an error message 
saying that a DLL file needed to install it cannot be opened.

By the way, I just posted this message, and apparantly, it disappeared.

----------
components: Installation
messages: 83599
nosy: JCoder
severity: normal
status: open
title: Broken DLL
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 15 05:51:10 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Mar 2009 04:51:10 +0000
Subject: [New-bugs-announce] [issue5491] Clarify contextlib.nested semantics
In-Reply-To: <1237092670.04.0.313927493642.issue5491@psf.upfronthosting.co.za>
Message-ID: <1237092670.04.0.313927493642.issue5491@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Current doc example:

with nested(A, B, C) as (X, Y, Z):
    do_something()

with A as X:
    with B as Y:
        with C as Z:
            do_something()

Recommended docs change:

with nested(A(), B(), C()) as (X, Y, Z):
    do_something()

m1, m2, m3 = A(), B(), C()
with m1 as X:
    with m2 as Y:
        with m3 as Z:
            do_something()

This makes it clearer that when using nested, the context managers are
all created outside the scope of the with statement.

----------
assignee: georg.brandl
components: Documentation
messages: 83619
nosy: georg.brandl, ncoghlan
severity: normal
status: open
title: Clarify contextlib.nested semantics

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

From report at bugs.python.org  Sun Mar 15 13:44:37 2009
From: report at bugs.python.org (Ger Luijten)
Date: Sun, 15 Mar 2009 12:44:37 +0000
Subject: [New-bugs-announce] [issue5492] Error on leaving IDLE with quit()
	or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>


New submission from Ger Luijten <gcjm.luijten at gmail.com>:

Hello developers,

Found a small error when using IDLE Version 3.1a1 under Kubuntu Linux
8.10 in the terminal.
Kubuntu is fully updated and no installation errors for Python 3.1a1.

See the listing from my installation notes below.

Greetings, Ger


Let's see if IDLE works, by starting it in the terminal:
$ idle

IDLE works in the new Python version 3.1a1, but there is an error!

When leaving IDLE with quit() or exit() and clicking the OK button for
the question 'The program is still running! Do you want to kill it?
there's the errors listed below, that does not occur when leaving IDLE
with Ctrl-D instead of quit():

Error when leaving with quit() (Full error listing)
*** Internal Error: rpc.py:SocketIO.localcall()

 Object: stderr
 Method: <bound method PseudoFile.write of <idlelib.PyShell.PseudoFile
object at 0x9ce942c>>
 Args: ('Traceback (most recent call last):',)

Traceback (most recent call last):
  File "/usr/local/lib/python3.1/idlelib/rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1218, in write
    self.shell.write(s, self.tags)
  File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1201, in write
    self.text.mark_gravity("iomark", "left")
AttributeError: 'NoneType' object has no attribute 'mark_gravity'

Error when leaving with exit() (Partial error listing: only the error
part that difffers is listed here)
 Object: stderr
 Method: <bound method PseudoFile.write of <idlelib.PyShell.PseudoFile
object at 0xa08642c>>
 Args: ('  File "<pyshell#0>", line 1, in <module>\n',)

----------
components: IDLE
messages: 83629
nosy: gerluijten
severity: normal
status: open
title: Error on leaving IDLE with quit() or exit() under Linux
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar 15 14:21:24 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Mar 2009 13:21:24 +0000
Subject: [New-bugs-announce] [issue5493] Rephrasing the doc of
	object.__nonzero__
In-Reply-To: <1237123284.32.0.590929476776.issue5493@psf.upfronthosting.co.za>
Message-ID: <1237123284.32.0.590929476776.issue5493@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The doc [1] actually says:
object.__nonzero__(self)
    Called to implement truth value testing, and the built-in operation
bool(); should return False or True, or their integer equivalents 0 or
1. When this method is not defined, __len__() is called, if it is
defined (see below). If a class defines neither __len__() nor
__nonzero__(), all its instances are considered true.

I suggest to:
1) drop the comma after 'testing';
2) clarify what happens when __nonzero__ is defined and where 'below'
actually is (and possibly add a link).


[1]: http://docs.python.org/reference/datamodel.html#object.__nonzero__

----------
assignee: georg.brandl
components: Documentation
messages: 83630
nosy: ezio.melotti, georg.brandl
severity: normal
status: open
title: Rephrasing the doc of object.__nonzero__

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

From report at bugs.python.org  Sun Mar 15 14:42:07 2009
From: report at bugs.python.org (Ger Luijten)
Date: Sun, 15 Mar 2009 13:42:07 +0000
Subject: [New-bugs-announce] [issue5494] Failure in test_httpservers on Linux
In-Reply-To: <1237124527.44.0.964288018613.issue5494@psf.upfronthosting.co.za>
Message-ID: <1237124527.44.0.964288018613.issue5494@psf.upfronthosting.co.za>


New submission from Ger Luijten <gcjm.luijten at gmail.com>:

Hello developers,

While running 'make test' for Python 3.1a1 there was an error reported,
obviously a permission problem, but when trying to run the reported
server.py script in verbose mode it turned up an error in the
regrtest.py script. 
Manually running the server.py script seems to go fine.
See my installation notes below.

Commands were issued with and without sudo in a terminal under fully
updated Kubuntu 8.10 and with no installation problems for Python 3.1a1.

Also I noticed Issue 4951 failure in test_httpserver under Windows, but
with a different kind of error message.

Greetings, Ger

$ sudo make test
Errors: 1 error reported; no idea what the script server.py is trying to
access for which it says to have no rights.

This error was listed 3 times:

test_httpservers                                                       
                                                    
Traceback (most recent call last):                                     
                                                    
  File
"/home/ger/Systeembeheer/Python/Python_Packages/Python-3.1a1/Lib/http/server.py",
line 1031, in run_cgi              
OSError: [Errno 13] Permission denied                                  
                                                                       
                                                               
test test_httpservers failed -- errors occurred; run in verbose mode for
details  

See the readme file for the Python installation on how to run the script
in verbose mode:
General: $ ./python Lib/test/regrtest.py -v test_whatever
So go to the folder Python-3.1a1/Lib/test/
Run testscript in verbose mode: $ sudo ./regrtest.py -v server.py

No idea if this regrtest.py script knows the path to server.py,
otherwise add the correct path later in testing.

This shows a programming error in the regrtest.py script, so a run of
server.py is not possible with this script:
  File "./regrtest.py", line 185
    print(msg, file=sys.stderr)
                   ^
SyntaxError: invalid syntax


So let's run the server.py script directly to see if this script crashes
or not.

When directly running the server.py script with and without sudo it runs
with no errors, until broken off by Ctrl+C. 
The script seems to run or simulate a small webserver for tests.

Python-3.1a1/Lib/http$ sudo python3.1 server.py
Serving HTTP on 0.0.0.0 port 8000 ...
^CTraceback (most recent call last):
  File "server.py", line 1101, in <module>
    test(HandlerClass=BaseHTTPRequestHandler)
  File "server.py", line 1097, in test
    httpd.serve_forever()
  File "/usr/local/lib/python3.1/socketserver.py", line 224, in
serve_forever
    r, w, e = select.select([self], [], [], poll_interval)
KeyboardInterrupt

----------
components: Tests
messages: 83631
nosy: gerluijten
severity: normal
status: open
title: Failure in test_httpservers on Linux
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar 15 15:30:36 2009
From: report at bugs.python.org (Retro)
Date: Sun, 15 Mar 2009 14:30:36 +0000
Subject: [New-bugs-announce] [issue5495] ValueError exception of
	tuple.index(x) gives imprecise error message
In-Reply-To: <1237127436.03.0.0963869402695.issue5495@psf.upfronthosting.co.za>
Message-ID: <1237127436.03.0.0963869402695.issue5495@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

>>> t = (0, 1, 2, 3, 4, 5, 6, 7)
>>> t.index(8)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tuple.index(x): x not in list

The error message "x not in list" should have been "x not in tuple".
Please fix the error message of the index method of the tuple type.

----------
components: None
messages: 83633
nosy: Retro
severity: normal
status: open
title: ValueError exception of tuple.index(x) gives imprecise error message
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar 15 17:26:32 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 15 Mar 2009 16:26:32 +0000
Subject: [New-bugs-announce] [issue5496] codecs.lookup docstring is
	misleading
In-Reply-To: <1237134392.29.0.239509482226.issue5496@psf.upfronthosting.co.za>
Message-ID: <1237134392.29.0.239509482226.issue5496@psf.upfronthosting.co.za>


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

codecs.lookup is documented as returning a tuple.  It actually returns a
what the registered lookup function returns, which really *should* be a
codecs.CodecInfo instance.  If a registered lookup function actually
returns a tuple, then codecs.getreader and the other similar functions
won't work.

----------
assignee: georg.brandl
components: Documentation
messages: 83640
nosy: exarkun, georg.brandl
severity: normal
status: open
title: codecs.lookup docstring is misleading

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

From report at bugs.python.org  Tue Mar 17 07:44:01 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 17 Mar 2009 06:44:01 +0000
Subject: [New-bugs-announce] [issue5497] openssl compileerror with original
	source
In-Reply-To: <1237272241.76.0.44185655243.issue5497@psf.upfronthosting.co.za>
Message-ID: <1237272241.76.0.44185655243.issue5497@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I ported "compile openssl without perl" scheme into PC/VC6 from PCBuild.
And I noticed openssl compilation fails with a message "IDEA is
disabled" if I use original source code from openssl homepage.

I hope attached patch will fix this. openssl's Configure seems to take
options to exclude specific algorithms. I tested test_ssl, it seems
working on my VC6.

----------
components: Build
files: fix_openssl_compile_error.patch
keywords: patch
messages: 83660
nosy: ocean-city
severity: normal
status: open
title: openssl compileerror with original source
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13347/fix_openssl_compile_error.patch

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

From report at bugs.python.org  Tue Mar 17 12:19:35 2009
From: report at bugs.python.org (once-off)
Date: Tue, 17 Mar 2009 11:19:35 +0000
Subject: [New-bugs-announce] [issue5498] Can SGMLParser properly handle
	<empty/> tags?
In-Reply-To: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>
Message-ID: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>


New submission from once-off <once-off at mailinator.com>:

The attached script (sgml_error.py) was designed to output XML files
unchanged, other than expanding <empty/> tags into an opening and
closing tag, such as <empty></empty>.

It seems the SGMLParser class recognizes an empty tag, but does not emit
the closing tag until the NEXT forward slash it sees. So everything from
the forward slash in <empty/> (even the closing angle bracket) until the
next forward slash is considered to be textual data. See the following
line output.

Have I missed something here (like a conscious design limitation on the
class, an error on my part, etc), or is this really a bug with the class?

C:\Python24\Lib>python sgmllib.py H:\input.xml
start tag: <root>
data: '\n '
start tag: <tag1>
end tag: </tag1>
data: '\n '
start tag: <tag2>
data: '>\n <tag3>hello<'
end tag: </tag2>
data: 'tag3>\n'
end tag: </root>

C:\Python24\Lib>python
ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sgml_error

Input:
<root>
 <tag1></tag1>
 <tag2/>
 <tag3>hello</tag3>
</root>

Output:
<root>
 <tag1></tag1>
 <tag2>>
 <tag3>hello<</tag2>tag3>
</root>

Expected:
<root>
 <tag1></tag1>
 <tag2></tag2>
 <tag3>hello</tag3>
</root>

----------
components: Extension Modules, Library (Lib), XML
files: sgml_error.py
messages: 83667
nosy: once-off
severity: normal
status: open
title: Can SGMLParser properly handle <empty/> tags?
type: behavior
versions: 3rd party, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file13348/sgml_error.py

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

From report at bugs.python.org  Tue Mar 17 13:58:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2009 12:58:18 +0000
Subject: [New-bugs-announce] [issue5499] only accept byte for getarg('c')
	and unicode for	getarg('C')
In-Reply-To: <1237294698.92.0.380829116259.issue5499@psf.upfronthosting.co.za>
Message-ID: <1237294698.92.0.380829116259.issue5499@psf.upfronthosting.co.za>


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

To avoid byte/character mixture, getarg('c') must only accept a byte 
string of 1 byte and getarg('C') only an unicode string of 1 
character.

Impacted methods:
- datetime.datetime.isoformat(sep), array.array(type, data): don't 
accept byte anymore
- msvcrt.putch(char), msvcrt.ungetch(char), <mmap 
object>.write_byte(char): don't accept unicode anymore

I tried runtests.sh: only the 3 bytes.{center,ljust,rjust} tests have 
to be changed, all other tests are ok.

Related issues: #3446, #5391.

----------
files: getarg_strict_char.patch
keywords: patch
messages: 83676
nosy: haypo
severity: normal
status: open
title: only accept byte for getarg('c') and unicode for getarg('C')
versions: Python 3.1
Added file: http://bugs.python.org/file13350/getarg_strict_char.patch

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

From report at bugs.python.org  Tue Mar 17 16:36:02 2009
From: report at bugs.python.org (Elijah Merkin)
Date: Tue, 17 Mar 2009 15:36:02 +0000
Subject: [New-bugs-announce] [issue5500] tarfile: path problem in arcname
	under windows
In-Reply-To: <1237304162.51.0.555320282686.issue5500@psf.upfronthosting.co.za>
Message-ID: <1237304162.51.0.555320282686.issue5500@psf.upfronthosting.co.za>


New submission from Elijah Merkin <elm at transas.com>:

Tested on Python 2.5.4.

1. Use tarfile.open("fname", "w|gz") to create an archive.
2. Add a file using TarFile.add(name, arcname=None, recursive=True,
exclude=None) by specifying 2 params: absolute path to a source file as
'name' and something containing one or more directories, e.g.
'test/myfile.txt' as 'arcname'.
3. Close the archive.

On Linux file is added as 'test/myfile.txt'. On Windows the full path
specified as 'name' is used (e.g. 'D:\\MyDir\\myfile.txt'). When I use
'w|bz2' everything works correctly.

Probably this bug is somewhat similar to a bug #4750, though it happens
under Windows and doesn't happen under Linux.

----------
components: Library (Lib), Windows
messages: 83680
nosy: ellioh
severity: normal
status: open
title: tarfile: path problem in arcname under windows
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Mar 17 19:01:44 2009
From: report at bugs.python.org (Brandon Corfman)
Date: Tue, 17 Mar 2009 18:01:44 +0000
Subject: [New-bugs-announce] [issue5501] Update multiprocessing docs re:
	freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>


New submission from Brandon Corfman <bcorfman at fastmail.fm>:

Indicate in docs whether freeze_support() can be called without issues
on Unix or OS X, so the user knows whether they can have a single code
base that works correctly on all platforms.

----------
assignee: georg.brandl
components: Documentation
messages: 83690
nosy: bcorfman, georg.brandl, jnoller
severity: normal
status: open
title: Update multiprocessing docs re: freeze_support
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 18 02:16:12 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2009 01:16:12 +0000
Subject: [New-bugs-announce] [issue5502] io-c: TextIOWrapper is faster than
	BufferedReader but not	protected by a lock
In-Reply-To: <1237338972.64.0.602798435318.issue5502@psf.upfronthosting.co.za>
Message-ID: <1237338972.64.0.602798435318.issue5502@psf.upfronthosting.co.za>


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

TextIOWrapper.readline() is much faster (eg. 72 ms vs 95 ms) than 
BufferedReader.readline(). It's because BufferedReader always acquires 
the file lock, whereas TextIOWrapper only acquires the file lock when 
the buffer is empty.

I would like a BufferedReader.readline() as fast as 
TextIOWrapper.readline(), or faster!

Why BufferedReader's attributes are protected by a lock whereas 
TextIOWrapper's attributes are not?

Does it mean that TextIOWrapper may crash if two threads calls 
readline() (or different methods) at the "same time"?

How does Python 2.x and 3.0 fix this issue?

----------
components: Library (Lib)
messages: 83724
nosy: haypo, pitrou
severity: normal
status: open
title: io-c: TextIOWrapper is faster than BufferedReader but not protected by a lock
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 18 03:17:24 2009
From: report at bugs.python.org (jq)
Date: Wed, 18 Mar 2009 02:17:24 +0000
Subject: [New-bugs-announce] [issue5503] multiprocessing/connection.py wrong
	pipe name under win32
In-Reply-To: <1237342644.17.0.0547422221967.issue5503@psf.upfronthosting.co.za>
Message-ID: <1237342644.17.0.0547422221967.issue5503@psf.upfronthosting.co.za>


New submission from jq <jqcn2003 at hotmail.com>:

def arbitrary_address(family):

    elif family == 'AF_PIPE':
        return tempfile.mktemp(prefix=r'\\.\pipe\pyc-%d-%d-' %
                               (os.getpid(), _mmap_counter.next()))
    

#works after removed tempfile.mktemp 

return r'\\.\pipe\pyc-%d-%d-' % (os.getpid(), _mmap_counter.next())

----------
components: Library (Lib)
messages: 83730
nosy: jqcn2003
severity: normal
status: open
title: multiprocessing/connection.py wrong pipe name under win32
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 18 04:55:31 2009
From: report at bugs.python.org (Adam Goode)
Date: Wed, 18 Mar 2009 03:55:31 +0000
Subject: [New-bugs-announce] [issue5504] ctypes should work with systems
	where mmap can't be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>


New submission from Adam Goode <adam at spicenitz.org>:

On Fedora systems, it is invalid to mmap something with PROT_WRITE and
PROT_EXEC. libffi has been updated to support this, but ctypes has not
been updated to use this new functionality.

Attached is a patch which currently only works if system libffi is used.
Though the embedded version of libffi is new enough, it is missing the
allocation and free functions. I know how I would update the ctypes
libffi/ directory (add the alloc/free files), but not sure about the
other libffi directories (darwin, arm_wince, msvc, osx). I suppose those
would all need to be upgraded, or perhaps even made to use the standard
libffi instead of special forks of it.

Note that this also eliminates the malloc_closure code.

----------
assignee: theller
components: ctypes
files: ctypes-newffi.patch
keywords: patch
messages: 83734
nosy: agoode, theller
severity: normal
status: open
title: ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13363/ctypes-newffi.patch

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

From report at bugs.python.org  Wed Mar 18 10:20:34 2009
From: report at bugs.python.org (Fan Decheng)
Date: Wed, 18 Mar 2009 09:20:34 +0000
Subject: [New-bugs-announce] [issue5505] sys.stdin.read() doesn't return
	after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>


New submission from Fan Decheng <fandecheng at gmail.com>:

Platform: Windows Vista x64
Python version: 3.0.1 x64

When I use sys.stdin.readlines(), it correctly ends when I enter ^Z 
(ctrl-Z) on the console (this is the EOF on the console). However when 
I call sys.stdin.read(), it doesn't end when ^Z is entered. It ends 
when I enter the second ^Z.

Repro steps:
1. Open python.
2. Type:
import sys
sys.stdin.read()
3. Type:
Hello
^Z
4. Note the above ^Z should be followed by a Return.
Result:
The function call doesn't end. If I enter another ^Z, it ends.
Expected result:
The function call ends.

----------
components: Library (Lib)
messages: 83736
nosy: r_mosaic
severity: normal
status: open
title: sys.stdin.read() doesn't return after first EOF on Windows
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Mar 18 11:40:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2009 10:40:13 +0000
Subject: [New-bugs-announce] [issue5506] io.BytesIO doesn't support the
	buffer protocol
In-Reply-To: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>
Message-ID: <1237372813.02.0.863937398422.issue5506@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It may be logical for BytesIO to support the buffer protocol (readable
/and/ writable).

----------
components: Library (Lib)
messages: 83740
nosy: pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: io.BytesIO doesn't support the buffer protocol
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 18 13:08:22 2009
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 18 Mar 2009 12:08:22 +0000
Subject: [New-bugs-announce] [issue5507] ctypes configuration fails on
	mips-linux (and probably	Irix)
In-Reply-To: <1237378102.74.0.471718601919.issue5507@psf.upfronthosting.co.za>
Message-ID: <1237378102.74.0.471718601919.issue5507@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

|   File "build/temp.linux-mips-2.6/libffi/fficonfig.py", line 32, in
<module>
|     ffi_sources += ffi_platforms['MIPS']
| KeyError: 'MIPS'

however the fficonfig.py file has only MIPS_LINUX and MIPS_IRIX keys.

----------
assignee: theller
components: ctypes
messages: 83744
nosy: doko, theller
severity: normal
status: open
title: ctypes configuration fails on mips-linux (and probably Irix)
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Mar 18 16:25:50 2009
From: report at bugs.python.org (ganges master)
Date: Wed, 18 Mar 2009 15:25:50 +0000
Subject: [New-bugs-announce] [issue5508] maximum recursion depth exceeded in
	__subclasscheck__
In-Reply-To: <1237389950.95.0.980403444987.issue5508@psf.upfronthosting.co.za>
Message-ID: <1237389950.95.0.980403444987.issue5508@psf.upfronthosting.co.za>


New submission from ganges master <gangesmaster at users.sourceforge.net>:

this is similar to bug #5370, but this for is a different reason. also,
i have seen several sites on google that mention it, so it has happened
to quite a few people.

the bug is that when calling dir() on a object, it looks for __members__
and __methods__, which might not exist, thus invoking __getattr__ (if it
exists).

if __getattr__ fails, say, due to a never ending recusion, the exception
is silently swallowed. this was the behavior in py2.5. since 2.6, it
emits a warning (that looks like PyErr_WriteUnraisable) with the
strangest message:

Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.AttributeError'> ignored

this is very confusing. either dir() raises this exception, or silently
ignore it, but displaying this message is only confusing.

i haven't been able to detect why this happens:
 * the source of this exception, merge_list_attr, calls PyErr_Clear
 * nobody seems to call PyErr_WriteUnraisable

here's a snippet:

class Foo(object):
    def __getattr__(self, name):
        return self.x  # which will recursively call __getattr__

>>> f = Foo()
>>> print dir(f)
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.AttributeError'> ignored
['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
'__getattr__', '__getattribute__', '__hash__', '__init__', '__module__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']

----------
components: Interpreter Core
messages: 83752
nosy: gangesmaster, georg.brandl
severity: normal
status: open
title: maximum recursion depth exceeded in __subclasscheck__
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 18 18:08:13 2009
From: report at bugs.python.org (Nathaniel Troutman)
Date: Wed, 18 Mar 2009 17:08:13 +0000
Subject: [New-bugs-announce] [issue5509] cPickle - module object has no
	attribute
In-Reply-To: <1237396093.07.0.466180023327.issue5509@psf.upfronthosting.co.za>
Message-ID: <1237396093.07.0.466180023327.issue5509@psf.upfronthosting.co.za>


New submission from Nathaniel Troutman <locutusofbeira at yahoo.com>:

If I define a class Foo in module A and in module A pickle out a list of
Foo objects to 'foo.pkl', then in module B attempt to unpickle 'foo.pkl'
I recieve the error "AttributeError: 'module' object has no attribute 'Foo'"

Attached are:
Foo.py which defines the class Foo and pickles out a list of objects

LoadFoo.py attempts to load the list of objects pickled by Foo

I'm running Vista with "Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08)
[MSC v.1310 32 bit (Intel)] on win32"

----------
components: None
files: Foo.py
messages: 83759
nosy: ntroutman
severity: normal
status: open
title: cPickle - module object has no attribute
versions: Python 2.5
Added file: http://bugs.python.org/file13364/Foo.py

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

From report at bugs.python.org  Wed Mar 18 19:21:34 2009
From: report at bugs.python.org (Ramsey Dow)
Date: Wed, 18 Mar 2009 18:21:34 +0000
Subject: [New-bugs-announce] [issue5510] patches for Modules/socketmodule.c
	for NetBSD
In-Reply-To: <1237400494.47.0.163345338744.issue5510@psf.upfronthosting.co.za>
Message-ID: <1237400494.47.0.163345338744.issue5510@psf.upfronthosting.co.za>


New submission from Ramsey Dow <yesmar at speakeasy.net>:

I couldn't install setuptools (required by gitosis) because Python 2.6.1
didn't install socket when I built it. A little digging and I
uncommented the "_socket socketmodule.c" line in Modules/Setup.
Unfortunately, the Bluetooth socket stuff in Modules/socketmodule.c was
broken under NetBSD. I made this patch and tested on NetBSD 4.0.1.

When researching this bug on bugs.python.org, I noticed issue5400 which,
in order to get Modules/socketmodule.c compiling, disabled Bluetooth
socket support entirely. That isn't necessary. I just had to ensure the
various structure references made use of the proper member names
(according to NetBSD's /usr/include/netbt/bluetooth.h header file). The
changes I made were similar, though not precisely the same, as those for
FreeBSD.

After patching and building:

ramsey at wizard /opt/build/runtime/Python-2.6.1$ ./python -bb -E
Lib/test/regrtest.py test_socket
test_socket
1 test OK.

----------
components: Build
files: Python-2.6.1.patch
keywords: patch
messages: 83767
nosy: yesmar
severity: normal
status: open
title: patches for Modules/socketmodule.c for NetBSD
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file13366/Python-2.6.1.patch

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

From report at bugs.python.org  Wed Mar 18 19:24:24 2009
From: report at bugs.python.org (J.R. Allen)
Date: Wed, 18 Mar 2009 18:24:24 +0000
Subject: [New-bugs-announce] [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: <1237400664.18.0.956324816364.issue5511@psf.upfronthosting.co.za>


New submission from J.R. Allen <python at petruchio.org>:

Currently the zipfile.ZipFile class has no __exit__ atribute, so it 
does not work with a with statement as other file objects do.  Can this 
be implemented?

----------
components: Library (Lib)
messages: 83768
nosy: petruchio
severity: normal
status: open
title: zipfile - add __exit__ attribute to make ZipFile object compatible with with_statement
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 18 23:11:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 18 Mar 2009 22:11:27 +0000
Subject: [New-bugs-announce] [issue5512] Streamline integer division
In-Reply-To: <1237414287.96.0.340893009762.issue5512@psf.upfronthosting.co.za>
Message-ID: <1237414287.96.0.340893009762.issue5512@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a patch that streamlines the x_divrem function in 
Objects/longobject.c.  More benchmarks are needed, but the initial 
results are promising:  for py3k, on a 32-bit machine with 15-bit 
digits, Victor's pidigits benchmark runs almost twice as fast with this 
patch (numbers below).

Patch details
=============

- Normalize inputs by shifting instead of multiplying and dividing.
  This halves the number of divisions used in the algorithm.

- Streamline innermost loop.

- Save an iteration of outer loop around half the time.

- Save an object allocation:  only 3 allocations per x_divrem call
  instead of 4.

- Remove special case where initial quotient estimate is >= PyLong_BASE.
  There's no need for this, since the 'digit' type holds values up
  to 2*PyLong_BASE - 1.

- Make q type digit instead of type twodigits:  this halves the size
  of the multiplication in the innermost loop.

Benchmark results
=================

Using the pidigits_bestof.py script that's posted in the issue 4258 
discussion, on a non-debug build of py3k (r70465), on OS X 10.5.6/Core 2 
Duo:

Unpatched
---------
Macintosh-3:py3k dickinsm$ ./python.exe ../pidigits_bestof.py 2000
performing a warm up run...
running
sys.int_info= sys.int_info(bits_per_digit=15, sizeof_digit=2)
Time; 2234.6 ms
Time; 2232.2 ms
Time; 2227.9 ms
Time; 2225.7 ms
Time; 2229.8 ms
Best Time; 2225.7 ms

Patched
-------
dickinsm$ ./python.exe ../pidigits_bestof.py 2000
performing a warm up run...
running
sys.int_info= sys.int_info(bits_per_digit=15, sizeof_digit=2)
Time; 1175.6 ms
Time; 1176.5 ms
Time; 1177.3 ms
Time; 1179.5 ms
Time; 1168.5 ms
Best Time; 1168.5 ms

So the patch gives a speedup of around 90%.  This particular benchmark 
is heavy on the divisions though, so I'd expect lesser speedups for 
other benchmarks.

----------
assignee: marketdickinson
components: Interpreter Core
files: faster_integer_division.patch
keywords: patch
messages: 83781
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: Streamline integer division
type: performance
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13368/faster_integer_division.patch

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

From report at bugs.python.org  Wed Mar 18 23:26:17 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 18 Mar 2009 22:26:17 +0000
Subject: [New-bugs-announce] [issue5513] "What's New" should say VERY
	CLEARLY that the type file	is gone
In-Reply-To: <1237415177.76.0.586178129986.issue5513@psf.upfronthosting.co.za>
Message-ID: <1237415177.76.0.586178129986.issue5513@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

MAIN POINT

The Python 3 "What's New" should SCREAM that the type file is gone, not 
just that people should use the function open() to open files, since 
that has been a recommendation for quite a while.

EXPLANATION

In multiple readings of the Python 3 "What's New" I blew right past the 
"Removed file. Use open().", since I've been using open() instead of 
file() for a long time. I didn't notice that unlike the preceding 
several lines, there were no parentheses after "file" and that this line 
was literally saying there was no longer a type called "file".

OBSERVATIONS

(1) If the line is meant to say that you can no longer call file() as a 
function -- which would be strange if it were still a type -- then it is 
missing its parentheses.

(2) If the line is meant to say that there is no longer a file type, as 
it apparently means to say since in fact -- and to my great surprise -- 
there really IS no type called "file" in Python 3 (I discovered that 
doing a dir(file) to check whether file provided method function I 
thought it did instead of taking the time to look it up.) then there is 
a grammatical problem with the line since a (n old) type shouldn't be 
equated to a function call.

(3) I predict that anyone who has more than a passing acquaintance with 
Python 2 will be similarly shocked when they find out that what they get 
back from open() is a _io.TextIOWrapper (and, by the way, that they have 
to import _io or at least _io.TextIOWrapper to be able to do a dir on 
it). Likewise for help(file) and help(_io.TextIOWrapper). There should 
be a very prominent statement that as part of the reimplementation of 
the io system, the type file has been replaced by _io.TextIOWrapper.

RECOMMENDATION

The line
    "Removed file. Use open()."
should be replaced with:
    "The type file has been removed; use open() to open a file."
or possibly:
    "The type file has been replaced by _ioTextIOWrapper; use open() to 
open a file; open returns an instance of _ioTextIOWrapper."

----------
assignee: georg.brandl
components: Documentation
messages: 83783
nosy: MLModel, georg.brandl
severity: normal
status: open
title: "What's New" should say VERY CLEARLY that the type file is gone
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 19 00:06:55 2009
From: report at bugs.python.org (Jack Howarth)
Date: Wed, 18 Mar 2009 23:06:55 +0000
Subject: [New-bugs-announce] [issue5514] Darwin framework libpython3.0.a is
	not a normal static	library
In-Reply-To: <1237417615.01.0.58676676944.issue5514@psf.upfronthosting.co.za>
Message-ID: <1237417615.01.0.58676676944.issue5514@psf.upfronthosting.co.za>


New submission from Jack Howarth <howarth at bromo.med.uc.edu>:

The libpython3.0.a created for Python 3.0.1 isn't a normal static 
library.

file 
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a: Mach-O universal binary with 3 architectures
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture x86_64):	Mach-O 64-bit 
dynamically linked shared library x86_64
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture i386):	Mach-O dynamically 
linked shared library i386
/System/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/c
onfig/libpython3.0.a (for architecture ppc7400):	Mach-O 
dynamically linked shared library ppc

Due to a bug in Darwin's ar, extraction the object files in this 
abnormal static libraries has been possible with 'ar x'. This bug in ar 
will be fixed in the next Xcode and the abnormal static library that 
python creates will no longer be able to serve as a substitute for a 
true static library. The libpython#.#.#.a files in config should be made 
into normal static libraries for all the currently supported versions of 
python when built as frameworks.

----------
components: Macintosh
messages: 83792
nosy: jhowarth
severity: normal
status: open
title: Darwin framework libpython3.0.a is not a normal static library
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Mar 19 01:33:58 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 19 Mar 2009 00:33:58 +0000
Subject: [New-bugs-announce] [issue5515] 'n' formatting for int and float
	handles leading zero	padding poorly
In-Reply-To: <1237422838.11.0.502789865949.issue5515@psf.upfronthosting.co.za>
Message-ID: <1237422838.11.0.502789865949.issue5515@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

I think the way leading zero padding is handled for int and float by
format's 'n' code is a bug.

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF8')
'en_US.UTF8'
>>> format(12345, '010n')
'000012,345'
>>> format(12345, '09n')
'00012,345'
>>> format(12345, '08n')
'0012,345'
>>> format(12345, '07n')
'012,345'
>>> format(12345, '06n')
'12,345'

When 'n' support was added to Decimal, leading zeros had commas in them:

>>> from decimal import Decimal
>>> format(Decimal(12345), '010n')
'00,012,345'
>>> format(Decimal(12345), '09n')
'0,012,345'
>>> format(Decimal(12345), '08n')
'0,012,345'
>>> format(Decimal(12345), '07n')
'012,345'
>>> format(Decimal(12345), '06n')
'12,345'

Decimal also has the same support for PEP 378's ',' modifier:

>>> format(Decimal(12345), '010,')
'00,012,345'
>>> format(Decimal(12345), '09,')
'0,012,345'
>>> format(Decimal(12345), '08,')
'0,012,345'
>>> format(Decimal(12345), '07,')
'012,345'
>>> format(Decimal(12345), '06,')
'12,345'
>>> 

As I'm implementing PEP 378 for int and float, I'm going to make it work
the same way that Decimal works. For consistency, and because I think
the current behavior is not useful, I'd like to change float and int
formatting with 'n' to match Decimal and PEP 378 for the ',' modifier.

Since I consider this a bug, I'd like to consider backporting it to 2.6
and 3.0, if the changes aren't too intrusive.

----------
assignee: marketdickinson
components: Interpreter Core
messages: 83797
nosy: eric.smith, marketdickinson, rhettinger
severity: normal
status: open
title: 'n' formatting for int and float handles leading zero padding poorly
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/issue5515>
_______________________________________

From report at bugs.python.org  Thu Mar 19 01:51:26 2009
From: report at bugs.python.org (Jess Austin)
Date: Thu, 19 Mar 2009 00:51:26 +0000
Subject: [New-bugs-announce] [issue5516] equality not reflixive for
	subclasses of datetime.date	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>


New submission from Jess Austin <jess.austin at gmail.com>:

While the datetime.date and datetime.datetime classes consistently
handle mixed-type comparison, their subclasses do not:

>>> from datetime import date, datetime, time
>>> d = date.today()
>>> dt = datetime.combine(d, time())
>>> d == dt
False
>>> dt == d
False
>>> class D(date):
...     pass
... 
>>> class DT(datetime):
...     pass
... 
>>> d = D.today()
>>> dt = DT.combine(d, time())
>>> d == dt
True
>>> dt == d
False

I think this is due to the premature "optimization" of using memcmp() in
date_richcompare().

----------
components: Library (Lib)
messages: 83798
nosy: jess.austin
severity: normal
status: open
title: equality not reflixive for subclasses of datetime.date and datetime.datetime
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 19 08:11:02 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 19 Mar 2009 07:11:02 +0000
Subject: [New-bugs-announce] [issue5517] 2to3 haven't convert buffer object
	to memoryview
In-Reply-To: <1237446662.62.0.531396044064.issue5517@psf.upfronthosting.co.za>
Message-ID: <1237446662.62.0.531396044064.issue5517@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

The following example is valid in Python 2.6:

a = 'abc'
b = buffer(a)
print([repr(c) for c in b])

After 2to3 it, the 'buffer' isn't changed to memoryview, so then it is
not valid program in Python 3:

Traceback (most recent call last):
  File "bufferobj3.py", line 2, in <module>
    b = buffer(a)
NameError: name 'buffer' is not defined

However even it changed to memoryview the program still not valid because:

>>> memoryview('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the
buffer interface


I can reporduce this on both Python 3.0.1 and Python 3.1a1+ (py3k:70310).

Thanks!

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 83802
nosy: bhy
severity: normal
status: open
title: 2to3 haven't convert buffer object to memoryview
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 19 16:53:52 2009
From: report at bugs.python.org (rb)
Date: Thu, 19 Mar 2009 15:53:52 +0000
Subject: [New-bugs-announce] [issue5518] cPickle produces inconsistent output
In-Reply-To: <1237478032.19.0.310078929224.issue5518@psf.upfronthosting.co.za>
Message-ID: <1237478032.19.0.310078929224.issue5518@psf.upfronthosting.co.za>


New submission from rb <rb-oss-2 at justgohome.co.uk>:

The documentation states that the output of pickle and cPickle may be
different. However it is implied that the output of a particular module
will always be consistent within itself. This expectation fails for the
case below.

I am using the output of cPickle in order to generate a key to use for
external storage where the key is abstracted to a generic Python
(immutable) object. Without consistency this breaks for me; pickle is
too slow so I need to use cPickle.

$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
>>> key = (1, u'foo')
>>> cPickle.dumps(key)
'(I1\nVfoo\ntp1\n.'
>>> cPickle.dumps((1, u'foo'))
'(I1\nVfoo\np1\ntp2\n.'

PythonWin 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] 
on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for 
further copyright information.
>>> import cPickle
>>> key = (1,u'foo')
>>> cPickle.dumps(key)
'(I1\nVfoo\ntp1\n.'
>>> cPickle.dumps((1,u'foo'))
'(I1\nVfoo\np1\ntp2\n.'

Expected results: the output of the two dumps calls should be the same.

----------
components: Library (Lib)
messages: 83814
nosy: rb
severity: normal
status: open
title: cPickle produces inconsistent output
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Thu Mar 19 20:56:03 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 19 Mar 2009 19:56:03 +0000
Subject: [New-bugs-announce] [issue5519] Deletion of some statements in re
	documentation
In-Reply-To: <1237492563.73.0.360381251415.issue5519@psf.upfronthosting.co.za>
Message-ID: <1237492563.73.0.360381251415.issue5519@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The second sentence of the re module documentation -- " The re module is 
always available." seems extraneous at best. What is it saying? What 
modules are not always available? Do other "always available" modules say 
that they are always available?

Also, the reference to kodos should probably be removed. It hasn't been 
updated since 2006, and it doesn't work with PyQT4.

----------
assignee: georg.brandl
components: Documentation
messages: 83821
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Deletion of some statements in re documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 19 21:49:53 2009
From: report at bugs.python.org (Jess Austin)
Date: Thu, 19 Mar 2009 20:49:53 +0000
Subject: [New-bugs-announce] [issue5520] refactor test_datetime.py
In-Reply-To: <1237495793.7.0.375370531619.issue5520@psf.upfronthosting.co.za>
Message-ID: <1237495793.7.0.375370531619.issue5520@psf.upfronthosting.co.za>


New submission from Jess Austin <jess.austin at gmail.com>:

I've broken out this refactoring from some of the other datetime stuff
I'm doing.  The patch needn't be applied until the other issues that
depend on it are.

----------
components: Library (Lib)
files: test_datetime.diff
keywords: patch
messages: 83822
nosy: jess.austin
severity: normal
status: open
title: refactor test_datetime.py
versions: Python 3.1
Added file: http://bugs.python.org/file13376/test_datetime.diff

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

From report at bugs.python.org  Fri Mar 20 01:07:59 2009
From: report at bugs.python.org (Matt Mendell)
Date: Fri, 20 Mar 2009 00:07:59 +0000
Subject: [New-bugs-announce] [issue5521] sqlite3.h missing
In-Reply-To: <1237507679.36.0.109463905227.issue5521@psf.upfronthosting.co.za>
Message-ID: <1237507679.36.0.109463905227.issue5521@psf.upfronthosting.co.za>


New submission from Matt Mendell <matthew.mendell at gmail.com>:

File sqlite3.h missing from Python-3.0.1.
setup.py looks for this file.

Is this intentional?

----------
components: None
messages: 83831
nosy: mendell
severity: normal
status: open
title: sqlite3.h missing
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Fri Mar 20 01:25:21 2009
From: report at bugs.python.org (Joshua Kugler)
Date: Fri, 20 Mar 2009 00:25:21 +0000
Subject: [New-bugs-announce] [issue5522] HTTPRedirectHandler documentation
	is wrong
In-Reply-To: <1237508721.0.0.854942701546.issue5522@psf.upfronthosting.co.za>
Message-ID: <1237508721.0.0.854942701546.issue5522@psf.upfronthosting.co.za>


New submission from Joshua Kugler <jkugler at bigfoot.com>:

On the page lib/http-redirect-handler.html it says the signature of 
redirect_request is:

redirect_request(  req, fp, code, msg, hdrs)

It is actually:

redirect_request(req, fp, code, msg, hdrs, newurl)

Well, technically the signature is:

redirect_request(self, req, fp, code, msg, hdrs, newurl)

but it is called as the six-argument version.

----------
assignee: georg.brandl
components: Documentation
messages: 83832
nosy: georg.brandl, jkugler
severity: normal
status: open
title: HTTPRedirectHandler documentation is wrong
versions: Python 2.5

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

From report at bugs.python.org  Fri Mar 20 01:27:28 2009
From: report at bugs.python.org (Joshua Kugler)
Date: Fri, 20 Mar 2009 00:27:28 +0000
Subject: [New-bugs-announce] [issue5523] Python bug tracker won't let you
	edit your profile
In-Reply-To: <1237508848.4.0.99019390166.issue5523@psf.upfronthosting.co.za>
Message-ID: <1237508848.4.0.99019390166.issue5523@psf.upfronthosting.co.za>


New submission from Joshua Kugler <jkugler at bigfoot.com>:

I tried to edit my e-mail address in the python bug tracker 
(under "Your Details"), but when I hit submit, it tells me:

You do not have permission to edit user

----------
components: None
messages: 83833
nosy: jkugler
severity: normal
status: open
title: Python bug tracker won't let you edit your profile
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Fri Mar 20 02:54:04 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2009 01:54:04 +0000
Subject: [New-bugs-announce] [issue5524] execfile() removed from Python3
In-Reply-To: <1237514044.93.0.31573705804.issue5524@psf.upfronthosting.co.za>
Message-ID: <1237514044.93.0.31573705804.issue5524@psf.upfronthosting.co.za>


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

In "What?s New In Python 3.0" document, I can read "Removed 
execfile(). Instead of execfile(fn) use exec(open(fn).read())". The 
new syntax has two problems:
 - if the file is not encoding in UTF-8, we get an unicode error. Eg. 
see issue #4282
 - exec() doesn't support newline different than \n, see issue #4628

We need a short function which opens the Python file with the right 
encoding. Get Python file encoding and open it with the right encoding 
is a command pattern.

Attached patch proposes a function open_script() to open a Python 
script with the correct encoding. Using it, execfile() can be replaced 
by exec(open_script(fn).read()) which doesn't have to two binary file 
problems.

----------
files: open_script.patch
keywords: patch
messages: 83845
nosy: haypo
severity: normal
status: open
title: execfile() removed from Python3
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13380/open_script.patch

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

From report at bugs.python.org  Fri Mar 20 04:11:51 2009
From: report at bugs.python.org (Luca clementi)
Date: Fri, 20 Mar 2009 03:11:51 +0000
Subject: [New-bugs-announce] [issue5525] Problem with email.MIME* library,
	using wrong new line
In-Reply-To: <1237518711.23.0.918881027535.issue5525@psf.upfronthosting.co.za>
Message-ID: <1237518711.23.0.918881027535.issue5525@psf.upfronthosting.co.za>


New submission from Luca clementi <luca.clementi at gmail.com>:

I'm running Python 2.5.2 under Ubuntu 8.10.

In the file email/generator.py from the core library at line 228 in the
function _handle_multipart()
            # delimiter transport-padding CRLF
            print >> self._fp, '\n--' + boundary
but if this function is run under Unix it print only the LF and not the
CRLF as by required by the standard. 

My guess is that this error is also in other part of the library.
SMTP (as HTTP) requires CRLF as new line, by standard, while I see that
at the beginning of the generator.py
NL = '\n'

Am I missing something?

Luca

----------
components: Library (Lib)
messages: 83851
nosy: lclement
severity: normal
status: open
title: Problem with email.MIME* library, using wrong new line
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Mar 20 04:59:49 2009
From: report at bugs.python.org (Evan Greensmith)
Date: Fri, 20 Mar 2009 03:59:49 +0000
Subject: [New-bugs-announce] [issue5526] Local variables unavailable for
	operation of list	comprehension when using eval()
In-Reply-To: <1237521589.9.0.0850513364759.issue5526@psf.upfronthosting.co.za>
Message-ID: <1237521589.9.0.0850513364759.issue5526@psf.upfronthosting.co.za>


New submission from Evan Greensmith <evan.greensmith at gmail.com>:

In python 3.0 and 3.1, attempting to access a local variable from within
a list comprehension in a string passed to eval() causes a NameError. 
Doesn't seem to be a problem in python 2.6

I have attempted to run the attached test cases (test_eval_comp.py)
using the following builds of python:

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32

Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32

Python 3.1a1 (r31a1:70244, Mar  8 2009, 18:15:03) [MSC v.1500 32 bit
(Intel)] on win32

All tests passed with Python 2.6.1.  The following five tests failed
with Python 3.0.1 and 3.1a1

EvalWithComprehensionTestCase.test_local_var
    NameError: global name 'value' is not defined
EvalWithComprehensionTestCase.test_function_arg
    NameError: global name 'value' is not defined
EvalWithComprehensionTestCase.test_self_attrib
    NameError: global name 'self' is not defined
ExampleFromDocsTestCase.test_local_var
    NameError: global name 'vec1' is not defined
NestedComprehensionExampleFromDocsTestCase.test_local_var
    NameError: global name 'mat' is not defined

----------
files: test_eval_comp.py
messages: 83852
nosy: evan.greensmith
severity: normal
status: open
title: Local variables unavailable for operation of list comprehension when using eval()
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13382/test_eval_comp.py

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

From report at bugs.python.org  Fri Mar 20 19:34:41 2009
From: report at bugs.python.org (Aki)
Date: Fri, 20 Mar 2009 18:34:41 +0000
Subject: [New-bugs-announce] [issue5527] multiprocessing won't work with
	Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>


New submission from Aki <akineko at users.sourceforge.net>:

Hello,

The attached test case, which uses multiprocessing module to run Tkinter
GUI process, runs flawlessly under Solaris but hung under Linux (CentOS5).

The test case is a trimmed version of much larger program but it still
exhibits the same problem.
I got a suggestion to use a function rather than a method of a class.
But it didn't make any difference.

I may have overlooked something but as far as I review my code, I
couldn't find anything that explains why the test case won't work (In
fact, it works under Solaris).

----------
components: Library (Lib)
files: tk_test.py
messages: 83867
nosy: akineko
severity: normal
status: open
title: multiprocessing won't work with Tkinter (under Linux)
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file13383/tk_test.py

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

From report at bugs.python.org  Fri Mar 20 23:33:38 2009
From: report at bugs.python.org (Chris)
Date: Fri, 20 Mar 2009 22:33:38 +0000
Subject: [New-bugs-announce] [issue5528] Unable to launch IDLE on Windows
In-Reply-To: <1237588418.03.0.370218080743.issue5528@psf.upfronthosting.co.za>
Message-ID: <1237588418.03.0.370218080743.issue5528@psf.upfronthosting.co.za>


New submission from Chris <chrisaroy at yahoo.com>:

I have recently installed python 2.6 and I have been successfully able 
to run python from a command line and from the Python command line.  
However, when I try to launch the IDLE, all I get is a window that 
flashes.  I tried launching the IDLE from a command line with the 
following command:  
c:\Python26\Lib\idlelib>idle.py -n

I get the following error:
************************************************
Traceback (most recent call last):
  File "C:\Python26\Lib\idlelib\idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "C:\Python26\lib\idlelib\PyShell.py", line 1386, in main
    root = Tk(className="Idle")
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1643, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, 
interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following 
directories:
    {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTOOLS/Python22/tcl/tcl8.5 
C:/Python2
6/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library 
C:/tcl8.5.2/libra
ry C:/tcl8.5.2/library

C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl: version conflict for 
package "Tcl": ha
ve 8.5.2, need exactly 8.4
version conflict for package "Tcl": have 8.5.2, need exactly 8.4
    while executing
"package require -exact Tcl 8.4"
    (file "C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl" line 19)
    invoked from within
"source C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source $tclfile]"

This probably means that Tcl wasn't installed properly.
*************************************************************

I tried changing the python path from c:\IBMTOOLS\Python22 to 
C:\Python26, but that did not work. 

One other note is that I do not have adminstrator priviledges on this 
computer.

----------
components: IDLE
messages: 83877
nosy: croy
severity: normal
status: open
title: Unable to launch IDLE on Windows
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 21 04:22:42 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2009 03:22:42 +0000
Subject: [New-bugs-announce] [issue5529] Backport sys module docs involving
	import to 2.7
In-Reply-To: <1237605762.97.0.593625711393.issue5529@psf.upfronthosting.co.za>
Message-ID: <1237605762.97.0.593625711393.issue5529@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The updated documentation in py3k involving the sys module and imports
(meta_path, path_hooks, and path_importer_cache) should get backported
to trunk. Slightly involved since there are glossary term references
that have not been backported.

----------
assignee: georg.brandl
components: Documentation
messages: 83917
nosy: brett.cannon, georg.brandl
priority: low
severity: normal
stage: needs patch
status: open
title: Backport sys module docs involving import to 2.7
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 21 06:02:41 2009
From: report at bugs.python.org (Jess Austin)
Date: Sat, 21 Mar 2009 05:02:41 +0000
Subject: [New-bugs-announce] [issue5530] datetime class names should obey
	PEP 8 CapWords convention
In-Reply-To: <1237611761.05.0.556904304127.issue5530@psf.upfronthosting.co.za>
Message-ID: <1237611761.05.0.556904304127.issue5530@psf.upfronthosting.co.za>


New submission from Jess Austin <jess.austin at gmail.com>:

Class names that comply with the CapWords naming convention described in
PEP 8 (http://www.python.org/dev/peps/pep-0008/) are preferred. See the
recent discussion that included the BDFL's recommendations at
http://mail.python.org/pipermail/python-dev/2009-March/086684.html.

Per those recommendations, the attached patch updates every class to
expose a CapWords name to python:

datetime.timedelta  -->  datetime.TimeDelta
datetime.date       -->  datetime.Date
datetime.tzinfo     -->  datetime.TZInfo
datetime.time       -->  datetime.Time
datetime.datetime   -->  datetime.DateTime

In addition, the old lowercase names are reproduced as derived classes,
the methods of which throw PendingDeprecationWarning, and the docstrings
of which advise using the new CapWords class names. The test_datetime.py
unit test is updated to check for proper functionality and for the
presence of the pending deprecation warnings. (This patch relies on the
previously-submitted refactoring patch attached to Issue 5520,
http://bugs.python.org/issue5520.) Various other tests and support files
are updated to use the new CapWords class names.

The current patch still fails one test in test_datetime.py, due to
previously-existing Issue 5516, http://bugs.python.org/issue5516.

This patch includes no documentation updates.

----------
components: Library (Lib)
files: pending_dep.diff
keywords: patch
messages: 83921
nosy: jess.austin
severity: normal
status: open
title: datetime class names should obey PEP 8 CapWords convention
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13386/pending_dep.diff

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

From report at bugs.python.org  Sat Mar 21 10:52:37 2009
From: report at bugs.python.org (Tim Cuthbertson)
Date: Sat, 21 Mar 2009 09:52:37 +0000
Subject: [New-bugs-announce] [issue5531] unittest: allow failures in
	tearDown method
In-Reply-To: <1237629157.74.0.0990473218389.issue5531@psf.upfronthosting.co.za>
Message-ID: <1237629157.74.0.0990473218389.issue5531@psf.upfronthosting.co.za>


New submission from Tim Cuthbertson <tim3d.junk at gmail.com>:

This patch adds the behaviour that when a unittest.failureException is
thrown in a TestCase's tearDown method, the test case is added to the
failures list (instead of the errors list, and only when the test case
body has passed successfully).

In some circumstances, tests may want to assert that something happens
at some point during the body of a test, and the best time to make these
checks can be in the tearDown method.

This is a modification I've made during development of my mocktest
library (https://github.com/gfxmonk/mocktest/tree), and I believe it is
beneficial to have as the default unittest behaviour.

----------
components: Extension Modules
files: unittest-fail-on-teardown-0.patch
keywords: patch
messages: 83927
nosy: gfxmonk
severity: normal
status: open
title: unittest: allow failures in tearDown method
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/file13387/unittest-fail-on-teardown-0.patch

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

From report at bugs.python.org  Sat Mar 21 19:10:46 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 21 Mar 2009 18:10:46 +0000
Subject: [New-bugs-announce] [issue5532] imap usage in itertools
	unique_justseen recipe
In-Reply-To: <1237659046.24.0.591034615164.issue5532@psf.upfronthosting.co.za>
Message-ID: <1237659046.24.0.591034615164.issue5532@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

The recipe for "unique_justseen" listed on:
http://docs.python.org/3.0/library/itertools.html
uses "imap", which is not available in Python 3.0.

I fixed it by changing "imap" to just "map", and I also changing
"itemgetter" to "operator.itemgetter" to make the namespace usage
clearer in the recipe:

Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from itertools import *
>>> import operator
>>> def unique_justseen(iterable, key=None):
...     "List unique elements, preserving order. Remember only the
element just
seen."
...     # unique_justseen('AAAABBBCCDAABBB') --> A B C D A B
...     # unique_justseen('ABBCcAD', str.lower) --> A B C A D
...     return map(next, map(operator.itemgetter(1), groupby(iterable,
key)))
...
>>> unique_justseen('AAAABBBCCDAABBB')
<map object at 0x00BB2690>
>>> list(unique_justseen('AAAABBBCCDAABBB'))
['A', 'B', 'C', 'D', 'A', 'B']
>>> unique_justseen('ABBCcAD', str.lower)
<map object at 0x00BB2650>
>>> list(unique_justseen('ABBCcAD', str.lower))
['A', 'B', 'C', 'A', 'D']
>>>

----------
assignee: georg.brandl
components: Documentation
messages: 83943
nosy: georg.brandl, mnewman
severity: normal
status: open
title: imap usage in itertools unique_justseen recipe
versions: Python 3.0

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

From report at bugs.python.org  Sat Mar 21 19:16:37 2009
From: report at bugs.python.org (Aristotelis Mikropoulos)
Date: Sat, 21 Mar 2009 18:16:37 +0000
Subject: [New-bugs-announce] [issue5533] unittest can't deal with packages
In-Reply-To: <1237659397.93.0.630701014314.issue5533@psf.upfronthosting.co.za>
Message-ID: <1237659397.93.0.630701014314.issue5533@psf.upfronthosting.co.za>


New submission from Aristotelis Mikropoulos <amikrop at gmail.com>:

There is a problem with unittest, as it cannot handle package imports.
This http://dpaste.com/17315/ proves it.

----------
components: Library (Lib)
messages: 83945
nosy: Indy
severity: normal
status: open
title: unittest can't deal with packages
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Mar 22 07:35:43 2009
From: report at bugs.python.org (Donald O'Donnell)
Date: Sun, 22 Mar 2009 06:35:43 +0000
Subject: [New-bugs-announce] [issue5534] Decimal __format__ reverses meaning
	of '<' and '>'	alignment specs
In-Reply-To: <1237703743.06.0.452434230687.issue5534@psf.upfronthosting.co.za>
Message-ID: <1237703743.06.0.452434230687.issue5534@psf.upfronthosting.co.za>


New submission from Donald O'Donnell <upwestdon at gmail.com>:

decimal.py ver 2.6:
    line 5474 is "if align == '<':"  s/b  "if align == '>':"
    line 5476 is "if align == '>':"  s/b  "if align == '<':"

decimal.py ver 3.01:
    line 5578 is "if align == '<':"  s/b  "if align == '>':"
    line 5580 is "if align == '>':"  s/b  "if align == '<':"

----------
components: Library (Lib)
messages: 83958
nosy: donodonnell
severity: normal
status: open
title: Decimal __format__ reverses meaning of '<' and '>' alignment specs
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/issue5534>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:03:40 2009
From: report at bugs.python.org (Pierre Hanser)
Date: Sun, 22 Mar 2009 08:03:40 +0000
Subject: [New-bugs-announce] [issue5535] json custom encoder not fully
	functionnal
In-Reply-To: <1237709020.89.0.211179227863.issue5535@psf.upfronthosting.co.za>
Message-ID: <1237709020.89.0.211179227863.issue5535@psf.upfronthosting.co.za>


New submission from Pierre Hanser <hanser at club-internet.fr>:

The json module provides an encoder python -> json.
The encoding may be specialized by the user, using
the cls parameter of the dumps function.

But all simple types are always handled by the library encoder,
the user encoder is only used as a last resort one, for unknown types.

This is not described nor intuitive, and it prevents specifying a custom
encoder for classes which inherit from simple type.

in the provided example (thanks Raymond) a user defined boolean
type, inheriting from int, is handled as int where you would prefer
it to be handled as a json boolean through a custom encoder.

problem seen on simplejson-2.0.9 or official python 2.6.1

----------
components: Library (Lib)
files: jsonCustomEncoder.py
messages: 83962
nosy: phanser
severity: normal
status: open
title: json custom encoder not fully functionnal
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13393/jsonCustomEncoder.py

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

From report at bugs.python.org  Sun Mar 22 13:28:55 2009
From: report at bugs.python.org (Petr Dolezal)
Date: Sun, 22 Mar 2009 12:28:55 +0000
Subject: [New-bugs-announce] [issue5536] urllib: urlretrieve() does not
	close file objects on	failure
In-Reply-To: <1237724935.59.0.818776278278.issue5536@psf.upfronthosting.co.za>
Message-ID: <1237724935.59.0.818776278278.issue5536@psf.upfronthosting.co.za>


New submission from Petr Dolezal <petr.dolezal at matfyz.cz>:

urllib.request.urlretrieve() does not close the file object created for
the retrieval when it fails during processing of the incoming data and
raises an exception (e.g. on HTTP 404 response). Therefore the file
remains opened until the process terminates and the OS itself closes the
orphaned file handle.

This behaviour may result in orphaned temporary/incomplete files. It is
also not just a resource leak, but it has another bad side effect on
Windows platform (at least): the file can't be deleted (due to the used
creation mode) before the handle is closed. But the entire file object,
including the handle, is lost due to the exception, thus nobody
(including the process itself) is able to delete the file until the
process terminates.

Consider this code snippet demonstrating the described behaviour:
import os
import urllib.request
FILENAME = 'nonexistent.html'
try:
    # The host must be valid, else the address resolving fails
    # before the target file is even created. But existing host
    # and non-existent resource is exactly what's the problem.
    NON_EXISTENT_URL = 'http://www.python.org/nonexistent.html'
    urllib.request.urlretrieve(NON_EXISTENT_URL, FILENAME)
except Exception:
    if os.path.exists(FILENAME):
        print('File exists! Attempting to delete.')
        os.unlink(FILENAME)
        print('Succeeded.')

On Windows, following output appears:
File exists! Attempting to delete.
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    urllib.request.urlretrieve(NON_EXISTENT_URL, FILENAME)
  File "C:\Program Files\Python\lib\urllib\request.py", line 134, in
urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "C:\Program Files\Python\lib\urllib\request.py", line 1502, in
retrieve
    block = fp.read(bs)
  File "C:\Program Files\Python\lib\io.py", line 572, in read
    self._checkClosed()
  File "C:\Program Files\Python\lib\io.py", line 450, in _checkClosed
    if msg is None else msg)
ValueError: I/O operation on closed file.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 10, in <module>
    os.unlink(FILENAME)
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process: 'nonexistent.html'

As a quick fix it is possible to ensure closing both source and target
file objects in finally blocks. I also assume the function should delete
the target file on an exception: the file is not only incomplete, but
its name is also unknown to the client code in the case of the temporary
file made by urlretrieve() itself. If the client code is interested in
partial downloads, I guess it should take another way to retrieve the
resource as urlretrieve() interface doesn't look like supporting
something like partial download.

Anyway, the proposed solution is still not the optimal one: ValueError
with message "I/O operation on closed handle" is really nothing I would
expect as a valid error when downloading a non-existent web page. I
guess a check on the source file object before reading begins would
discover the problem early and raise more appropriate IOError or
something like that.

Note:
This bug report probably applies to older versions of urllib, but I
can't verify it now. I know at least I spotted it in 2.6 just before I
upgraded to 3.0.1.

----------
components: Library (Lib)
messages: 83970
nosy: pdolezal
severity: normal
status: open
title: urllib: urlretrieve() does not close file objects on failure
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Mar 22 18:50:31 2009
From: report at bugs.python.org (Chris Hollenbeck)
Date: Sun, 22 Mar 2009 17:50:31 +0000
Subject: [New-bugs-announce] [issue5537] LWPCookieJar cannot handle cookies
	with expirations of	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>


New submission from Chris Hollenbeck <chris.hollenbeck at gmail.com>:

The LWPCookieJar can be saved on 64-bit Ubuntu, but not on 32-bit Ubuntu
when the expiration year is greater than 2038.  This has not been tested
on any other Intel-compatible Linux platform, though it appears related
to the Year 2038 bug.  The MozillaCookieJar does not have a problem
saving on either architecture.

A sample crash is shown below:

  File "/home/user/xblstatus/LiveConnect.py", line 189, in connect
    self.cookiejar.save(self.cookieFile)
  File "/usr/lib/python2.5/_LWPCookieJar.py", line 89, in save
    f.write(self.as_lwp_str(ignore_discard, ignore_expires))
  File "/usr/lib/python2.5/_LWPCookieJar.py", line 75, in as_lwp_str
    r.append("Set-Cookie3: %s" % lwp_cookie_str(cookie))
  File "/usr/lib/python2.5/_LWPCookieJar.py", line 35, in lwp_cookie_str
    time2isoz(float(cookie.expires))))
  File "/usr/lib/python2.5/cookielib.py", line 98, in time2isoz
    year, mon, mday, hour, min, sec = time.gmtime(t)[:6]
ValueError: timestamp out of range for platform time_t

---

The cookie jar and urllib2 integration was done with:

self.cookiejar = cookielib.LWPCookieJar()

self.opener =
urllib2.build_opener(urllib2.HTTPCookieProcessor(self.cookiejar))

urllib2.install_opener(self.opener)

---

The code used to save the cookie after accessing the web page was:

self.cookiejar.save(self.cookieFile)

The cookieFile variable is simply the default location of the cookie
file for saving in the program.

----------
components: Library (Lib)
messages: 83979
nosy: hollec
severity: normal
status: open
title: LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 22 22:16:23 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Sun, 22 Mar 2009 21:16:23 +0000
Subject: [New-bugs-announce] [issue5538] tearDown in unittest should be
	executed regardless of	result in setUp
In-Reply-To: <1237756583.23.0.244511202702.issue5538@psf.upfronthosting.co.za>
Message-ID: <1237756583.23.0.244511202702.issue5538@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

While trying to deal with some annoying issues with setting up and
tearing down consoles via pexpect, I noticed that the teardown functions
/ methods weren't being executed via nose.

After applying this change to 2.4.5 and 2.6.1, things work as expected
(note: this patch only applies cleanly with 2.4.5 AFAICT -- it didn't
work with 2.6.1).

My expectations are:

========

I'd expect that the best fix would be for tearDown to be unconditionally
called if setUp is called, s.t. testers can ensure that the operating
state of the UUT and testbed are at a predefined state.

So in my testcase provided, I would expect the following flow:

1. Keeping assert False in setup_module...
`Calling setup_module'
<assert fails>
`Calling teardown_module'

2. Removing assert False from setup_module...

`Calling setup_module'
- `Calling function_setup'
<assert fails>
- `Calling function_teardown'
- `Calling TestClass:setUp'
<assert fails>
- `Calling TestClass:tearDown'
`Calling teardown_module'

If this isn't done, it makes some operations, like tearing down consoles
with pexpect _extremely_ painful to perform...

========

Please see <http://code.google.com/p/python-nose/issues/detail?id=234>
for more details.

----------
components: Tests
files: issue-blah-2.4.5.diff
keywords: patch
messages: 83983
nosy: yaneurabeya
severity: normal
status: open
title: tearDown in unittest should be executed regardless of result in setUp
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file13397/issue-blah-2.4.5.diff

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

From report at bugs.python.org  Mon Mar 23 01:21:46 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 23 Mar 2009 00:21:46 +0000
Subject: [New-bugs-announce] [issue5539] open documentation unclear
In-Reply-To: <1237767706.4.0.494617404743.issue5539@psf.upfronthosting.co.za>
Message-ID: <1237767706.4.0.494617404743.issue5539@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

See thread
http://groups.google.com/group/comp.lang.python/browse_thread/thread/85e
c714aa6898d84#


En Sun, 22 Mar 2009 19:12:13 -0300, Benjamin Peterson   
<benja... at python.org> escribi?: 
> Gabriel Genellina <gagsl-py2 <at> yahoo.com.ar> writes: 
>> The undocumented behavior is relying on the open() builtin to return 
a 
>> BufferedReader for a binary file. 
> I don't see the problem. open() will return some BufferedIOBase   
> implmentor, and 
> that's all that TextIOWrapper needs. 


How do you know? AFAIK, the return value of open() is completely   
undocumented: 
http://docs.python.org/3.0/library/functions.html#open 
And if you open the  file in text mode, the return value isn't a   
BufferedIOBase. 
-- 
Gabriel Genellina 

The return value of open() is a "stream", according to 
http://docs.python.org/dev/py3k/library/io.html#module-io

----------
messages: 83990
nosy: LambertDW
severity: normal
status: open
title: open documentation unclear

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

From report at bugs.python.org  Mon Mar 23 01:23:50 2009
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 23 Mar 2009 00:23:50 +0000
Subject: [New-bugs-announce] [issue5540] "file objects" in python 3 tutorial
In-Reply-To: <1237767830.7.0.116685302416.issue5540@psf.upfronthosting.co.za>
Message-ID: <1237767830.7.0.116685302416.issue5540@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/py3k/tutorial/inputoutput.html#methods-of-
file-objects

Is it proper to discuss file objects in py3K?

----------
assignee: georg.brandl
components: Documentation
messages: 83991
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: "file objects" in python 3 tutorial
versions: Python 3.0

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

From report at bugs.python.org  Mon Mar 23 09:26:24 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 23 Mar 2009 08:26:24 +0000
Subject: [New-bugs-announce] [issue5541] File's current position
	inconsistent with 'a+' mode
In-Reply-To: <1237796784.39.0.86522917715.issue5541@psf.upfronthosting.co.za>
Message-ID: <1237796784.39.0.86522917715.issue5541@psf.upfronthosting.co.za>


New submission from Lukas Lueg <knabberknusperhaus at yahoo.de>:

The file pointer's behaviour after opening a file in 'a+b' mode is not
consistent among platforms: The pointer is set to the beginning of the
file on Linux and to the end of the file on MacOS. You have to call
.seek(0) before calling .read() to get consistent behaviour on all
platforms.

While this is not a serious problem, it somewhat violates the rule of
least surprise. Also we are not bound to this behaviour and can make
sure that all file objects have their respective positions well-defined
after object-creation.

Thoughts?

----------
messages: 83997
nosy: ebfe
severity: normal
status: open
title: File's current position inconsistent with 'a+' mode
versions: Python 2.5

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

From report at bugs.python.org  Mon Mar 23 10:29:10 2009
From: report at bugs.python.org (Jason Davies)
Date: Mon, 23 Mar 2009 09:29:10 +0000
Subject: [New-bugs-announce] [issue5542] Socket is closed prematurely in
	httplib, if server sends response before request body has been sent
In-Reply-To: <1237800550.85.0.782891199129.issue5542@psf.upfronthosting.co.za>
Message-ID: <1237800550.85.0.782891199129.issue5542@psf.upfronthosting.co.za>


New submission from Jason Davies <jason at jasondavies.com>:

I came across this bug when trying to use CouchDB-Python to PUT an
attachment using HTTP authentication (using the httplib2 library). 
Essentially what httplib2 does is this:

1. Attempt PUT with no auth credentials
2. If a 401 response is received, try again with credentials

However, CouchDB sends a 401 response as soon as it has consumed the
request headers, and before the request body has been fully sent by the
client.

This triggers a bug in both httplib and httplib2, whereby they raise
exceptions due to a broken pipe being encountered when trying to finish
sending the request body.

It seems that Python's httplib checks for broken pipe errors and closes
the connection entirely when they occur when making a request.  This is
unhelpful if a legitimate response was sent and the socket was closed
early by the server.

The offending try/except handler is in httplib.HttpConnection.send and
has a comment saying:

# send the data to the server. if we get a broken pipe, then close
# the socket. we want to reconnect when somebody tries to send again.

This is wrong, as someone might want to read the response before closing
the socket.

For reference, the CouchDB-Python issue is:
http://code.google.com/p/couchdb-python/issues/detail?id=68

This bug may also be related to: http://bugs.python.org/issue3566

----------
components: Library (Lib)
messages: 84000
nosy: jasondavies
severity: normal
status: open
title: Socket is closed prematurely in httplib, if server sends response before request body has been sent
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 23 11:01:48 2009
From: report at bugs.python.org (Alexandru V. Mosoi)
Date: Mon, 23 Mar 2009 10:01:48 +0000
Subject: [New-bugs-announce] [issue5543] sys.last_type missing
In-Reply-To: <1237802508.05.0.8782027083.issue5543@psf.upfronthosting.co.za>
Message-ID: <1237802508.05.0.8782027083.issue5543@psf.upfronthosting.co.za>


New submission from Alexandru V. Mosoi <brtzsnr at gmail.com>:

`sys.last_type' is missing and thus, traceback.print_last() is not working.

$ python
Python 2.6.1 (r261:67515, Dec  7 2008, 18:56:39) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import sys
>>> try: raise Exception('asdf')
... except: print sys.last_type
... 
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
AttributeError: 'module' object has no attribute 'last_type'

>>> import traceback
>>> try: raise Exception('asdf')
... except: traceback.print_last()
... 
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
AttributeError: 'module' object has no attribute 'last_type'

----------
components: Library (Lib)
messages: 84002
nosy: brtzsnr
severity: normal
status: open
title: sys.last_type missing
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 23 17:07:32 2009
From: report at bugs.python.org (Andreas Schawo)
Date: Mon, 23 Mar 2009 16:07:32 +0000
Subject: [New-bugs-announce] [issue5544] test_fileio fials on windows MSVC
	Assertion
In-Reply-To: <1237824452.26.0.278609096502.issue5544@psf.upfronthosting.co.za>
Message-ID: <1237824452.26.0.278609096502.issue5544@psf.upfronthosting.co.za>


New submission from Andreas Schawo <andreas.schawo at gmail.com>:

test_fileio fails on windows with MSVC "Debug Assertion failed" message
since last week.

----------
components: Tests
messages: 84015
nosy: andreas.schawo, pitrou
severity: normal
status: open
title: test_fileio fials on windows MSVC Assertion
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar 23 18:15:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 23 Mar 2009 17:15:57 +0000
Subject: [New-bugs-announce] [issue5545] multiprocessing: switch to autoconf
	detection of platform	values
In-Reply-To: <1237828557.72.0.911819794631.issue5545@psf.upfronthosting.co.za>
Message-ID: <1237828557.72.0.911819794631.issue5545@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

See mail thread:
http://mail.python.org/pipermail/python-dev/2009-March/087418.html

And Christian's checkin to the back port:
http://code.google.com/p/python-multiprocessing/source/detail?r=64#

Need to take into the account information here (for my own notes):
http://bugs.python.org/issue5400
http://bugs.python.org/issue3876
http://bugs.python.org/msg83495
http://bugs.python.org/issue3110

----------
assignee: jnoller
messages: 84019
nosy: christian.heimes, jnoller
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing: switch to autoconf detection of platform values
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Mar 23 22:38:36 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 23 Mar 2009 21:38:36 +0000
Subject: [New-bugs-announce] [issue5546] PyDict_SetItemString mentions
	PyString_FromString which	does not exist
In-Reply-To: <1237844316.22.0.714323414222.issue5546@psf.upfronthosting.co.za>
Message-ID: <1237844316.22.0.714323414222.issue5546@psf.upfronthosting.co.za>


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

The documentation for PyDict_SetItemString contains the text "The key
object is created using PyString_FromString(key)".  However,
PyString_FromString has been removed in Python 3.

Perhaps it should read PyUnicode_FromString?

----------
assignee: georg.brandl
components: Documentation
messages: 84041
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: PyDict_SetItemString mentions PyString_FromString which does not exist
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 23 23:17:44 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 23 Mar 2009 22:17:44 +0000
Subject: [New-bugs-announce] [issue5547] The Py_InitModule functions no
	longer exist, but remain in the docs
In-Reply-To: <1237846664.94.0.236567796822.issue5547@psf.upfronthosting.co.za>
Message-ID: <1237846664.94.0.236567796822.issue5547@psf.upfronthosting.co.za>


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

Py_InitModule, Py_InitModule3, etc. are mentioned in the docs (including
the extending tutorial!), but no longer exist.

----------
assignee: georg.brandl
components: Documentation
messages: 84044
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: The Py_InitModule functions no longer exist, but remain in the docs
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 23 23:19:09 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 23 Mar 2009 22:19:09 +0000
Subject: [New-bugs-announce] [issue5548] In the tutorial,
	PyMODINIT_FUNC is shown as having a return type of void rather
	than	PyObject *
In-Reply-To: <1237846749.48.0.0822005616246.issue5548@psf.upfronthosting.co.za>
Message-ID: <1237846749.48.0.0822005616246.issue5548@psf.upfronthosting.co.za>


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

PyMODINIT_FUNC functions should return the module object or NULL on
error.  Or at least that what it looks like the core modules are doing. ;-)

----------
assignee: georg.brandl
components: Documentation
messages: 84045
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: In the tutorial, PyMODINIT_FUNC is shown as having a return type of void rather than PyObject *
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 23 23:21:09 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 23 Mar 2009 22:21:09 +0000
Subject: [New-bugs-announce] [issue5549] PyModule_Create and PyModuleDef are
	undocumented
Message-ID: <1237846869.86.0.109740749085.issue5549@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: PyModule_Create and PyModuleDef are undocumented
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 24 05:49:02 2009
From: report at bugs.python.org (cocobear)
Date: Tue, 24 Mar 2009 04:49:02 +0000
Subject: [New-bugs-announce] [issue5550] urllib2 use of opener.addheaders
In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za>
Message-ID: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za>


New submission from cocobear <cocobear.cn at gmail.com>:

take a look at following code:
<code>
import urllib2

headers = [("Content-Type","application/oct-stream"),]
opener = urllib2.build_opener()
opener.addheaders = headers
urllib2.install_opener(opener)
print "after install_opener"

ret = opener.open('http://www.google.com',data="word=ss")
print ret.read()
</code>

I got real send data by wireshark?

POST / HTTP/1.1

Accept-Encoding: identity

Content-Length: 7

Host: www.dict.cn

Content-Type: application/x-www-form-urlencoded

Connection: close



word=ss


I had already set HTTP header of Content-Type, but actally urllib2
change this header.

I got this piece of code from urllib2.py:

       if request.has_data():  # POST
           data = request.get_data()
           if not request.has_header('Content-type'):
               request.add_unredirected_header(
                   'Content-type',
                   'application/x-www-form-urlencoded')
           if not request.has_header('Content-length'):
               request.add_unredirected_header(
                   'Content-length', '%d' % len(data))

       scheme, sel = splittype(request.get_selector())
       sel_host, sel_path = splithost(sel)
       if not request.has_header('Host'):
           request.add_unredirected_header('Host', sel_host or host)
       for name, value in self.parent.addheaders:
           name = name.capitalize()
           if not request.has_header(name):
               request.add_unredirected_header(name, value)


first,urllib2 will add Content-Type if it's POST method, then it try to
add headers which holded by opener, but there's already 'Content-Type',
so the attribute->addheaders of opener will not append.

I can use Request to add 'Content-Type' header?

 request = urllib2.Request(url,headers=headers,data=body)

The example code that I wrote doesn't correct? or it's a problem of urllib2?

----------
components: Library (Lib)
messages: 84058
nosy: cocobear
severity: normal
status: open
title: urllib2 use of opener.addheaders
type: behavior
versions: Python 2.5

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

From =?utf-8?b?IkrDvHJnZW4gQS4gRXJoYXJkIiA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?= at psf.upfronthosting.co.za  Tue Mar 24 07:33:20 2009
From: =?utf-8?b?IkrDvHJnZW4gQS4gRXJoYXJkIiA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?= at psf.upfronthosting.co.za (=?utf-8?b?IkrDvHJnZW4gQS4gRXJoYXJkIiA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?= at psf.upfronthosting.co.za)
Date: Tue, 24 Mar 2009 06:33:20 +0000
Subject: [New-bugs-announce] [issue5551] os.path.ismount take a cross-device
	symlink for a	mountpoint
In-Reply-To: <1237876400.19.0.961076831302.issue5551@psf.upfronthosting.co.za>
Message-ID: <1237876400.19.0.961076831302.issue5551@psf.upfronthosting.co.za>


New submission from J?rgen A. Erhard <jae at users.sourceforge.net>:

Confirmed to exist in 2.6.1 (r261:67515) and 3.0 (r30:67503).  Seems to
have been introduced somewhere in the 2.5 timeline, as 2.4 doesn't show
this bug.

----------
components: Library (Lib)
messages: 84060
nosy: jae
severity: normal
status: open
title: os.path.ismount take a cross-device symlink for a mountpoint
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Mar 24 14:42:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Mar 2009 13:42:06 +0000
Subject: [New-bugs-announce] [issue5552] With invalid FD,
	os.device_encoding() returns None under Linux but raises an
	error	under Windows
In-Reply-To: <1237902126.36.0.583275173569.issue5552@psf.upfronthosting.co.za>
Message-ID: <1237902126.36.0.583275173569.issue5552@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a potentially annoying incompatibility between platforms.
Under Linux:

>>> import os
>>> print(os.device_encoding(1000))
None

----------
components: Interpreter Core
messages: 84079
nosy: pitrou
priority: normal
severity: normal
status: open
title: With invalid FD, os.device_encoding() returns None under Linux but raises an error under Windows
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 24 15:49:19 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 24 Mar 2009 14:49:19 +0000
Subject: [New-bugs-announce] [issue5553] Py_LOCAL_INLINE(type) doesn't
	actually inline except	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>


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

Below is the relevant snippet from pyport.h.  There are two reasons that
Py_LOCAL_INLINE doesn't actually emit the "inline" keyword (unless
compiling with MSC).  

First, "configure" does not have code to test the compiler and define
USE_INLINE if appropriate.

Second, the code undefines USE_INLINE even if defined! (oops? ;) )

The snippet is replicated with slightly different names near the top of
_sre.c.

#undef USE_INLINE /* XXX - set via configure? */

#if defined(_MSC_VER)
#if defined(PY_LOCAL_AGGRESSIVE)
/* enable more aggressive optimization for visual studio */
#pragma optimize("agtw", on)
#endif
/* ignore warnings if the compiler decides not to inline a function */
#pragma warning(disable: 4710)
/* fastest possible local call under MSVC */
#define Py_LOCAL(type) static type __fastcall
#define Py_LOCAL_INLINE(type) static __inline type __fastcall
#elif defined(USE_INLINE)
#define Py_LOCAL(type) static type
#define Py_LOCAL_INLINE(type) static inline type
#else
#define Py_LOCAL(type) static type
#define Py_LOCAL_INLINE(type) static type
#endif

----------
messages: 84089
nosy: stutzbach
severity: normal
status: open
title: Py_LOCAL_INLINE(type) doesn't actually inline except using MSC
versions: Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 24 18:24:57 2009
From: report at bugs.python.org (Ultrasick)
Date: Tue, 24 Mar 2009 17:24:57 +0000
Subject: [New-bugs-announce] [issue5554] file.read() doesn't read the whole
	file
In-Reply-To: <1237915497.04.0.963901802383.issue5554@psf.upfronthosting.co.za>
Message-ID: <1237915497.04.0.963901802383.issue5554@psf.upfronthosting.co.za>


New submission from Ultrasick <python at ontheserver.de>:

--------------------------------------------------------
# open the file
file = open('F:/test.bmp', 'r')

# read the content
content = file.read()

# close the file
file.close()

print "len(content): " + str(len(content))
--------------------------------------------------------
Returns

len(content): 1522

on my computer. But it should be something like

len(content): 1248858

----------
components: Interpreter Core
files: test.bmp
messages: 84098
nosy: Ultrasick
severity: normal
status: open
title: file.read() doesn't read the whole file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13407/test.bmp

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

From report at bugs.python.org  Tue Mar 24 19:01:15 2009
From: report at bugs.python.org (Aaron Sherman)
Date: Tue, 24 Mar 2009 18:01:15 +0000
Subject: [New-bugs-announce] [issue5555] optparse
In-Reply-To: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>
Message-ID: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>


New submission from Aaron Sherman <ajs at ajs.com>:

First off, I want to be clear that this isn't a request for changes to
functionality, nor for debate over decisions which have already been
made. This is purely a request for correction to mis-statements about
the nature and origins of optparse's handling in its documentation.

This is an edited-down excerpt form the optparse documentation from:

http://docs.python.org/library/optparse.html

"... the traditional Unix syntax is a hyphen (?-?) followed by a single
letter [...] Some other option syntaxes that the world has seen include:
    * a hyphen followed by a few letters, e.g. "-pf" [...]
[...] These option syntaxes are not supported by optparse, and they
never will be. This is deliberate: the first three are non-standard on
any environment[...]"

While, obviously, optparse is free to choose whatever model of option
parsing the developers like, the above text should be removed or
corrected. Traditional Unix command-line usage is detailed in the POSIX
specification's definition of various utilities and the optparse C
function as documented here:

http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html

which lays out this example:

"This code accepts any of the following as equivalent:
cmd -ao arg path path
cmd -a -o arg path path"

Note that the concatenation of single-character arguments is, in fact,
in conformance to the POSIX standard, GNU coding conventions, and Unix
best-practices since at least the mid-1980s. This clearly contradicts
the statement from Python's documentation. For further reference, see:

any Unix or Unix-like system's "man 3 getopt"
http://www.faqs.org/docs/artu/ch10s05.html
http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces
(which refers back to the "POSIX guidelines for the command-line options
of a program")
any Unix or Unix-like system's man pages for a plethora of core
utilities such as rm(1), ls(1), sh(1), cp(1), etc.

A more accurate statement would be:

"optparse has chosen to implement a subset of the GNU coding standard's
command line interface guidelines, allowing for both long and short
options, but not the POSIX-style concatenation of short options."

A rationale for that decision may or may not be included, but I won't
presume to write it since I'm not actually privy to that decision-making
process.

----------
assignee: georg.brandl
components: Documentation
messages: 84103
nosy: ajs, georg.brandl
severity: normal
status: open
title: optparse
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Mar 24 20:32:02 2009
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Tue, 24 Mar 2009 19:32:02 +0000
Subject: [New-bugs-announce] [issue5556] interactive interpreter,
	source encoding
In-Reply-To: <1237923122.0.0.0658736950329.issue5556@psf.upfronthosting.co.za>
Message-ID: <1237923122.0.0.0658736950329.issue5556@psf.upfronthosting.co.za>


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

A few hours ago I sent a comment to the issue #4626. I didn't notice the
issue was closed. So I repeat it here. I'm interested in comments
because I have the feeling it is still a pending annoying isssue.

---

I'm glad to have discovered this topic. I bumped into something similar
when I toyed with an interactive interpreter.

from code import InteractiveInterpreter

ii = InteractiveInterpreter()
source = ...
ii.runsource(source)

What should be the encoding and/or the type (str, bytes) of the "source"
string? Taking into account the encoding of the script which contains
this code, I have the feeling there is always something going wrong,
this can be a "non ascii" char in the source (encoded in utf-8!) or the
interactive interpreter does not accept very well a byte string
representing a utf-8 encoded string.

IDLE is not suffering from this. Its interactive interpreter is somehow
receiving "ucs-2 ready string" from tkinter.

I'm a little bit confused here (win2k, winXP sp2, Python 3.0.1).

----------
components: Interpreter Core
messages: 84107
nosy: jmfauth
severity: normal
status: open
title: interactive interpreter, source encoding
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Mar 24 20:48:44 2009
From: report at bugs.python.org (Tom Goddard)
Date: Tue, 24 Mar 2009 19:48:44 +0000
Subject: [New-bugs-announce] [issue5557] Byte-code compilation uses
	excessive memory
In-Reply-To: <1237924124.82.0.478709056921.issue5557@psf.upfronthosting.co.za>
Message-ID: <1237924124.82.0.478709056921.issue5557@psf.upfronthosting.co.za>


New submission from Tom Goddard <goddard at cgl.ucsf.edu>:

Bytecode compiling large Python files uses an unexpectedly large amount
of memory.  For example, compiling a file containing a list of 5 million
integers uses about 2 Gbytes of memory while the Python file size is
about 40 Mbytes.  The memory used is 50 times the file size.  The
resulting list in Python consumes about 400 Mbytes of memory, so
compiling the byte codes uses about 5 times the memory of the list
object.  Can the byte-code compilation can be made more memory efficient?

The application that creates simlilarly large Python files is a
molecular graphics program called UCSF Chimera that my lab develops.  It
writes session files which are Python code.  Sessions of reasonable size
for Chimera for a given amount of physical memory cannot be
byte-compiled without thrashing, crippling the interactivity of all
software running on the machine.

Here is Python code to produce the test file test.py containing a list
of 5 million integers:

print >>open('test.py','w'), 'x = ', repr(range(5000000))

I tried importing the test.py file with Python 2.5, 2.6.1 and 3.0.1 on
Mac OS 10.5.6.  In each case when the test.pyc file is not present the
python process as monitored by the unix "top" command took about 1.7 Gb
RSS and 2.2 Gb VSZ on a MacBook Pro which has 2 Gb of memory.

----------
components: Interpreter Core
messages: 84108
nosy: goddard
severity: normal
status: open
title: Byte-code compilation uses excessive memory
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 25 00:02:25 2009
From: report at bugs.python.org (xdcdx)
Date: Tue, 24 Mar 2009 23:02:25 +0000
Subject: [New-bugs-announce] [issue5558] Python 3.0.1 doesn't install
	correctly on Mac Os X	10.5.6. with xCode 3.1.2
In-Reply-To: <1237935745.17.0.299901472709.issue5558@psf.upfronthosting.co.za>
Message-ID: <1237935745.17.0.299901472709.issue5558@psf.upfronthosting.co.za>


New submission from xdcdx <agentriot at gmail.com>:

The Python 3.0.1 Mac OS X installer image doesn't generate correct links
for Python3.0 binary interpreter on /usr/local/bin (as the ReadMe says
it will do). I'm using Mac Os X 10.5.6 (Darwin Kernel Version 9.6.0: Mon
Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386).

Otherwise, Python 3.0 framework files seem to be correctly installed in
/Library/Frameworks/Python.framework/Versions/3.0/, and running the
interpreter from there works fine.

Additionally, Python 2.5 and 2.3 are installed on
/System/Library/Frameworks/Python.framework/Versions, and linked from
/usr/bin/python. I'm not sure where did these come from, but I suspect
they were installed with Xcode 3.1.2.

Find the Python 3.0.1 install log attached (I tried to install it twice,
disregard the second time).

If you need more info, just ask.

----------
files: install.log.0.bz2
messages: 84119
nosy: xdcdx
severity: normal
status: open
title: Python 3.0.1 doesn't install correctly on Mac Os X 10.5.6. with xCode 3.1.2
Added file: http://bugs.python.org/file13410/install.log.0.bz2

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

From report at bugs.python.org  Wed Mar 25 04:22:52 2009
From: report at bugs.python.org (Claudio Canepa)
Date: Wed, 25 Mar 2009 03:22:52 +0000
Subject: [New-bugs-announce] [issue5559] IDLE Output Window 's goto fails
	when path has spaces
In-Reply-To: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>
Message-ID: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>


New submission from Claudio Canepa <ccanepacc at gmail.com>:

in windows XP, python 2.6.1, 2.6 , python 2.4
1. do an Edit | 'Find in files' [ it pop ups the Output Window with 
result]
2. Right click over one of the target lines found, click the 'goto file
\line' pop up

If the path in the target line has spaces, it will popup a window with 
title 'No special line' and message 'the line you point at doenst look 
like a valid file name followed by a line number'

posible fix:
in idlelib/OutputWindow.py
replace the literal
r'([^\s]+):\s*(\d+):'
with
r'([^\t\n\r\f\v]+):\s*(\d+):'

fair warning: seems to work in windows XP, dont know about other OSes

----------
components: IDLE
messages: 84142
nosy: ccanepa
severity: normal
status: open
title: IDLE Output Window 's goto fails when path has spaces
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 25 06:16:11 2009
From: report at bugs.python.org (geremy condra)
Date: Wed, 25 Mar 2009 05:16:11 +0000
Subject: [New-bugs-announce] [issue5560] help() no longer reports module
	docstrings
In-Reply-To: <1237958171.84.0.78612071906.issue5560@psf.upfronthosting.co.za>
Message-ID: <1237958171.84.0.78612071906.issue5560@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

In 2.x, help(module) reported the docstrings from name when invoked. In
3.0, it simply reports the location of that module. pydoc3.0 invoked at
the commandline behaves identically.

----------
components: Library (Lib)
messages: 84143
nosy: debatem1
severity: normal
status: open
title: help() no longer reports module docstrings
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Mar 25 17:26:15 2009
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 25 Mar 2009 16:26:15 +0000
Subject: [New-bugs-announce] [issue5561] platform.python_version_tuple
	returns tuple of ints, should be strings
In-Reply-To: <1237998375.74.0.567262091679.issue5561@psf.upfronthosting.co.za>
Message-ID: <1237998375.74.0.567262091679.issue5561@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The documentation for platform.python_version_tuple() says:
"Returns the Python version as tuple (major, minor, patchlevel) of strings."

In 2.4 and 2.5 it correctly returned a tuple of strings.  In 2.6 it
returns a tuple of ints.

In 2.4 and 2.5 the implementation was this:
  return string.split(_sys_version()[0], '.')
In 2.6 it changed to this:
    if hasattr(sys, 'version_info'):
        return sys.version_info[:3]
    return tuple(string.split(_sys_version()[1], '.'))
The fields used from sys.version_info are ints, and always have been.  I
am mystified as to why the "if hasattr" lines were added; they broke it,
and it's not like that's superior information somehow.

I suggest modernizing it slightly when you fix the bug; use the .split()
method on strings.  Like so:
    return tuple(_sys_version()[1].split('.'))

----------
components: Library (Lib)
messages: 84161
nosy: Larry Hastings
severity: normal
status: open
title: platform.python_version_tuple returns tuple of ints, should be strings
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 25 20:46:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Mar 2009 19:46:18 +0000
Subject: [New-bugs-announce] [issue5562] Locale-based date formatting
	crashes on non-ASCII data
In-Reply-To: <1238010378.87.0.1611631381.issue5562@psf.upfronthosting.co.za>
Message-ID: <1238010378.87.0.1611631381.issue5562@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Locale-based date formatting in py3k (using strftime) crashes when asked
to format a month name (or day, I assume) containing non-ASCII characters:

>>> import time
>>> import locale
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
'February'
>>> locale.setlocale(locale.LC_TIME, "fr_FR")
'fr_FR'
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3:
invalid data

It works if I specify the encoding explicitly in the locale name so as
to coincide with the encoding specified in the error message above (but
that's assuming the given encoding-specific locale *is* installed):

>>> locale.setlocale(locale.LC_TIME, "fr_FR.UTF-8")
'fr_FR.UTF-8'
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
'f?vrier'

----------
components: Library (Lib)
messages: 84163
nosy: pitrou
priority: high
severity: normal
status: open
title: Locale-based date formatting crashes on non-ASCII data
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 26 00:32:58 2009
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 25 Mar 2009 23:32:58 +0000
Subject: [New-bugs-announce] [issue5563] Document bdist_msi
In-Reply-To: <1238023978.65.0.898272761153.issue5563@psf.upfronthosting.co.za>
Message-ID: <1238023978.65.0.898272761153.issue5563@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

[Suggested in issue5095 by John Machin]

The 2.6.1 documentation consists of a *single* line:
"distutils.command.bdist_msi ? Build a Microsoft Installer binary
package". The docs should explain briefly what an msi file is, and why a
packager might want to use it instead of wininst.

----------
assignee: georg.brandl
components: Documentation
messages: 84168
nosy: bethard, georg.brandl
severity: normal
status: open
title: Document bdist_msi
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 26 01:52:13 2009
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 26 Mar 2009 00:52:13 +0000
Subject: [New-bugs-announce] [issue5564] os.symlink/os.link docs should say
	old/new, not src/dst
In-Reply-To: <1238028733.0.0.712487268611.issue5564@psf.upfronthosting.co.za>
Message-ID: <1238028733.0.0.712487268611.issue5564@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

"destination" is ambiguous.  It means opposite things, depending on if
it's the symlink creation operation or if it's the symlink itself.

In contrast, "old" is clearly what existed before the operation, and
"new" is what the operation creates.  This terminology is already in use
by os.rename.

----------
assignee: georg.brandl
components: Documentation
messages: 84171
nosy: Rhamphoryncus, georg.brandl
severity: normal
status: open
title: os.symlink/os.link docs should say old/new, not src/dst

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

From =?utf-8?b?UGhpbGlwcCBUw7Zsa2UgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za  Thu Mar 26 08:12:25 2009
From: =?utf-8?b?UGhpbGlwcCBUw7Zsa2UgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za (=?utf-8?b?UGhpbGlwcCBUw7Zsa2UgPHJlcG9ydEBidWdzLnB5dGhvbi5vcmc+?= at psf.upfronthosting.co.za)
Date: Thu, 26 Mar 2009 07:12:25 +0000
Subject: [New-bugs-announce] [issue5565] Strange behavior when I logout()
	with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>


New submission from Philipp T?lke <toelke+pb at model.in.tum.de>:

While researching some strange logs from out firewall and narrowing it
down to a biff-like imap-client written in python we found the following:

To reproduce:

Start a network-sniffer like wireshark on the loopback-interface
In one shell start some network-listener:
$ nc -l -p 12345

In python, connect to it and send some data:
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(("127.0.0.1", 12345))
>>> s.send("Hallo\n");
6

The other shell now looks like:
$ nc -l -p 12345
Hallo

Type in anything and press <Enter> to send. Then quit the nc with C-c.

Then:
>>> s.close()

What I see here is the following:
The two messages are exchanged and nc sends his FIN-Package when
quitting. Python ACKnowledges this package (though intrestingly enough,
with a ack-number one to far (8 instead of 7 in my example)). At the
Moment of the s.close(), it sends another package, containing the same
ACK-Number, the same SEQ-Number(!) and this time the RST-Flag as well.

If I understand correctly, it sends RST, because not everything from the
connection was read by python. Why does it resend the ACK? Why is the
ACK-Number one to high? Why does it reuse the SEQ-Number?

And now to imaplib.IMAP4_SSL. The behavior here seems to me even more
strange:

If I invoke .logout(), the server sends his "BYE" message and after that
a FIN, which python ACKnowledges. At the moment, that the
IMAP4_SSL-object gets out of scope, a RST/ACK-Package is send, that
again re-ACKs the FIN and has the same sequence-number, that the ACK
package had!

Why does .logout() not send a FIN? Why does it not read the complete
Buffer, so that the Socket could close with FIN? And, why does it wait
until getting out of scope with sending this RST? (I assume, that is
when the Object is garbage-collected)

Thank you!

----------
components: Library (Lib)
messages: 84175
nosy: toelke
severity: normal
status: open
title: Strange behavior when I logout() with IMAP4_SSL
versions: Python 2.5

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

From report at bugs.python.org  Thu Mar 26 12:28:02 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 26 Mar 2009 11:28:02 +0000
Subject: [New-bugs-announce] [issue5566] Minor error in document of
	PyLong_AsSsize_t
In-Reply-To: <1238066882.54.0.64237594344.issue5566@psf.upfronthosting.co.za>
Message-ID: <1238066882.54.0.64237594344.issue5566@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

In 2.6 and 2.7 development document, PyLong_AsSsize_t is said "New in
version 2.5". It is not correct because I checked Python 2.5.4 and
there's only _PyLong_AsSsize_t(). You can check it here:
http://docs.python.org/dev/c-api/long.html#PyLong_AsSsize_t

In 3.0 and 3.1 development document, PyLong_AsSsize_t is appeared twice,
there must be one duplicated. Check it here:
http://docs.python.org/dev/py3k/c-api/long.html#PyLong_AsSsize_t

Thanks!

----------
assignee: georg.brandl
components: Documentation
messages: 84178
nosy: bhy, georg.brandl
severity: normal
status: open
title: Minor error in document of PyLong_AsSsize_t
versions: Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Mar 26 16:48:18 2009
From: report at bugs.python.org (Marek Kubica)
Date: Thu, 26 Mar 2009 15:48:18 +0000
Subject: [New-bugs-announce] [issue5567] Operators in operator module don't
	work with keyword	arguments
In-Reply-To: <1238082498.01.0.463671336038.issue5567@psf.upfronthosting.co.za>
Message-ID: <1238082498.01.0.463671336038.issue5567@psf.upfronthosting.co.za>


New submission from Marek Kubica <marek at xivilization.net>:

When calling operators from the ``operator``-module, they refuse to
accept keyword arguments:

operator.add(a=1, b=2)
TypeError: add() takes no keyword arguments

Operators with keyword arguments are important when one wants to create
partial functions with non-positional arguments.

Take for example ``operator.mod`` where the order of the arguments matters:

This works:
map(lambda x: x % 2, range(5))

This does not work, since ``operator.mod`` does not support keyword
arguments:
map(functools.partial(operator.mod, b=2), range(5))

So there are two solutions: define one's own add(), mod(), contains()
etc. but then the ``operator`` module is rather useless or make them
accept keyword arguments. With ``partial`` in the Stdlib this solution
would be a whole lot nicer.

----------
components: Library (Lib)
messages: 84181
nosy: leonidas
severity: normal
status: open
title: Operators in operator module don't work with keyword arguments
type: feature request

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

From report at bugs.python.org  Thu Mar 26 18:35:12 2009
From: report at bugs.python.org (Jim Olson)
Date: Thu, 26 Mar 2009 17:35:12 +0000
Subject: [New-bugs-announce] [issue5568] self.writer.closed() extraneous
	parens in BufferedRWPair	of io module
In-Reply-To: <1238088912.5.0.880041716832.issue5568@psf.upfronthosting.co.za>
Message-ID: <1238088912.5.0.880041716832.issue5568@psf.upfronthosting.co.za>


New submission from Jim Olson <jimo555 at gmail.com>:

import io


# Corrected a typo in Python261/Lib/io.py at line 1167
# return self.writer.closed() ==> return self.writer.closed
# in
#    @property
#    def closed(self):
#        return self.writer.closed

#also: shouldn't ascii strings still work in Python 2.6.1 for
#StringIO and TextIO? As shown below, writes only work with unicode strings.
#Python 3 changes default encoding to utf-8 but 2.6.1 is still ascii:
#>>> import sys
#>>> sys.getdefaultencoding()
#'ascii'

# Sorry if I am wrong about this.  

ba = buffer('circle')
s = io.StringIO(ba)
print s.getvalue()
#ascii string doesn't work in Python 2.6.1 -- print s.write('square')
print s.write(u'square')
print s.read()
print s.getvalue(), '\n\n'

f = io.FileIO('ioex.txt', 'a+')
r = io.BufferedReader(f)
w = io.BufferedWriter(f)
p = io.BufferedRWPair(r, w)
t = io.TextIOWrapper(p, line_buffering=True)
print t.read(3)
print t.read()
print f.write('julius ceaser\n')
lines = ['william', 'shakespeare', '\n']
f.writelines(' '.join(lines))
#ascii string doesn't work in Python 2.6.1 -- print t.write('marc
anthony\n')
print t.write(u'marc anthony\n')

----------
files: ioex.py
messages: 84190
nosy: jimo555
severity: normal
status: open
title: self.writer.closed() extraneous parens in BufferedRWPair of io module
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file13420/ioex.py

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

From report at bugs.python.org  Thu Mar 26 19:47:06 2009
From: report at bugs.python.org (Yogendra Mohan)
Date: Thu, 26 Mar 2009 18:47:06 +0000
Subject: [New-bugs-announce] [issue5569] Issue in transparency in top level
	tk window(python) on	MAC
In-Reply-To: <1238093226.99.0.851453746263.issue5569@psf.upfronthosting.co.za>
Message-ID: <1238093226.99.0.851453746263.issue5569@psf.upfronthosting.co.za>


New submission from Yogendra Mohan <yogendra_mohan at oxyent-medical.com>:

Hello All,

   OS - MAC 10.5.1
   Python 2.5.1
   Tk - 8.5.6

I am using the wm_attributes for transparency of top level window. But 
unable to do the same.  
The Tk wm attributes command takes option arguments
        self.top=Toplevel(master=self.parent)
        self.top.wm_attributes(alpha=0.0)
Let me know can I do on MAC system or Not? If not then please let me 
know what all changes are required into tkinter.

Thanks in advance.
Yogendra Mohan

----------
components: Tkinter
messages: 84196
nosy: YMohan
severity: normal
status: open
title: Issue in transparency in top level tk window(python) on MAC
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Thu Mar 26 20:08:51 2009
From: report at bugs.python.org (Allister MacLeod)
Date: Thu, 26 Mar 2009 19:08:51 +0000
Subject: [New-bugs-announce] [issue5570] Bus error when calling .poll() on a
	closed Connection	from multiprocessing.Pipe()
In-Reply-To: <1238094531.54.0.874632618778.issue5570@psf.upfronthosting.co.za>
Message-ID: <1238094531.54.0.874632618778.issue5570@psf.upfronthosting.co.za>


New submission from Allister MacLeod <allister.macleod at gmail.com>:

Python 2.6.1 (r261:67515, Mar 26 2009, 14:44:39) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pipe
>>> a, b = Pipe()
>>> a.close()
>>> a.poll()
Bus error

amacleod at cthulhu:~$ uname -a
Linux cthulhu 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009
x86_64 GNU/Linux


I'm running Ubuntu 8.04 LTS, and just installed Python 2.6.1, compiling
from source.

----------
components: Library (Lib)
messages: 84197
nosy: amacleod
severity: normal
status: open
title: Bus error when calling .poll() on a closed Connection from multiprocessing.Pipe()
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 26 20:10:16 2009
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Thu, 26 Mar 2009 19:10:16 +0000
Subject: [New-bugs-announce] [issue5571] new "TestCase.skip" method causes
	all tests to skip under	trial (Twisted's test runner)
In-Reply-To: <1238094616.02.0.646494355716.issue5571@psf.upfronthosting.co.za>
Message-ID: <1238094616.02.0.646494355716.issue5571@psf.upfronthosting.co.za>


New submission from Glyph Lefkowitz <glyph at divmod.com>:

c.f. this Twisted ticket: http://twistedmatrix.com/trac/ticket/3703

Twisted's test tool has an extended TestCase which uses the 'skip'
attribute, on both tests and methods, to determine whether to skip them.
 You can see the implementation here:

http://twistedmatrix.com/trac/browser/trunk/twisted/trial/unittest.py?rev=26043#L655

The addition of the new 'skip' method in unittest.py therefore causes
trial, twisted's test tool, to unconditionally skip all tests.

I've set the priority to release blocker because I'd like it to be
determined whether this is really python's fault, or twisted's fault for
subclassing TestCase.

If the new 'skip' method of TestCase is renamed to something else, say
skipTest, this won't be a problem.

While I understand that this is technically a compatible change (the
addition of an attribute) I'd appreciate it if this changed on Python's
side of things, because leaving it up to Twisted means we need to go
through a deprecation cycle on a long-standing, stable public interface
that a lot of test code is using.

----------
assignee: benjamin.peterson
components: Library (Lib)
messages: 84198
nosy: benjamin.peterson, glyph
priority: release blocker
severity: normal
status: open
title: new "TestCase.skip" method causes all tests to skip under trial (Twisted's test runner)
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Mar 26 20:16:53 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 26 Mar 2009 19:16:53 +0000
Subject: [New-bugs-announce] [issue5572] distutils ignores the LIBS
	configure env var
In-Reply-To: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>
Message-ID: <1238095013.07.0.627782689433.issue5572@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

If you pass LIBS to ./configure (as in "LIBS=-lgcov ./configure"),
distutils ignores this when building extension modules, which breaks
when using certain gcc options which require certain libraries (I'm
thinking of -fprofile-generate). The attached patch remedies this.

----------
assignee: tarek
components: Distutils
files: distutils_libs.patch
keywords: needs review, patch, patch
messages: 84199
nosy: collinwinter, jyasskin, tarek
severity: normal
stage: patch review
status: open
title: distutils ignores the LIBS configure env var
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13422/distutils_libs.patch

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

From report at bugs.python.org  Thu Mar 26 20:38:32 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Thu, 26 Mar 2009 19:38:32 +0000
Subject: [New-bugs-announce] [issue5573] multiprocessing Pipe poll() and
	recv() semantics.
In-Reply-To: <1238096312.97.0.564685442594.issue5573@psf.upfronthosting.co.za>
Message-ID: <1238096312.97.0.564685442594.issue5573@psf.upfronthosting.co.za>


New submission from Vaibhav Mallya <mallyvai at umich.edu>:

Python 2.6.1 (r261:67515, Mar 22 2009, 05:39:39) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pipe
>>> parent, child = Pipe()
>>> parent.send(1)
>>> parent.close()
>>> print child.recv()
1
>>> print child.poll()
True
>>> print child.recv()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
EOFError

We have to use both poll() and recv() to determine whether or not the
connection was actually closed.

Better behavior might be returning True on poll() only if the next
recv() on that end of the pipe will work without an error. There may not
be a way to guarantee this, but it would be useful if the documentation
was clarified either way.


uname -a:
Linux mememy 2.6.24-23-generic #1 SMP Thu Feb 5 15:00:25 UTC 2009 i686
GNU/Linux

Compiled Python 2.6.1 from source.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 84204
nosy: georg.brandl, mallyvai
severity: normal
status: open
title: multiprocessing Pipe poll() and recv() semantics.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 26 21:27:28 2009
From: report at bugs.python.org (Vaibhav Mallya)
Date: Thu, 26 Mar 2009 20:27:28 +0000
Subject: [New-bugs-announce] [issue5574] multiprocessing queues.py doesn't
	include JoinableQueue	in its __all__ list
In-Reply-To: <1238099248.59.0.559630696158.issue5574@psf.upfronthosting.co.za>
Message-ID: <1238099248.59.0.559630696158.issue5574@psf.upfronthosting.co.za>


New submission from Vaibhav Mallya <mallyvai at umich.edu>:

Should __all__ = ['Queue', 'SimpleQueue'] in queues.py have
JoinableQueue as part of the list as well? 

Also, multiprocessing's __init__.py does not appear to have SimpleQueue
as part of its __all__ - is this expected?

SimpleQueue does not appear in the multiprocessing docs; is it meant to
be avoided by user code then?

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 84212
nosy: georg.brandl, jnoller, mallyvai
severity: normal
status: open
title: multiprocessing queues.py doesn't include JoinableQueue in its __all__ list
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Thu Mar 26 22:08:00 2009
From: report at bugs.python.org (Collin Winter)
Date: Thu, 26 Mar 2009 21:08:00 +0000
Subject: [New-bugs-announce] [issue5575] Add env vars for controlling
	building sqlite, hashlib and ssl
In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za>
Message-ID: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

This patch adds SSL_ROOT, SQLITE_INC and SQLITE_LIB environment
variables used to inject additional libraries/headers for building the
sqlite, hashlib and ssl modules. We've found this very useful for
building these modules against their dependencies statically for
deployment purposes. This may well not be useful for most CPython users,
but I figured it would be nice to have a record here.

----------
components: Build
files: setup_env_vars.patch
keywords: needs review, patch, patch
messages: 84220
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Add env vars for controlling building sqlite, hashlib and ssl
versions: Python 2.7
Added file: http://bugs.python.org/file13424/setup_env_vars.patch

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

From report at bugs.python.org  Fri Mar 27 01:23:22 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2009 00:23:22 +0000
Subject: [New-bugs-announce] [issue5576] Don't use PyLong_SHIFT with
	_PyLong_AsScaledDouble()
In-Reply-To: <1238113402.96.0.541162373186.issue5576@psf.upfronthosting.co.za>
Message-ID: <1238113402.96.0.541162373186.issue5576@psf.upfronthosting.co.za>


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

_PyLong_AsScaledDouble() writes the exponent in a int which have to be 
multiplied by PyLong_SHIFT to give the power of 2. I proposed to 
multiply the exponent by PyLong_SHIFT in _PyLong_AsScaledDouble() to 
directly get the power of 2. It avoids complex code to test integer 
overflow in code using _PyLong_AsScaledDouble() (the test is only done 
once, in _PyLong_AsScaledDouble).

I also propose to change exponent type from "int*" to "unsigned int*". 
Previous maximum exponent was INT_MAX//PyLong_SHIFT (eg. 143165576 for 
PyLong using base 2^15). The new maximum is now 
UINT_MAX//PyLong_SHIFT, the double ;-)

And since issue #4258 is commited (Use 30-bit digits instead of 15-bit 
digits for Python integers), PyLong_SHIFT value may be different 
depending on the compiler option. Using my patch, the long implement 
will be a little bit more hidden.

The function _PyLong_AsScaledDouble() should be private because the 
name starts with "_". But I see it in Include/longobject.h. In Python, 
it's used in longobject.c and mathmodule.c.

----------
components: Interpreter Core
files: pylong_asscaleddouble-2.patch
keywords: patch
messages: 84236
nosy: haypo
severity: normal
status: open
title: Don't use PyLong_SHIFT with _PyLong_AsScaledDouble()
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13428/pylong_asscaleddouble-2.patch

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

From report at bugs.python.org  Fri Mar 27 13:25:15 2009
From: report at bugs.python.org (qwjqwj)
Date: Fri, 27 Mar 2009 12:25:15 +0000
Subject: [New-bugs-announce] [issue5577] yield in iterators
In-Reply-To: <1238156715.07.0.356189133984.issue5577@psf.upfronthosting.co.za>
Message-ID: <1238156715.07.0.356189133984.issue5577@psf.upfronthosting.co.za>


New submission from qwjqwj <qwj at papayamobile.com>:

In Python 3.0,3.1a1:

>>> def f():
	[(yield i) for i in range(10)]
>>> f()
>>> f() is None
True

>>> def f():
	((yield i) for i in range(10))
>>> f()
>>> f() is None
True

However it is correct in Python 2.5,2.6

>>> def f():
...     [(yield i) for i in range(10)]
... 
>>> f()
<generator object f at 0x2b84bbe3ae60>

----------
components: Interpreter Core
messages: 84257
nosy: qwjqwj
severity: normal
status: open
title: yield in iterators
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Mar 27 15:40:57 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Fri, 27 Mar 2009 14:40:57 +0000
Subject: [New-bugs-announce] [issue5578] unqualified exec in class body
In-Reply-To: <1238164857.67.0.53034733648.issue5578@psf.upfronthosting.co.za>
Message-ID: <1238164857.67.0.53034733648.issue5578@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

A patch and a test. The problem is a bit broader - what about import * etc?

Patch fixes that, but without a test.

----------
components: Interpreter Core
files: out.diff
keywords: patch
messages: 84259
nosy: fijal
severity: normal
status: open
title: unqualified exec in class body
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file13435/out.diff

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

From report at bugs.python.org  Fri Mar 27 15:54:19 2009
From: report at bugs.python.org (Todd Weiler)
Date: Fri, 27 Mar 2009 14:54:19 +0000
Subject: [New-bugs-announce] [issue5579] Display for OrderedDict
In-Reply-To: <1238165659.22.0.188261777341.issue5579@psf.upfronthosting.co.za>
Message-ID: <1238165659.22.0.188261777341.issue5579@psf.upfronthosting.co.za>


New submission from Todd Weiler <tweiler at raggedcreek.com>:

Now that python has an ordered dictionary it would be great to have a
display sytax for creating them.

To create a dict I just use the dict display syntax:
newdict = {'fred':'flintstone', 'barney':'rubble', 'dino':'thedinosaur'}

I'd like to be able to create an OrderedDict in the same way - I realize
that a list of tuples would do the trick, but I find the dict display
more convenient and readable.  Back in the archives there is probably a
whole discussion of why dict displays are useful.  My reason for liking
displays is that I like to put dictionaries inside dictionaries - the
display format spread out over several lines makes this easy to read.

Possible solutions:

1. maybe use ^{ for OrderedDicts
newdict = ^{'fred':'flintstone', 'barney':'rubble', 'dino':'thedinosaur'}

2. have OrdredDict accept a dictionary display string
newodict = OrderedDict("{'fred':'flintstone', 'barney':'rubble',
'dino':'thedinosaur'}"}

----------
messages: 84261
nosy: tweiler
severity: normal
status: open
title: Display for OrderedDict
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Fri Mar 27 16:35:58 2009
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 27 Mar 2009 15:35:58 +0000
Subject: [New-bugs-announce] [issue5580] Strange error message in
	Python/getargs.c
In-Reply-To: <1238168158.76.0.166850509675.issue5580@psf.upfronthosting.co.za>
Message-ID: <1238168158.76.0.166850509675.issue5580@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

I think the following message is a little bit confusing:
Python 2.7a0 (trunk, Mar 17 2009, 12:06:19)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open('abc\x00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: file() argument 1 must be (encoded string without NULL
bytes), not str

This message could be much more better if unneeded parentheses were
removed. :)
The message on line 861 in Python/getargs.c reads much better:
"string without null bytes"
Would it be appropriate to change the message in topic to something like
this?

----------
messages: 84264
nosy: mishok13
severity: normal
status: open
title: Strange error message in Python/getargs.c
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 27 19:38:31 2009
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 27 Mar 2009 18:38:31 +0000
Subject: [New-bugs-announce] [issue5581] abc.abstractproperty() docs list
	fget as required; fget is not required by abc.abstractproperty()
In-Reply-To: <1238179111.83.0.887852993055.issue5581@psf.upfronthosting.co.za>
Message-ID: <1238179111.83.0.887852993055.issue5581@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

The documentation uses the function signature 
`abc.abstractproperty(fget[, fset[, fdel[, doc]]])`, implying that 
fget is mandatory, and all other arguments are optional. The correct 
version would be `abc.abstractproperty([fget[, fset[, fdel[, 
doc]]]])`, or else to change abc.abstractproperty() to require fget (I 
have not compiled 2.7+ to test if this is the case, I only know that 
the docs in trunk continue to use this signature).

I initially suspected that I misunderstood the signature syntax, but 
other functions use it as I would assume-- for instance, the Built-In 
Functions documentation lists `property([fget[, fset[, fdel[, 
doc]]]])`.

----------
assignee: georg.brandl
components: Documentation
messages: 84277
nosy: Devin Jeanpierre, georg.brandl
severity: normal
status: open
title: abc.abstractproperty() docs list fget as required; fget is not required by abc.abstractproperty()
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 28 00:23:38 2009
From: report at bugs.python.org (acummings)
Date: Fri, 27 Mar 2009 23:23:38 +0000
Subject: [New-bugs-announce] [issue5582] Incorrect DST transition on Windows
In-Reply-To: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>
Message-ID: <1238196218.64.0.426344630758.issue5582@psf.upfronthosting.co.za>


New submission from acummings <acummings at aperiogroup.com>:

On Windows, the calculation of when DST starts is incorrect. Windows OS 
seems to be fully patched, and correctly changed to DST on 3-8-2009. 
However, datetime.now() is 1 hour less then Windows displayed time.

I even tried setting the TZ environment variable to 
PST8PDT,M3.2.0,M11.1.0 to fully specify the date change.

Below you can see that today (3-27-08) is marked as standard time, while 
July 1st is DST and Jan 1st is Standard, if I understand the meaning of 
the 9th element of the timetuple:

ON WINDOWS, with windows reporting the time as 3:59pm:
>>> july1 = datetime(2009, 7, 1)
>>> jan1 = datetime(2009, 1, 1)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 3, 27, 14, 59, 46, 4, 86, 0)

It worked correctly on Linux, though: 
>>> july1 = datetime(2009,7,1)
>>> jan1 = datetime(2009,1,1)
>>> time.localtime(time.mktime(july1.timetuple()))
(2009, 7, 1, 0, 0, 0, 2, 182, 1)
>>> time.localtime(time.mktime(jan1.timetuple()))
(2009, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.localtime(time.mktime(datetime.now().timetuple()))
(2009, 3, 27, 15, 57, 2, 4, 86, 1)

----------
components: Windows
messages: 84286
nosy: acummings
severity: normal
status: open
title: Incorrect DST transition on Windows
versions: Python 2.5

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

From report at bugs.python.org  Sat Mar 28 01:42:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 28 Mar 2009 00:42:42 +0000
Subject: [New-bugs-announce] [issue5583] Optional extensions in setup.py
In-Reply-To: <1238200962.29.0.771243104654.issue5583@psf.upfronthosting.co.za>
Message-ID: <1238200962.29.0.771243104654.issue5583@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Adds a new kwarg to the Extension constructor that does what Python's
own /setup.py does to ignore build failure in an extension with a warning.

I'm not sure if that's everything that's needed, but it seems to work in
a simple test case.

----------
assignee: tarek
components: Distutils
files: opt-ext.diff
keywords: patch
messages: 84293
nosy: georg.brandl, tarek
severity: normal
status: open
title: Optional extensions in setup.py
versions: Python 2.7
Added file: http://bugs.python.org/file13436/opt-ext.diff

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

From report at bugs.python.org  Sat Mar 28 06:53:35 2009
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 28 Mar 2009 05:53:35 +0000
Subject: [New-bugs-announce] [issue5584] json.loads(u'3.14') fails
	unexpectedly (minor scanner bug)
In-Reply-To: <1238219615.73.0.707210951472.issue5584@psf.upfronthosting.co.za>
Message-ID: <1238219615.73.0.707210951472.issue5584@psf.upfronthosting.co.za>


New submission from Bob Ippolito <bob at redivi.com>:

http://code.google.com/p/simplejson/issues/detail?id=43

Need a <= where there's a < in the unicode float scanner. problem only 
exists when decoding a unicode float that is not in any sort of container 
(e.g. array or object).

----------
assignee: bob.ippolito
keywords: easy
messages: 84299
nosy: bob.ippolito
severity: normal
stage: needs patch
status: open
title: json.loads(u'3.14') fails unexpectedly (minor scanner bug)
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Mar 28 12:16:26 2009
From: report at bugs.python.org (lekma)
Date: Sat, 28 Mar 2009 11:16:26 +0000
Subject: [New-bugs-announce] [issue5585] implement initializer
	for	multiprocessing.BaseManager.start()
In-Reply-To: <1238238986.76.0.311716023622.issue5585@psf.upfronthosting.co.za>
Message-ID: <1238238986.76.0.311716023622.issue5585@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

It would be useful to have the ability to run arbitrary code before a
manager's server subprocess is started (I'd use this feature to install
signal handlers for example).

----------
components: Library (Lib)
messages: 84302
nosy: lekma
severity: normal
status: open
title: implement initializer for multiprocessing.BaseManager.start()
type: feature request

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

From report at bugs.python.org  Sat Mar 28 15:16:32 2009
From: report at bugs.python.org (Mher Movsisyan)
Date: Sat, 28 Mar 2009 14:16:32 +0000
Subject: [New-bugs-announce] [issue5586] The documentation of os.makedirs is
	misleading
In-Reply-To: <1238249792.26.0.0616878005738.issue5586@psf.upfronthosting.co.za>
Message-ID: <1238249792.26.0.0616878005738.issue5586@psf.upfronthosting.co.za>


New submission from Mher Movsisyan <mher.movsisyan at gmail.com>:

The documentation of os.makedirs (http://docs.python.org/library/os.html?
highlight=makedirs#os.makedirs) is misleading. It states that os.makedirs raises an 
exception if the leaf directory already exists but it doesn't.

Lib/os.py:

136 def makedirs(name, mode=0777):
137     """makedirs(path [, mode=0777])
138 
139     Super-mkdir; create a leaf directory and all intermediate ones.
140     Works like mkdir, except that any intermediate path segment (not
141     just the rightmost) will be created if it does not exist.  This is
142     recursive.
143 
144     """
145     head, tail = path.split(name)
146     if not tail:
147         head, tail = path.split(head)
148     if head and tail and not path.exists(head):
149         try:
150             makedirs(head, mode)
151         except OSError, e:
152             # be happy if someone already created the path
153             if e.errno != errno.EEXIST:
154                 raise
155         if tail == curdir:           # xxx/newdir/. exists if xxx/newdir exists
156             return
157     mkdir(name, mode)

The attachment is a patch of the documentation (trunk, revision 70643).

----------
assignee: georg.brandl
components: Documentation
files: makedirs.diff
keywords: patch
messages: 84305
nosy: georg.brandl, mher
severity: normal
status: open
title: The documentation of os.makedirs is misleading
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file13439/makedirs.diff

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

From report at bugs.python.org  Sat Mar 28 18:08:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 Mar 2009 17:08:41 +0000
Subject: [New-bugs-announce] [issue5587] vars() no longer has a use __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The vars() builtin now returns a hard to view object.  Formerly, it had
a useful __repr__.


Python 3.1a1 
>>> class A: pass
>>> vars(A)
<dict_proxy object at 0x0131FE70>



IDLE 2.6.1      
>>> class A: pass
>>> vars(A)
{'__module__': '__main__', '__doc__': None}

----------
components: Interpreter Core
messages: 84315
nosy: rhettinger
severity: normal
status: open
title: vars() no longer has a use __repr__
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Mar 28 19:58:11 2009
From: report at bugs.python.org (Collin Winter)
Date: Sat, 28 Mar 2009 18:58:11 +0000
Subject: [New-bugs-announce] [issue5588] Add --randseed to regrtest
In-Reply-To: <1238266691.91.0.7889256249.issue5588@psf.upfronthosting.co.za>
Message-ID: <1238266691.91.0.7889256249.issue5588@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

Add the ability to control the random seed used by regrtest.py -r. This
patch adds a --randseed option, and makes regrtest.py -r indicate what
random seed it's using so that that value can later be fed back to
--randseed. This option is useful for tracking down test order-related
issues found by make buildbottest, for example.

----------
components: Tests
files: randseed.patch
keywords: needs review, patch
messages: 84322
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Add --randseed to regrtest
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file13446/randseed.patch

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

From report at bugs.python.org  Sat Mar 28 19:58:36 2009
From: report at bugs.python.org (Sebastian Billaudelle)
Date: Sat, 28 Mar 2009 18:58:36 +0000
Subject: [New-bugs-announce] [issue5589] Wrong dump of floats
In-Reply-To: <1238266716.08.0.597393543227.issue5589@psf.upfronthosting.co.za>
Message-ID: <1238266716.08.0.597393543227.issue5589@psf.upfronthosting.co.za>


New submission from Sebastian Billaudelle <stein at cream-project.org>:

Hi there,

I just recognized a weird behaviour of the json module...

Dumpig a float like 0.1 I get some crazy output.

Here is an example:

>>> import json
>>> json.dumps([.1])
'[0.10000000000000001]'

Very simple to reproduce;)

- Sebastian

----------
components: Library (Lib)
messages: 84323
nosy: stein
severity: normal
status: open
title: Wrong dump of floats
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 28 22:53:47 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 28 Mar 2009 21:53:47 +0000
Subject: [New-bugs-announce] [issue5590] pyexpat defines global symbol
	template_string
In-Reply-To: <1238277227.85.0.219241873183.issue5590@psf.upfronthosting.co.za>
Message-ID: <1238277227.85.0.219241873183.issue5590@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

pyexpat.c defines the global symbol template_string polluting the global
namespace, which isn't used in the module. Is it ok to remove this
definition altogether?

----------
messages: 84333
nosy: doko
severity: normal
status: open
title: pyexpat defines global symbol template_string

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

From report at bugs.python.org  Sat Mar 28 22:57:05 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 28 Mar 2009 21:57:05 +0000
Subject: [New-bugs-announce] [issue5591] global symbols in shared libpython
	not prefixed with Py	or _Py
In-Reply-To: <1238277425.36.0.0359778681116.issue5591@psf.upfronthosting.co.za>
Message-ID: <1238277425.36.0.0359778681116.issue5591@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

There are four global symbols in libpython, which have are globally
defined, and don't have a Py prefix. Would it be possible to define
those with a _Py prefix instead?

----------
messages: 84334
nosy: doko
severity: normal
status: open
title: global symbols in shared libpython not prefixed with Py or _Py

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

From report at bugs.python.org  Sat Mar 28 22:59:06 2009
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 28 Mar 2009 21:59:06 +0000
Subject: [New-bugs-announce] [issue5592] Modules/_textio.c defines global
	symbol encodefuncs
In-Reply-To: <1238277546.75.0.294864873348.issue5592@psf.upfronthosting.co.za>
Message-ID: <1238277546.75.0.294864873348.issue5592@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

encodefuncs is only used locally. ok to make this variable static?

----------
messages: 84335
nosy: doko
severity: normal
status: open
title: Modules/_textio.c defines global symbol encodefuncs

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

From report at bugs.python.org  Sun Mar 29 03:07:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Mar 2009 01:07:42 +0000
Subject: [New-bugs-announce] [issue5593] test_math.testFsum failure on
	release30-maint
In-Reply-To: <1238288862.5.0.344212782108.issue5593@psf.upfronthosting.co.za>
Message-ID: <1238288862.5.0.344212782108.issue5593@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I started getting this in release30-maint (not in py3k).

======================================================================
FAIL: testFsum (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/30/Lib/test/test_math.py", line 443, in testFsum
    self.assertEqual(actual, expected)
AssertionError: 1.1102230246251565e-16 != 0.0

----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 84354
nosy: marketdickinson, pitrou
priority: normal
severity: normal
status: open
title: test_math.testFsum failure on release30-maint
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Mar 29 09:20:10 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Sun, 29 Mar 2009 07:20:10 +0000
Subject: [New-bugs-announce] [issue5594] IDLE startup configuration
In-Reply-To: <1238311210.52.0.532490988344.issue5594@psf.upfronthosting.co.za>
Message-ID: <1238311210.52.0.532490988344.issue5594@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

My suggestion is to add somewhere in the configuration dialog when users
can enter a block of Python code to be executed at startup and whenever
Restart Shell is executed.

Use case: for people who use IDLE for calculations/experiments they
might like to always have certain module imported. For me personally, it
would be:

   import os
   import re
   import sys
   from math import *

but of course the whole point is that people can write any code they
like. (Some people might want to do various from __future__ imports in
Python 2.6 to get various Python 3 features for example.)

I know that you can use the -c option, but that only works at startup,
not every time you Restart Shell.

----------
components: IDLE
messages: 84367
nosy: mark
severity: normal
status: open
title: IDLE startup configuration
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Mar 29 14:39:53 2009
From: report at bugs.python.org (Michael Newman)
Date: Sun, 29 Mar 2009 12:39:53 +0000
Subject: [New-bugs-announce] [issue5595] os.path.ismount (ntpath) gives
	UnboundLocalError for any	input
In-Reply-To: <1238330393.67.0.063983564768.issue5595@psf.upfronthosting.co.za>
Message-ID: <1238330393.67.0.063983564768.issue5595@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

os.path.ismount gives UnboundLocalError for any input in Python 3.0:

Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path
<module 'ntpath' from 'C:\python30\lib\ntpath.py'>
UnboundLocalError: local variable 'p' referenced before assignment
>>> os.path.ismount("C:\\")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\ntpath.py", line 260, in ismount
    seps = _get_bothseps(p)
UnboundLocalError: local variable 'p' referenced before assignment
>>> os.path.ismount("C:\\windows")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\ntpath.py", line 260, in ismount
    seps = _get_bothseps(p)
UnboundLocalError: local variable 'p' referenced before assignment

It works fine in Python 2.6:
Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path
<module 'ntpath' from 'C:\python26\lib\ntpath.pyc'>
>>> os.path.ismount("C:\\")
True
>>> os.path.ismount("C:\\windows")
False

----------
components: Library (Lib)
messages: 84382
nosy: mnewman
severity: normal
status: open
title: os.path.ismount (ntpath) gives UnboundLocalError for any input
versions: Python 3.0

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

From report at bugs.python.org  Sun Mar 29 16:19:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Mar 2009 14:19:48 +0000
Subject: [New-bugs-announce] [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

A couple of tests exhibit some memory leaks in the py3k branch (when
invoked with "-R 3:2").

test_asyncore leaked [-78, 0] references, sum=-78
test_fileio leaked [1, 1] references, sum=2
test_httpservers leaked [-210, 157] references, sum=-53
test_socket leaked [8, 210] references, sum=218
test_urllib2 leaked [227, 227] references, sum=454
test_urllib2_localnet leaked [5, 4] references, sum=9

I'm filing this as critical so that we keep track of it, but it doesn't
look severe in itself (ISTR we actually had more leaks in 3.0).

----------
components: Extension Modules, Interpreter Core
messages: 84403
nosy: pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: memory leaks in 3.1
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sun Mar 29 19:41:13 2009
From: report at bugs.python.org (Petr Dolezal)
Date: Sun, 29 Mar 2009 17:41:13 +0000
Subject: [New-bugs-announce] [issue5597] inspect.formatargspec crashes on
	missing kwonlydefaults
In-Reply-To: <1238348473.08.0.854037190303.issue5597@psf.upfronthosting.co.za>
Message-ID: <1238348473.08.0.854037190303.issue5597@psf.upfronthosting.co.za>


New submission from Petr Dolezal <petr.dolezal at matfyz.cz>:

inspect.formatargspec is not able to handle functions with keyword only
arguments without the default values (probably rare, but still allowed).
This has also impact on help command which is then unable to show proper
help page for such functions. 

Offending function examples:
def fun1(arg, defarg=None, *args, kwonly):
    """Some documentation."""
    return arg, defarg, args, kwonly

def fun2(arg, defarg=None, *, kwonly):
    """Some documentation."""
    return arg, defarg, kwonly


The fix is easy:
897c897
<             if kwonlyarg in kwonlydefaults:
---
>             if kwonlydefaults and kwonlyarg in kwonlydefaults:


For the test following code snippet taken from help module (or help) can
be used:

import inspect

def trybug(fun):
    args, varargs, varkw, defaults, kwonlyargs, kwdefaults, ann = \
        inspect.getfullargspec(fun)
    argspec = inspect.formatargspec(
        args, varargs, varkw, defaults, kwonlyargs, kwdefaults, ann,
        formatannotation=inspect.formatannotationrelativeto(object))

----------
components: Library (Lib)
messages: 84417
nosy: petr.dolezal
severity: normal
status: open
title: inspect.formatargspec crashes on missing kwonlydefaults
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Mar 29 23:54:29 2009
From: report at bugs.python.org (harobed)
Date: Sun, 29 Mar 2009 21:54:29 +0000
Subject: [New-bugs-announce] [issue5598] "paths" argument missing in
	DocFileSuite documentation
In-Reply-To: <1238363669.79.0.212822428061.issue5598@psf.upfronthosting.co.za>
Message-ID: <1238363669.79.0.212822428061.issue5598@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

This is DocFileSuite function source code
(http://svn.python.org/view/python/trunk/Lib/doctest.py) :

::

    def DocFileSuite(*paths, **kw):
        """A unittest suite for one or more doctest files.

        The path to each doctest file is given as a string; the
        interpretation of that string depends on the keyword argument
        "module_relative".

        A number of options may be provided as keyword arguments:

This is DocFileSuite documentation
(http://svn.python.org/view/python/trunk/Doc/library/doctest.rst) :

::

    .. function:: DocFileSuite([module_relative][, package][, setUp][,
tearDown][, globs][, optionflags][, parser][, encoding])

       Convert doctest tests from one or more text files to a
       :class:`unittest.TestSuite`.

       The returned :class:`unittest.TestSuite` is to be run by the
unittest framework
       and runs the interactive examples in each file.  If an example in
any file
       fails, then the synthesized unit test fails, and a
:exc:`failureException`
       exception is raised showing the name of the file containing the
test and a
       (sometimes approximate) line number.

       Pass one or more paths (as strings) to text files to be examined.


I think "paths" argument missing in this documentation.

Regards,
Stephane

----------
assignee: georg.brandl
components: Documentation
messages: 84434
nosy: georg.brandl, harobed
severity: normal
status: open
title: "paths" argument missing in DocFileSuite documentation
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 30 04:03:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2009 02:03:07 +0000
Subject: [New-bugs-announce] [issue5599] test_email_codecs is skipped
	because it fails to import	TestSkipped from test_support
In-Reply-To: <1238378587.61.0.473582086133.issue5599@psf.upfronthosting.co.za>
Message-ID: <1238378587.61.0.473582086133.issue5599@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Recently (maybe within the last couple days) on the 2.7 trunk
test_email_codecs has started to get skipped:

rdmurray at partner:~/python/trunk>./python -m test.regrtest test_email_codecs
test_email_codecs
test_email_codecs skipped -- cannot import name TestSkipped
1 test skipped:
    test_email_codecs
1 skip unexpected on linux2:
    test_email_codecs

----------
components: Library (Lib)
keywords: easy
messages: 84456
nosy: benjamin.peterson, bitdancer
priority: normal
severity: normal
stage: needs patch
status: open
title: test_email_codecs is skipped because it fails to import TestSkipped from test_support
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 30 04:29:29 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 30 Mar 2009 02:29:29 +0000
Subject: [New-bugs-announce] [issue5600] Slight inaccuracy in webbrowser
	documentation
In-Reply-To: <1238380169.52.0.082922809662.issue5600@psf.upfronthosting.co.za>
Message-ID: <1238380169.52.0.082922809662.issue5600@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The sentence introducing "Browser Controller Objects" in the documentation 
of the webbrowser module says that the methods parallel two of the 
module's convenience functions; it's really three.

----------
assignee: georg.brandl
components: Documentation
messages: 84460
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Slight inaccuracy in webbrowser documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 30 05:46:17 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 30 Mar 2009 03:46:17 +0000
Subject: [New-bugs-announce] [issue5601] webbrowser doesn't just open
	browsers
In-Reply-To: <1238384777.3.0.774822780209.issue5601@psf.upfronthosting.co.za>
Message-ID: <1238384777.3.0.774822780209.issue5601@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

There is a problem with the documentation of the webbrowser module: 
opening a URL doesn't necessarily open it in a browser. The 
documentation of the open function and method should say that the URL is 
opened in whatever application the system chooses based on 
considerations such as the type of URL, an application assigned to the 
file, and the application assigned to the file's type (extension).

Here's why:

The documentation of module webbrowser, as well as the name of the 
module itself, only mentions browsers as what opens the given URL. 
However, on some platforms (Mac OS X, e.g.) if things are configured so 
there is a default application associated with a particular file 
extension, the webbrowser functions will open a path to a file in the 
application associated with it's file type rather than a browser. This 
is true whether or not "file://" precedes the file path in the "URL". 
For example, if .py files are set to open in IDLE, 
webbrowser.open('/fullpath/to/file.py') will open /fullpath/to/file.py 
in IDLE. It's even possible to assign one browser to open .htm files and 
another to open .html files.

It is also possible on some platforms (Mac, again) to assign a default 
application to files of a particular extension but assign a different 
application to specific files with that extension.

Applications can also be assigned to URL types. For instance, you could 
have an application that isn't really a browser open ftp:// URLs. (This 
also can happen when you download a file from a browser and the task is 
turned over to a download application such as Speed Download or 
Interarchy on a Mac.)

The real problem here is that some platforms have extended the idea of 
opening a URL (including a bare file path interpreted as a file:// URL) 
beyond browsers per se. In a sense the entire terminology of this module 
is suspect, despite its obvious intent. Although not a serious 
suggestion, it would more accurately be termed the urlopen module.

----------
assignee: georg.brandl
components: Documentation
messages: 84485
nosy: MLModel, georg.brandl
severity: normal
status: open
title: webbrowser doesn't just open browsers
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 30 06:17:08 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 30 Mar 2009 04:17:08 +0000
Subject: [New-bugs-announce] [issue5602] Slight punctuation problem in
	documentation of	urllib.request.urlopen
In-Reply-To: <1238386628.28.0.265769634027.issue5602@psf.upfronthosting.co.za>
Message-ID: <1238386628.28.0.265769634027.issue5602@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the documentation of the urllib.request module, the function 
urllib.request.urlretrieve is shown with parameters:
        (url[, data][, timeout])
Shouldn't the right bracket after 'data' be after 'timeout'?

----------
assignee: georg.brandl
components: Documentation
messages: 84489
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Slight punctuation problem in documentation of urllib.request.urlopen
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 30 06:22:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 30 Mar 2009 04:22:20 +0000
Subject: [New-bugs-announce] [issue5603] Garbled sentence in documentation
	of	urllib.request.urlopen
In-Reply-To: <1238386940.02.0.317505088908.issue5603@psf.upfronthosting.co.za>
Message-ID: <1238386940.02.0.317505088908.issue5603@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The middle sentence of the last paragraph of the documentation of 
urllib.request.urlopen is garbled, reading:
    "The urlopen function from the previous version, Python 2.6 and 
earlier, of the module urllib has been discontinued as urlopen can return 
the file-object as the previous."

Perhaps the easiest way to say what is intended is "urllib.request.urlopen 
replaces the function urllib.urlopen from versions of Python before 3.0".

----------
assignee: georg.brandl
components: Documentation
messages: 84490
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Garbled sentence in documentation of urllib.request.urlopen
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 30 16:26:41 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2009 14:26:41 +0000
Subject: [New-bugs-announce] [issue5604] imp.find_module() mixes UTF8 and
	MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

There's a path in imp.find_module that mixes encodings.  The module name
is encoded to char* using UTF-8 by the 's' format passed to
PyArg_ParseTuple().  But the path name is converted (in the loop over
the path in find_module()) to char* using the filesystem encoding.  On
Windows this ends up constructing a char* that mixes MBCS and UTF8 in
one string.

(We discovered this when researching bug 4352, but this is not the cause
of the problem reported there -- the module name in that bug is ASCII.)

Andrew Svetlov is looking into producing a patch.

----------
components: Interpreter Core
messages: 84548
nosy: asvetlov, gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: imp.find_module() mixes UTF8 and MBCS
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Mar 30 17:10:04 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Mon, 30 Mar 2009 15:10:04 +0000
Subject: [New-bugs-announce] [issue5605] Don't assume that repr of literal
	dicts are sorted like	pprint sorts them.
In-Reply-To: <1238425804.02.0.358939732522.issue5605@psf.upfronthosting.co.za>
Message-ID: <1238425804.02.0.358939732522.issue5605@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

test_same_as_repr in test_pprint.py assumes repr of literal dict {5:6,
7:8} will be ordered.  This definitely is not the case for Jython, and
the comments above the test appear to indicate that it is not a
guarantee of CPython either.

----------
components: Tests
files: test_pprint_patch.txt
messages: 84561
nosy: fwierzbicki
severity: normal
status: open
title: Don't assume that repr of literal dicts are sorted like pprint sorts them.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13471/test_pprint_patch.txt

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

From report at bugs.python.org  Mon Mar 30 18:12:16 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 30 Mar 2009 16:12:16 +0000
Subject: [New-bugs-announce] [issue5606] The makefile dependencies listing
	formatter.h are wrong
In-Reply-To: <1238429536.66.0.981803111622.issue5606@psf.upfronthosting.co.za>
Message-ID: <1238429536.66.0.981803111622.issue5606@psf.upfronthosting.co.za>


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

The makefile lists Objects/stringlib/formatter.h as a dependency for
Objects/unicodeobject.o, which doesn't include formatter.h.  

Python/formatter_unicode includes it, but doesn't list it as a dependency.

I've attached a patch for Makefile.pre.in for the trunk.  I'm not sure
which other versions might be affected.  At some point in the past
perhaps it was a dependency for unicodeobject.o.

----------
components: Interpreter Core
files: formatter.patch
keywords: patch
messages: 84574
nosy: stutzbach
severity: normal
status: open
title: The makefile dependencies listing formatter.h are wrong
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file13472/formatter.patch

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

From report at bugs.python.org  Mon Mar 30 18:39:14 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 30 Mar 2009 16:39:14 +0000
Subject: [New-bugs-announce] [issue5607] Lib/distutils/test/test_util:
	test_get_platform bogus for	OSX
In-Reply-To: <1238431154.34.0.307596210829.issue5607@psf.upfronthosting.co.za>
Message-ID: <1238431154.34.0.307596210829.issue5607@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

the testcase test_get_platform is not entirely correct for the OSX case.

Background: OSX supports fat binary builds (Apple calls those Universal 
Binaries). The testitem for OSX gives a false negative when you run the 
test with a Universal Binary build of Python on OSX.

To get correct test results on OSX you'll have to patch a number of other 
variables as well, such as CFLAGS, because get_platform uses those to 
detect if you're running on a universal build.

----------
assignee: tarek
messages: 84578
nosy: ronaldoussoren, tarek
severity: normal
status: open
title: Lib/distutils/test/test_util: test_get_platform bogus for OSX

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

From report at bugs.python.org  Mon Mar 30 19:28:00 2009
From: report at bugs.python.org (Thomas Willis)
Date: Mon, 30 Mar 2009 17:28:00 +0000
Subject: [New-bugs-announce] [issue5608] Add python.exe to the path in
	windows?
In-Reply-To: <1238434080.38.0.135810189607.issue5608@psf.upfronthosting.co.za>
Message-ID: <1238434080.38.0.135810189607.issue5608@psf.upfronthosting.co.za>


New submission from Thomas Willis <tom.willis at gmail.com>:

All the vast amounts of documentation out there on how to do neat things
with python seem to assume that python is already in the system path. 

It would be nice if the installer went ahead and set this up for the
user. In my experience there are windows users that don't know how to do
that themselves. As a result, when opening a console(something else
becoming more and more foreign to windows users....) and typing "python"
they get an error and possibly give up, and go back to VB.net or Excel. 

This seems like it would be a relatively easy thing to setup for them
and likely increase world domination.

----------
components: Windows
messages: 84589
nosy: twillis
severity: normal
status: open
title: Add python.exe to the path in windows?
type: feature request

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

From report at bugs.python.org  Mon Mar 30 19:29:34 2009
From: report at bugs.python.org (Maksim Kozyarchuk)
Date: Mon, 30 Mar 2009 17:29:34 +0000
Subject: [New-bugs-announce] [issue5609] Create Unit Tests for nturl2path
	module
In-Reply-To: <1238434174.72.0.622903214477.issue5609@psf.upfronthosting.co.za>
Message-ID: <1238434174.72.0.622903214477.issue5609@psf.upfronthosting.co.za>


New submission from Maksim Kozyarchuk <maksim_kozyarchuk at yahoo.com>:

Added Unit Tests for nturl2path module.

http://codereview.appspot.com/32072/show

----------
components: Tests
messages: 84590
nosy: Kozyarchuk
severity: normal
status: open
title: Create Unit Tests for nturl2path module
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar 30 19:59:37 2009
From: report at bugs.python.org (Tony Nelson)
Date: Mon, 30 Mar 2009 17:59:37 +0000
Subject: [New-bugs-announce] [issue5610] email feedparser.py CRLFLF bug: $
	vs \Z
In-Reply-To: <1238435977.23.0.604038870745.issue5610@psf.upfronthosting.co.za>
Message-ID: <1238435977.23.0.604038870745.issue5610@psf.upfronthosting.co.za>


New submission from Tony Nelson <tony_nelson at users.sourceforge.net>:

feedparser.py does not pares mixed newlines properly.  NLCRE_eol, which
is used to search for the various newlines at End Of Line, uses $ to
match the end of string, but $ also matches \n$, due to a wise long-ago
patch by the Effbot.  This causes feedparser to match '\r\n\n' at
'\r\n', and then to remove the last two characters, leaving '\r', thus
eating up a line.  Such mixed line endings can occur if a message with
CRLF line endings is parsed, written out, and then parsed again.

When explicitly searching for various newlines, the \Z end-of-string
marker should be used instead.  There are two improper uses of $ in
feedparser.py.  I don't see any others in the email package.

NLCRE_eol = re.compile('(\r\n|\r|\n)$')

should be:

NLCRE_eol = re.compile('(\r\n|\r|\n)\Z')

and boundary_re also needs the fix.

I can write a test.  Where exactly should it be put?

----------
components: Library (Lib)
files: feedparser_crlflf.patch
keywords: patch
messages: 84595
nosy: barry, tony_nelson
severity: normal
status: open
title: email feedparser.py CRLFLF bug: $ vs \Z
versions: Python 2.6
Added file: http://bugs.python.org/file13476/feedparser_crlflf.patch

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

From report at bugs.python.org  Mon Mar 30 20:10:46 2009
From: report at bugs.python.org (Kirk McDonald)
Date: Mon, 30 Mar 2009 18:10:46 +0000
Subject: [New-bugs-announce] [issue5611] Auto-detect indentation in C source
	in vimrc
In-Reply-To: <1238436646.8.0.898787236764.issue5611@psf.upfronthosting.co.za>
Message-ID: <1238436646.8.0.898787236764.issue5611@psf.upfronthosting.co.za>


New submission from Kirk McDonald <kirklin.mcdonald at gmail.com>:

According to PEP 7, older C source files are indented with tabs, and
newer ones are indented with spaces. The vimrc file in the repository
assumes that existing C source files should be indented with tabs, and it
should indent with spaces when you create a new C source file. This has
an obvious drawback: It will configure vim to use tabs when you edit a
file that in fact uses spaces.

The attached patch will search for the regex '^\t'; if it is found, vim
will be configured to use tabs and an 8-column shiftwidth; and if it is
not found, it will be configured to use spaces and a 4-column shiftwidth.

----------
components: Demos and Tools
files: vimrc.diff
keywords: patch
messages: 84602
nosy: KirkMcDonald
severity: normal
status: open
title: Auto-detect indentation in C source in vimrc
versions: Python 2.7
Added file: http://bugs.python.org/file13477/vimrc.diff

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

From report at bugs.python.org  Mon Mar 30 20:25:16 2009
From: report at bugs.python.org (Chris Withers)
Date: Mon, 30 Mar 2009 18:25:16 +0000
Subject: [New-bugs-announce] [issue5612] whitespace folding in the email
	package could be better ; -)
In-Reply-To: <1238437516.03.0.51001864383.issue5612@psf.upfronthosting.co.za>
Message-ID: <1238437516.03.0.51001864383.issue5612@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

In python 3 this has been done better already, but in python2.7 we still
have this problem:

>>> from email.mime.text import MIMEText
>>> m = MIMEText('foo')
>>> m['Subject'] = 'AA  '*40
>>> str(m)
'From nobody Mon Mar 30 13:22:44 2009\nContent-Type: text/plain;
charset="us-ascii"\nMIME-Version: 1.0\nContent-Transfer-Encoding:
7bit\nSubject: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA\n\tAA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA \n\nfoo'

Note that all the AA's are single spaced, even though they were supposed
to be double spaced.

It should be noted that the fix for [issue1974] actually relies on this
bug for the fix to work properly ;-) More work will be required to fix
that bug when this bug is fixed :-(

----------
assignee: barry
components: Library (Lib)
messages: 84603
nosy: barry, cjw296
severity: normal
status: open
title: whitespace folding in the email package could be better ;-)
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 30 20:40:17 2009
From: report at bugs.python.org (Tim Driscoll)
Date: Mon, 30 Mar 2009 18:40:17 +0000
Subject: [New-bugs-announce] [issue5613] test_posix.py and test_wait4.py
	having missing import on	win32
In-Reply-To: <1238438417.18.0.73151997177.issue5613@psf.upfronthosting.co.za>
Message-ID: <1238438417.18.0.73151997177.issue5613@psf.upfronthosting.co.za>


New submission from Tim Driscoll <tdriscol at gmail.com>:

These are supposed to raise a unittest.SkipTest on win32 but the
unittest import is missing.  The patch just adds the missing import


See patch here:
http://codereview.appspot.com/32074/show

----------
components: Tests
messages: 84607
nosy: brett.cannon, tdriscol
severity: normal
status: open
title: test_posix.py and test_wait4.py having missing import on win32
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar 31 00:02:56 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 30 Mar 2009 22:02:56 +0000
Subject: [New-bugs-announce] [issue5614] Malloc errors in test_io
In-Reply-To: <1238450576.61.0.363286616174.issue5614@psf.upfronthosting.co.za>
Message-ID: <1238450576.61.0.363286616174.issue5614@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The malloc warnings happen on OSX, with a fresh checkout of the python3 
branch. Python was build using --enable-universalsdk=/ --with-universal-
archs=all, on a x86_64 capable laptop running Leopard.

The issue goes away when running from the commandline, the "-E -bb" 
flags that 'make test' use seem to be involved in the issue.


test_io

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.
python.exe(35535,0x7fff701d1720) malloc: *** mmap(size=-
9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(35535,0x7fff701d1720) malloc: *** mmap(size=-
9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(35535,0x7fff701d1720) malloc: *** mmap(size=-
9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
test_ioctl

----------
messages: 84672
nosy: nad, ronaldoussoren
severity: normal
status: open
title: Malloc errors in test_io

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

From report at bugs.python.org  Tue Mar 31 00:03:04 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 30 Mar 2009 22:03:04 +0000
Subject: [New-bugs-announce] [issue5615] linking fails when configured
	--without-threads
In-Reply-To: <1238450584.26.0.327846530944.issue5615@psf.upfronthosting.co.za>
Message-ID: <1238450584.26.0.327846530944.issue5615@psf.upfronthosting.co.za>


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

A few spots are missing #ifdef WITH_THREAD

I've included a patch for the relevant bits.

----------
components: Extension Modules, Interpreter Core
files: without-threads.patch
keywords: patch
messages: 84673
nosy: stutzbach
severity: normal
status: open
title: linking fails when configured --without-threads
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file13492/without-threads.patch

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

From report at bugs.python.org  Tue Mar 31 00:34:58 2009
From: report at bugs.python.org (Lennart Regebro)
Date: Mon, 30 Mar 2009 22:34:58 +0000
Subject: [New-bugs-announce] [issue5616] Distutils 2to3 support doesn't have
	the doctest_only flag.
In-Reply-To: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>
Message-ID: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

The run_2to3 method, and therefore also the Mixin2to3 class doesn't take
a parameter for doctest_only parameter that refactor has. That means you
have to do a lot of code duplication if you want to write distutil
commands that handle doctest files.

The fix is simple, just add the parameter to the relevant methods.

----------
assignee: tarek
components: 2to3 (2.x to 3.0 conversion tool), Distutils
messages: 84689
nosy: lregebro, tarek
severity: normal
status: open
title: Distutils 2to3 support doesn't have the doctest_only flag.
type: feature request
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 31 03:26:10 2009
From: report at bugs.python.org (David Christian)
Date: Tue, 31 Mar 2009 01:26:10 +0000
Subject: [New-bugs-announce] [issue5617] Unicode pringint in post-mortem
	sessions
In-Reply-To: <1238462770.71.0.542276550689.issue5617@psf.upfronthosting.co.za>
Message-ID: <1238462770.71.0.542276550689.issue5617@psf.upfronthosting.co.za>


New submission from David Christian <dbc at rpath.com>:

http://blog.kowalczyk.info/article/Gdb-basics.html

It is difficult to display the frame you're in while debugging a core
dump in python 3.0 (when in a core dump, you can't run functions, and
thus cannot use many of the normal methods of displaying unicode). 

Martin van Loewis discovered this gdb function (linked), "pu", which
prints out unicode strings.  The way it does so is a bit kludgy, but I
think it is at least the start of a solution.  Perhaps it can be
included in .gdbinit?

----------
messages: 84738
nosy: dugan
severity: normal
status: open
title: Unicode pringint in post-mortem sessions
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Mar 31 05:36:01 2009
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 31 Mar 2009 03:36:01 +0000
Subject: [New-bugs-announce] [issue5618] PyMemberDef type T_UBYTE
	incorrectly documtented
In-Reply-To: <1238470561.76.0.295268646264.issue5618@psf.upfronthosting.co.za>
Message-ID: <1238470561.76.0.295268646264.issue5618@psf.upfronthosting.co.za>


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

One of the available options for the type field in the PyMemberDef
structure is incorrectly listed as T_UNBYTE. T_UBYTE is the correct type.

See http://docs.python.org/c-api/structures.html#PyMemberDef

----------
assignee: georg.brandl
components: Documentation
files: structures_2x.patch
keywords: patch
messages: 84747
nosy: briancurtin, georg.brandl
severity: normal
status: open
title: PyMemberDef type T_UBYTE incorrectly documtented
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13504/structures_2x.patch

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

From =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za  Tue Mar 31 06:13:03 2009
From: =?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za (=?utf-8?b?Ik1hcnRpbiB2LiBMw7Z3aXMiIDxyZXBvcnRAYnVncy5weXRob24ub3JnPg==?= at psf.upfronthosting.co.za)
Date: Tue, 31 Mar 2009 04:13:03 +0000
Subject: [New-bugs-announce] [issue5619] Pass MS CRT debug flags into
	subprocesses
In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>
Message-ID: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

To avoid bringing up CRT assert message dialogs, the CRT debug flags 
need to be passed into subprocesses for multiprocessing.

CRT doesn't have getters. Instead, you have to set to 0, get the current 
value, then restore it. This can be done with

modes = []
for m in [msvcrt.CRT_WARN, msvcrt.CRT_ERROR, msvcrt.CRT_ASSERT]:
    oldmode = msvcrt.CrtSetReportMode(m, 0)
    msvcrt.CrtSetReportMode(m, oldmode)
    modes.append((m, oldmode))

The same probably needs to be done for CrtSetReportFile, except
that msvcrt.CrtSetReportFile currently doesn't return the previous
value. (Also, it returns a HFILE - hopefully, the file handle value
will still be valid in the subprocess)

----------
messages: 84750
nosy: asvetlov, jnoller, loewis
severity: normal
status: open
title: Pass MS CRT debug flags into subprocesses

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

From report at bugs.python.org  Tue Mar 31 13:27:25 2009
From: report at bugs.python.org (edmundy)
Date: Tue, 31 Mar 2009 11:27:25 +0000
Subject: [New-bugs-announce] [issue5620] The attribute's action of an object
	is not correct.
In-Reply-To: <1238498845.56.0.843345010323.issue5620@psf.upfronthosting.co.za>
Message-ID: <1238498845.56.0.843345010323.issue5620@psf.upfronthosting.co.za>


New submission from edmundy <yong.sunny at 163.com>:

The following is the test code.

class C1:
	myurl = []	
	def test(self):
		url = [5,6,7]
		self.myurl.extend(url)		
def testv():
	c = C1()
	c.test()
	print(c.myurl)
	
i = 0
while i<10 :
	testv()
	i = i+1

The output is :

[5, 6, 7]
[5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 
7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 
7, 5, 6, 7]
[5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 7, 5, 6, 
7, 5, 6, 7, 5, 6, 7]

The myurl of class C1 is not set to [] when a new object is created.
All objects use the same memory.

----------
components: None
messages: 84765
nosy: Yong yang
severity: normal
status: open
title: The attribute's action of an object is not correct.
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Mar 31 16:45:06 2009
From: report at bugs.python.org (John Posner)
Date: Tue, 31 Mar 2009 14:45:06 +0000
Subject: [New-bugs-announce] [issue5621] Add description of special case to
	"Assignment	statements" section
In-Reply-To: <1238510706.85.0.278195682658.issue5621@psf.upfronthosting.co.za>
Message-ID: <1238510706.85.0.278195682658.issue5621@psf.upfronthosting.co.za>


New submission from John Posner <john_posner_ab71 at post.harvard.edu>:

The subsection "Augmented assignment statements" includes a note on this
special case:

  a.x += 1

But the parent section "Assignment statements" does not include such a
note, even though it's essentially the same situation. I suggest
replacing the bulleted paragraph that begins "If the target is an
attribute reference" with the following:

---------

*   If the target is an attribute reference: The primary expression in
    the reference is evaluated. It should yield an object with
    assignable attributes; if this is not the case, TypeError is raised.
    That object is then asked to assign the assigned object to the given
    attribute; if it cannot perform the assignment, it raises an
    exception (usually but not necessarily AttributeError).

    If the object is a class instance and the attribute
    reference occurs on both sides of the assignment operator; for example::

        a.x = a.x + 1

    ... in the RHS expression, ``a.x`` is evaluated with
    ``getattr()``, which can access either an instance attribute or (if
    no instance attribute exists) a class attribute. The LHS target
    ``a.x`` is assigned with ``setattr()``, which *always* accesses
    an instance attribute, creating it if necessary. Thus, the two
    occurrences of ``a.x`` do not necessarily refer to the same
    variable. If the RHS expression refers to a class attribute, the LHS
    creates a new instance attribute as the target of the assignment.
    (This description does not necessarily
    apply to attributes defined with ``property()``, which are accessed
    with user-defined functions instead of ``getattr()`` and ``setattr()``).

    See section "Augmented assignment statements" for a similar note on
    attribute references.

---------

----------
assignee: georg.brandl
components: Documentation
messages: 84790
nosy: georg.brandl, jjposner
severity: normal
status: open
title: Add description of special case to "Assignment statements" section
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Mar 31 17:00:37 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Mar 2009 15:00:37 +0000
Subject: [New-bugs-announce] [issue5622] wrong error from curses.wrapper if
	curses initialization	fails
In-Reply-To: <1238511637.05.0.307555783931.issue5622@psf.upfronthosting.co.za>
Message-ID: <1238511637.05.0.307555783931.issue5622@psf.upfronthosting.co.za>


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

wrong error from curses.wrapper if curses initialization fails

One way to reproduce is trying under IDLE.app in OS X:

  import curses
  def scr(a):
    a.getch()

  curses.wrapper(scr)

Traceback before patch:
  UnboundLocalError: local variable 'stdscr' referenced before 
assignment

Traceback after patch:
  _curses.error: setupterm: could not find terminal

APPLIES         2.6, 2.7, 3.0, 3.1

----------
components: Library (Lib)
files: patch-nad0018.txt
messages: 84793
nosy: nad
severity: normal
status: open
title: wrong error from curses.wrapper if curses initialization fails
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13512/patch-nad0018.txt

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

From report at bugs.python.org  Tue Mar 31 17:24:43 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 31 Mar 2009 15:24:43 +0000
Subject: [New-bugs-announce] [issue5623] test_fdopen fails with vs2005,
	release build on Windows 2000
In-Reply-To: <1238513083.42.0.065691454167.issue5623@psf.upfronthosting.co.za>
Message-ID: <1238513083.42.0.065691454167.issue5623@psf.upfronthosting.co.za>


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

Python trunk, compiled with VS2005 SP1, release build on Windows 2000:
>>> import os
>>> fd = os.open("t", 0)
>>> os.close(fd)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor

The _PyVerify_fd() returned False for the given fd!
Needless to say that there are many other similar failures. For example,
subprocess does not work.

Digging inside assembly code, I noticed that the __pioinfo structure
compiled inside msvcr80.dll has a sizeof==64 (asssembly code multiplies
by 64 when doing pointer arithmetic); in Debug mode, sizeof==56.
in posixmodule.c, _PyVerify_fd() uses a sizeof of 56...

It appears that Windows 2000 picks the first msvcr80.dll it finds on the
PATH. So I played with copying various versions of it in the target
directory. Here are the results, as reported by Visual Studio in the
"Modules" pane.

fails: C:\WINNT\system32\msvcr80.dll		8.00.50727.1433
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.1433
works: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.762	
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.163	
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.42
works: C:\WINNT\system32\msvcr80d.dll	8.00.50727.762

DLL hell...

The manifest embedded inside python27.dll contains
version="8.0.50727.762", which is the only working version.
So the problem will likely not happen on Windows XP, which enforces
manifests.

Is there a way to enforce the manifest information on Windows 2000 as well?
If not, there may be several solutions:
- disable the _PyVerify_fd() stuff on Windows 2000.
- write clever code to detect the real sizeof(ioinfo) (for example:
_get_osfhandle(1) returns __pioinfo[0][1]->osfhnd, which is a file
opened for writing)

----------
components: Windows
messages: 84798
nosy: amaury.forgeotdarc, loewis, mhammond
priority: critical
severity: normal
status: open
title: test_fdopen fails with vs2005, release build on Windows 2000
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Mar 31 17:34:00 2009
From: report at bugs.python.org (Maksim Kozyarchuk)
Date: Tue, 31 Mar 2009 15:34:00 +0000
Subject: [New-bugs-announce] [issue5624] Py3K branch import _winreg instead
	of winreg
In-Reply-To: <1238513640.75.0.770010391975.issue5624@psf.upfronthosting.co.za>
Message-ID: <1238513640.75.0.770010391975.issue5624@psf.upfronthosting.co.za>


New submission from Maksim Kozyarchuk <maksim_kozyarchuk at yahoo.com>:

Number of modules in py3k branch are importing _winreg instead of winreg.

According to fix_import.py module in libpy2to3 all _winreg imports need
to be converted to winreg.

----------
components: Library (Lib)
messages: 84801
nosy: Kozyarchuk
severity: normal
status: open
title: Py3K branch import _winreg instead of winreg
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar 31 17:48:08 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Mar 2009 15:48:08 +0000
Subject: [New-bugs-announce] [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: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>


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

[NOTE: applies to 2.x urllib2 and similar code in merged 3.x urllib]

test_urllib2 can fail because urllib2.FileHandler assumes incorrectly
that the local host has only a single IP address.  It is not uncommon
to have host IP configurations where a host has more than one network
interface and the same IP host name is associated with each address.

Both the urllib module and test_urllib2 use
    socket.gethostbyname(socket.gethostname())
to find "the" host IP address.  But, as can be seen here, 
consecutive calls may produce different addresses depending on the
network configuration and underlying os implementation:

Python 2.6.1 (r261:67515, Dec 17 2008, 23:27:50) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.gethostbyname(socket.gethostname())
'10.52.12.105'
>>> socket.gethostbyname(socket.gethostname())
'10.52.12.105'
>>> socket.gethostbyname(socket.gethostname())
'10.52.12.205'
>>>

This leads to predictable test failures when the calls in test_urllib2
and urllib2.FileHandler return different addresses:

test_urllib2
test test_urllib2 failed -- Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/te
st_urllib2.py", line 621, in test_file
    r = h.file_open(Request(url))
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2
.py", line 1229, in file_open
    return self.open_local_file(req)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2
.py", line 1266, in open_local_file
    raise URLError('file not on local host')
URLError: <urlopen error file not on local host>

The simplest way to avoid the test failure is to modify
urllib2.FileHandler to use socket.gethostbyname_ex which returns all
of the IPv4 addresses associated with a hostname:
>>> socket.gethostbyname_ex(socket.gethostname())
('myhost.net', [], ['10.52.12.205', '10.52.12.105'])

Attached patches for 2.x urllib2 and 3.x urllib do that.  Note that 
there remain other issues in this area:
- when urllib2 is enhanced to support IPv6, code is needed to return
  all of the host's IPv6 addresses as well (-> adding a note to open
  Issue1675455)
- the merged 3.0 urlib has two nearly identical functions named
  open_local_file, one each from 2.x urllib.URLopener and
  urllib2.FileHandler, and both use similarly flawed
  socket.gethostbyname(socket.gethostname()) tests but the tests for
  local vs remote file URLs is somewhat different in each.
  (The patches here do not attempt to address this other than to add
   a comment.)

----------
components: Library (Lib)
files: patch-nad0017-trunk-26.txt
messages: 84806
nosy: nad
severity: normal
status: open
title: test_urllib2 fails - urlopen error file not on local host
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file13514/patch-nad0017-trunk-26.txt

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

From report at bugs.python.org  Tue Mar 31 18:03:02 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Mar 2009 16:03:02 +0000
Subject: [New-bugs-announce] [issue5626] misleading comment in
	socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>


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

The documentation for socket.gethostname() contains the following 
comment:

"If you want to know the current machine?s IP address, you may want to 
use gethostbyname(gethostname()). This operation assumes that there is a 
valid address-to-host mapping for the host, and the assumption does not 
always hold."

This comment leads to the mistaken assumption that a machine has only 
one IP address, an assumption which results in bugs such as in 
Issue5625.  The comment also does not deal with other address families, 
i.e. IPv6 addresses.  Either the paragraph should be expanded to cover 
multiple addresses and families, requiring the use of other socket 
functions, or the paragraph should simply be removed.

----------
assignee: georg.brandl
components: Documentation
messages: 84816
nosy: georg.brandl, nad
severity: normal
status: open
title: misleading comment in socket.gethostname() documentation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Mar 31 18:47:13 2009
From: report at bugs.python.org (Euler Taveira de Oliveira)
Date: Tue, 31 Mar 2009 16:47:13 +0000
Subject: [New-bugs-announce] [issue5627] PyDict_SetItemString() fails when
	the second argument is	null
In-Reply-To: <1238518033.32.0.364685297824.issue5627@psf.upfronthosting.co.za>
Message-ID: <1238518033.32.0.364685297824.issue5627@psf.upfronthosting.co.za>


New submission from Euler Taveira de Oliveira <euler at timbira.com>:

PyDict_SetItemString() fails when the second argument (key) is null
pointer. It occurs because PyString_FromString(key) call doesn't check
for null pointer and if we're in a disabled assert environment the
assert() is not caught and strlen() fails.

I don't know what is the best fix but we have two possibilities:

(i) check the second argument in PyDict_SetItemString() before calling
PyString_FromString() and returns null if that argument is null;
(ii) replace the assert() in PyString_FromString() to 'if (str == NULL)
return NULL;'.

This bug was reported as a PostgreSQL bug at [1].

[1] http://archives.postgresql.org/pgsql-hackers/2009-03/msg01344.php

----------
components: Interpreter Core
messages: 84833
nosy: eulerto
severity: normal
status: open
title: PyDict_SetItemString() fails when the second argument is null
type: crash

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

From report at bugs.python.org  Tue Mar 31 19:08:44 2009
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 31 Mar 2009 17:08:44 +0000
Subject: [New-bugs-announce] [issue5628] TextIOWrapper fails with
	SystemError when reading	HTTPResponse
In-Reply-To: <1238519324.96.0.24578067817.issue5628@psf.upfronthosting.co.za>
Message-ID: <1238519324.96.0.24578067817.issue5628@psf.upfronthosting.co.za>


New submission from Jeremy Hylton <jeremy at alum.mit.edu>:

import io
import urllib.request

f_bytes = urllib.request.urlopen("http://www.python.org/")
f_string = io.TextIOWrapper(f_bytes, "iso-8859-1")
print(f_string.read())

----------
components: Library (Lib)
messages: 84840
nosy: jhylton
severity: normal
status: open
title: TextIOWrapper fails with SystemError when reading HTTPResponse
versions: Python 3.0

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

From report at bugs.python.org  Tue Mar 31 19:18:48 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2009 17:18:48 +0000
Subject: [New-bugs-announce] [issue5629] PEP 0 date and revision not being
	set
In-Reply-To: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>
Message-ID: <1238519928.09.0.287279544516.issue5629@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The date and revision data for PEP 0 is not being set since it is trying
to use svn substitution when the PEP itself is not in svn.

----------
components: None
messages: 84843
nosy: benjamin.peterson, brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: PEP 0 date and revision not being set
type: behavior

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

From report at bugs.python.org  Tue Mar 31 21:07:49 2009
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 31 Mar 2009 19:07:49 +0000
Subject: [New-bugs-announce] [issue5630] Update CObject API so it is safe
	and regular
In-Reply-To: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>
Message-ID: <1238526469.89.0.691687509266.issue5630@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The CObject API has two flaws.

First, there is no usable type safety mechanism.  You can store a void
*object, and a void *description.  There is no established schema for
the description; it could be an integer cast to a pointer, or it could
point to memory of any configuration, or it could be NULL.  Thus users
of the CObject API generally ignore it--thus working without any type
safety whatsoever.  A programmer could crash the interpreter from pure
Python by mixing and matching CObjects from different modules (e.g. give
"curses" a CObject from "_ctypes").

Second, the destructor callback is defined as taking *either* one *or*
two parameters, depending on whether the "descr" pointer is non-NULL. 
One can debate the finer points of what is and isn't defined behavior in
C, but at its heart this is a sloppy API.

MvL and I discussed this last night and decided to float a revision of
the API.  I wrote the patch, though, so don't blame Martin if you don't
like my specific approach.

The color of this particular bike shed is:
* The PyCObject is now a private data structure; you must use accessors.
 I added accessors for all the members.
* The constructors and the main accessor (PyCObject_AsVoidPtr) now all
*require* a "const char *type" parameter, which must be a non-NULL C
string of non-zero length.  If you call that accessor and the "type" is
invalid *or doesn't match,* it fails.
* The destructor now takes the PyObject *, not the PyCObject *.  You
must use accessors to get your hands on the data inside to free it.

Yes, you can easily skip around the "matching type" restriction by
calling PyCObject_AsVoidPtr(cobj, PyCObject_GetType(cobj)).  The point
of my API changes is to *encourage* correct use.


The attached patch was written py3k/trunk r70718.  It compiles with no
new warnings/errors and doesn't seem to cause any new failures in the
regression test.

Note: this patch is not complete; I fixed all the .c and .h files, but I
have yet to update the documentation.  I figure I don't want to put the
effort in until the dust settles.

----------
components: Interpreter Core
files: cobject.diff
keywords: patch
messages: 84864
nosy: lhastings
severity: normal
status: open
title: Update CObject API so it is safe and regular
versions: Python 3.1
Added file: http://bugs.python.org/file13521/cobject.diff

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

From report at bugs.python.org  Tue Mar 31 22:01:10 2009
From: report at bugs.python.org (Martin Blais)
Date: Tue, 31 Mar 2009 20:01:10 +0000
Subject: [New-bugs-announce] [issue5631] Distutils "upload" command does not
	show up in	--help-commands output.
In-Reply-To: <1238529670.22.0.992833360277.issue5631@psf.upfronthosting.co.za>
Message-ID: <1238529670.22.0.992833360277.issue5631@psf.upfronthosting.co.za>


New submission from Martin Blais <blais at furius.ca>:

The output of running "python setup.py --help-commands" does not include
the "upload" command.

----------
components: Library (Lib)
messages: 84884
nosy: blais
severity: normal
status: open
title: Distutils "upload" command does not show up in --help-commands output.
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Mar 31 23:01:38 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 31 Mar 2009 21:01:38 +0000
Subject: [New-bugs-announce] [issue5632] Bug -
	threading.currentThread().ident returns None in	main thread
In-Reply-To: <1238533298.48.0.429621534133.issue5632@psf.upfronthosting.co.za>
Message-ID: <1238533298.48.0.429621534133.issue5632@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

The main thread has an ident, but the threading module doesn't
recognize that fact.  I shouldn't have to "start" the main thread.

Example:

% python
Python 2.7a0 (trunk:70084, Feb 28 2009, 20:51:51) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> import thread
>>> print threading.currentThread(), threading.currentThread().ident, 
thread.get_ident()
<_MainThread(MainThread, started)> None -1602627808

% python3.1
Python 3.1a0 (py3k:70084M, Feb 28 2009, 20:46:48) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading  
>>> print (threading.current_thread(), 
threading.current_thread().ident)<_MainThread(MainThread, started)> None

----------
components: Library (Lib)
messages: 84901
nosy: skip.montanaro
severity: normal
status: open
title: Bug - threading.currentThread().ident returns None in main thread
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/issue5632>
_______________________________________

From report at bugs.python.org  Tue Mar 31 23:01:39 2009
From: report at bugs.python.org (Tim Driscoll)
Date: Tue, 31 Mar 2009 21:01:39 +0000
Subject: [New-bugs-announce] [issue5633] timeit breaks when the statment is
	a string and the setup	is not
In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za>
Message-ID: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za>


New submission from Tim Driscoll <tdriscol at gmail.com>:

The patch and test is here:
http://codereview.appspot.com/28161/show

There were no tests so i added a few of them.  The one that breaks
without the patch to timeit is:
test_setup_is_called_when_the_statment_is_string_and_the_setup_is_not()
(sorry for the long name)

Even if the patch is no good perhaps the test could be useful.

----------
components: Library (Lib)
messages: 84902
nosy: tdriscol
severity: normal
status: open
title: timeit breaks when the statment is a string and the setup is not
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar 31 23:25:52 2009
From: report at bugs.python.org (vadim suvorov)
Date: Tue, 31 Mar 2009 21:25:52 +0000
Subject: [New-bugs-announce] [issue5634] cPickle error in case of recursion
	limit
In-Reply-To: <1238534752.39.0.574212792554.issue5634@psf.upfronthosting.co.za>
Message-ID: <1238534752.39.0.574212792554.issue5634@psf.upfronthosting.co.za>


New submission from vadim suvorov <zzPythonTracker at stelary.com>:

In case of heavily recursive data structure cPickle produces
intermittent random exceptions (AttributeError, etc.). The expected is
RuntimeError: ('maximum recursion depth exceeded in ...'). In addition,
the behavior differs for classic/new classes.

The reason: the cPickle needs several optional methods (__getstate__,
__getinitargs__) for each object. In their absence an AttributeError is
generated. It is normally suppressed, but suppression itself causes
recursion. The error in exception processing leads to fancy errors.

The proposed solution: temporary (for call of PyErr_ExceptionMatches())
increase recursion limit.

----------
files: !!!
messages: 84915
nosy: bad
severity: normal
status: open
title: cPickle error in case of recursion limit
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13527/!!!

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