From report at bugs.python.org  Tue Feb  1 08:57:33 2011
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 01 Feb 2011 07:57:33 +0000
Subject: [New-bugs-announce] [issue11087] Speeding up the interpreter with a
	few lines of code
In-Reply-To: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>
Message-ID: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos <jneb at users.sourceforge.net>:

I found a very simple way to improve the speed of CPython a few percent on the most common platforms (i.e. x86), at the cost of only a few lines of code in ceval.c
The only problem is that I don't have any experience in patch submission.

Here are the suggested new lines (also see submitted file):

#define NEXTARG() (next_instr +=2, *(unsigned short*)&next_instr[-2])
#define PEEKARG() (*(unsigned short*)&next_instr[1])

of course this code only works on little-endian processors that allow nonaligned shorts; a change to configure might be needed (*shiver*).

Hope you like it.

----------
components: Interpreter Core
files: speedpatch.c
messages: 127686
nosy: jneb
priority: normal
severity: normal
status: open
title: Speeding up the interpreter with a few lines of code
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20638/speedpatch.c

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

From report at bugs.python.org  Tue Feb  1 12:02:52 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 11:02:52 +0000
Subject: [New-bugs-announce] [issue11088] IDLE on OS X with Cocoa Tk 8.5 can
	hang waiting on input	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>


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

As reported by Alex McNerney in Issue11075 msg127687:

"... running Python 2.7.1:88286 (maintenance) [built from source] on ActiveState Tcl/Tk 8.5.9 causes the idle to hang when a simple script like:
"
x = raw_input("x: ")
print x
"
is run. Is this a bug in Tcl/Tk? Looking in the logs I see several instances of "setCanCycle: is deprecated.  Please use setCollectionBehavior instead" Does this have any relevancy?"

I can reproduce the problem using input with Cocoa Tk 8.5 and Python 3.2rc2 or raw_input with Python 2.7.1+.  It does not seem to happen with Carbon Tk 8.4.  This may be related to Issue10940.  Investigating further for impact on 3.2.

----------
assignee: ned.deily
components: IDLE, Macintosh
messages: 127691
nosy: amcnerney13, ned.deily
priority: critical
severity: normal
status: open
title: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw_input
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  1 15:04:42 2011
From: report at bugs.python.org (Vasilis)
Date: Tue, 01 Feb 2011 14:04:42 +0000
Subject: [New-bugs-announce] [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>


New submission from Vasilis <Vasilis.Vlachoudis at cern.ch>:

The ConfigParser class in 2.7 is almost >50 times slower than in the 2.6 which for large files it renders it almost unusable. Actually the speed decrease depends on the amount of the stored data

Results from test program:
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
on 3.5GHz Fedora14 64bit machine
ConfigParser 166.307140827                
RawConfigParser 0.1887819767 

Python 2.6.4 (r264:75706, Jun  4 2010, 18:20:31)
on 3.0GHz Fedora13 64bit machine
ConfigParser 4.24494099617
RawConfigParser 0.172905921936

----------
components: Extension Modules
files: ConfigParserTest.py
messages: 127699
nosy: vlachoudis
priority: normal
severity: normal
status: open
title: ConfigParser 50x slower in 2.7
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file20640/ConfigParserTest.py

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

From report at bugs.python.org  Tue Feb  1 16:23:43 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 01 Feb 2011 15:23:43 +0000
Subject: [New-bugs-announce] [issue11090] Doc errors for unittest in Python
	3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>


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

Looks like some unittest doc changes got incorrectly backported to Python 3.1.

For example the command line features using -m are new in 3.2 and don't work with 3.1:

http://docs.python.org/py3k/library/unittest.html#command-line-interface

----------
assignee: michael.foord
components: Documentation
messages: 127703
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Doc errors for unittest in Python 3.1
versions: Python 3.1

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

From report at bugs.python.org  Tue Feb  1 18:41:09 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCn0YPQv9GA0LDQutC+0LI=?=)
Date: Tue, 01 Feb 2011 17:41:09 +0000
Subject: [New-bugs-announce] [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>


New submission from ?????? ???????? <sergeyzsg at gmail.com>:

import pkg_resources change path of already imported module
this break google appengine because It use "google.__file__" to determine sdk directory.

Ubuntu 10.10
~/lib/google_appengine$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from appcfg import fix_sys_path
>>> fix_sys_path()
>>> import google
>>> google
<module 'google' from '/home/schuprakov/lib/google_appengine/google/__init__.pyc'>
>>> import pkg_resources
>>> google
<module 'google' from '/usr/lib/pymodules/python2.6/google/__init__.pyc'>
>>> 


ls /usr/lib/pymodules/python2.6/google/
__init__.py  __init__.pyc  protobuf

----------
messages: 127704
nosy: ??????.????????
priority: normal
severity: normal
status: open
title: Bug with reimport in pkg_resources
type: resource usage

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

From report at bugs.python.org  Tue Feb  1 18:42:36 2011
From: report at bugs.python.org (Julien Miotte)
Date: Tue, 01 Feb 2011 17:42:36 +0000
Subject: [New-bugs-announce] [issue11092] Setup.cfg isn't packaged when
	running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

Operating System: Ubuntu Maverick
Version of Python: 2.6.6
Version of Distutils2: d355f123ac79

How to reproduce: Create a project bato with a setup.cfg, like this: 
[metadata]
name = bato
version = 1.0

Run:
$ python -m distutils2.run sdist
$ tar tf dist/bato-1.0.tar.gz

What happens: The archive doesn't contain the setup.cfg file.

----------
assignee: tarek
components: Distutils2
messages: 127705
nosy: Julien.Miotte, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Setup.cfg isn't packaged when running sdist
versions: 3rd party

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

From report at bugs.python.org  Tue Feb  1 20:08:04 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 01 Feb 2011 19:08:04 +0000
Subject: [New-bugs-announce] [issue11093] test_future - rename not-unittest
	files to redure	regrtest.NOTTESTS an empty set
In-Reply-To: <1296587284.84.0.269223815277.issue11093@psf.upfronthosting.co.za>
Message-ID: <1296587284.84.0.269223815277.issue11093@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
following up with issue10848, here's another preparatory step:

- renamed test_future[12].py to future_test[12].py, to clearly identify the as not unittest files (and so facilitate the autodiscovery introduction)
- adapted test_future.py for the filename change
- at last, make NOTTESTS and empty set.

I tested that both test_future only and the whole test suite are all ok.

Let me know if you need anything more or done different :) (f.e.: David, do you want the documentation bits in issue11031 added here instead?) 

Cheers,
Sandro

----------
assignee: sandro.tosi
components: Tests
files: test_future.patch
keywords: patch
messages: 127706
nosy: r.david.murray, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: test_future - rename not-unittest files to redure regrtest.NOTTESTS an empty set
versions: Python 3.3
Added file: http://bugs.python.org/file20641/test_future.patch

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

From report at bugs.python.org  Wed Feb  2 00:16:24 2011
From: report at bugs.python.org (Yelena)
Date: Tue, 01 Feb 2011 23:16:24 +0000
Subject: [New-bugs-announce] [issue11094] Runtime error
In-Reply-To: <1296602184.41.0.81665541642.issue11094@psf.upfronthosting.co.za>
Message-ID: <1296602184.41.0.81665541642.issue11094@psf.upfronthosting.co.za>


New submission from Yelena <kowu at ucdavis.edu>:

I've been using python to run some large database recently. 
I used dbfpy module to access some information stored in dbf format.
However, after 20hrs of running it gave me an error of :
Runtime Error!
This application has requested the Runtime to terminate it in an unusual way.Please contact the application's support team for more information.

The error popped out every time I ran them after 20 hrs. My prediction was that
it ran over its memory usage, since it has been accumulating the memory usage
when I was running the program. So I tried deleting/closing I/O immediately
after they were processed. However, such changes did not make any difference
in memory usage accumulation.

Could you please give me some advice in fixing problems like this?

Thank you.

----------
components: Windows
files: test2
messages: 127711
nosy: yelenawu
priority: normal
severity: normal
status: open
title: Runtime error
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20642/test2

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

From report at bugs.python.org  Wed Feb  2 03:28:41 2011
From: report at bugs.python.org (kai zhu)
Date: Wed, 02 Feb 2011 02:28:41 +0000
Subject: [New-bugs-announce] [issue11095] subprocess popen broken for bytes
	and backslash
In-Reply-To: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>
Message-ID: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu at ugcs.caltech.edu>:

noticed when trying to call grep w/ backslashes in regexp, in shell mode.
same behavior on python2.5 & python3.2

in shell mode:
1. bytes is broken
2. 1st character after backslash is always silently truncated (with exception of '\\')

$ python3.2
Python 3.2rc1+ (py3k, Jan 24 2011, 15:00:02) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call(b'echo aa', shell = True) ## bytes broken
Traceback (most recent call last):
  File "<pseudosugar console>", line 1, in <module>
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 460, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 1175, in _execute_child
    restore_signals, start_new_session, preexec_fn)
TypeError: Can't convert 'int' object to str implicitly
>>> subprocess.call('echo \aa', shell = True) ## backslash \
a
0
>>> subprocess.call('echo \\aa', shell = True) ## backslash \\
aa
0
>>> subprocess.call('echo \\\aa', shell = True) ## backslash \\\
a
0
>>> subprocess.call('echo \\\\aa', shell = True) ## backslash \\\\
a
0
>>> subprocess.call('echo \\\\\aa', shell = True) ## backslash \\\\\
\a
0
>>> subprocess.call('echo \\\\\\aa', shell = True) ## backslash \\\\\\
a
0
>>> subprocess.call('echo \\\\\\\\\\\\\\\\\\\\\\\\\aa', shell = True)
\\\a
0

----------
messages: 127714
nosy: kaizhu
priority: normal
severity: normal
status: open
title: subprocess popen broken for bytes and backslash
type: behavior
versions: Python 2.5, Python 3.2

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

From report at bugs.python.org  Wed Feb  2 06:02:45 2011
From: report at bugs.python.org (Alex McNerney)
Date: Wed, 02 Feb 2011 05:02:45 +0000
Subject: [New-bugs-announce] [issue11096] Multiple turtle tracers
In-Reply-To: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>
Message-ID: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>


New submission from Alex McNerney <amcnerney13 at yahoo.com>:

In Python 2.7 and 2.6 (only ones I have tried), there is a bug in the turtle module's tracer() function, when applying it to multiple turtles using the same value.

When two turtles are defined (to draw simultaneously), and both turtles' tracers are set to the same number, one of the turtles does not end up following its tracer value. (It's a little hard to explain...look at/try the sample code)

The following script will recreate this glitch:
"
from turtle import *

t1 = Turtle()
t2 = Turtle()

for t in turtles():
    t.ht()
    t.speed(0)
    t.tracer(10)

t1.color("black")
t2.color("red")

for x in range(500):
    t1.forward(x)
    t2.forward(x)
    t1.left(144.5)
    t2.right(144.5)
"

----------
messages: 127718
nosy: amcnerney13
priority: normal
severity: normal
status: open
title: Multiple turtle tracers
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Feb  2 09:14:32 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 02 Feb 2011 08:14:32 +0000
Subject: [New-bugs-announce] [issue11097] MSI: Remove win32com dependency
	from installer generator
In-Reply-To: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>
Message-ID: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The MSI installer is generated using msilib.py from http://svn.python.org/projects/python/branches/release27-maint/Tools/msi that is dependent from external win32com module. We also have internal 'msilib' module that is unused for some reason.

Is it possible to incrementally transition from Tools/msilib.py to builtin 'msilib'?

See http://codereview.appspot.com/4080047/ for the start of the thread.

----------
components: Installation
messages: 127720
nosy: loewis, techtonik
priority: normal
severity: normal
status: open
title: MSI: Remove win32com dependency from installer generator
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  2 12:18:55 2011
From: report at bugs.python.org (Alexey Luchko)
Date: Wed, 02 Feb 2011 11:18:55 +0000
Subject: [New-bugs-announce] [issue11098] syntax error at end of line in
	interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>


New submission from Alexey Luchko <luch at ank-sia.com>:

Interactive python -u produces syntax error in win2k:
> python -u
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
  File "<stdin>", line 1
    1+1
       ^
SyntaxError: invalid syntax
>>> import sys
  File "<stdin>", line 1
    import sys
              ^
SyntaxError: invalid syntax
>>>

Tried Python 2.5.4, 2.7.1 and 3.1.2 on the same win2k machine.

The problem does not exist under mac os x 10.5 and freebsd 8.1.

----------
components: Windows
messages: 127732
nosy: luch
priority: normal
severity: normal
status: open
title: syntax error at end of line in interactive python -u
versions: Python 2.5, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  2 16:31:29 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 02 Feb 2011 15:31:29 +0000
Subject: [New-bugs-announce] [issue11099] Bytes pickled with 3.1 not
	unpickled with 2.7 correctly
In-Reply-To: <1296660689.12.0.256726786227.issue11099@psf.upfronthosting.co.za>
Message-ID: <1296660689.12.0.256726786227.issue11099@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jharper at yapdc.com>:

When a bytes object is pickled with 3.1 and then unpickled with 2.7, the results are incorrect.  The example below shows that pickling 
b'abcdefg' in 3.1 and then unpickling in 2.7 produces the string
'[97L, 98L, 99L, 100L, 101L, 102L, 103L]'

The unpickling operation should return 'abcdefg'.

C:\decompyle\jtest>c:\Python31\python
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> file = open('test.pkl', 'wb')
>>> import pickle
>>> pickle.dump(b'abcdefg', file, 0)
>>> exit()

C:\decompyle\jtest>c:\python27\python
Python 2.7 Stackless 3.1b3 060516 (release27-maint, Jul 22 2010, 18:58:18) [MSC
v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> file = open('test.pkl', 'rb')
>>> import pickle
>>> pickle.load(file)
'[97L, 98L, 99L, 100L, 101L, 102L, 103L]'
>>>

----------
components: Library (Lib), Unicode
messages: 127735
nosy: jdharper
priority: normal
severity: normal
status: open
title: Bytes pickled with 3.1 not unpickled with 2.7 correctly
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  2 17:41:59 2011
From: report at bugs.python.org (Erik Krauss)
Date: Wed, 02 Feb 2011 16:41:59 +0000
Subject: [New-bugs-announce] [issue11100] test_fdopen: close failed in file
	object destructor
In-Reply-To: <1296664919.37.0.123111264864.issue11100@psf.upfronthosting.co.za>
Message-ID: <1296664919.37.0.123111264864.issue11100@psf.upfronthosting.co.za>


New submission from Erik Krauss <erik.krauss at highmark.com>:

test_fdopen (in test_os) fails on Solaris 9/sparc with Python 2.7.1.

FAIL: test_fdopen (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/p01/app/tenv6/mercator/tmp_pythonbuild/Python-2.7.1/Lib/test/test_os.py", line 550, in helper
    self.check(getattr(os, f))
  File "/p01/app/tenv6/mercator/tmp_pythonbuild/Python-2.7.1/Lib/test/test_os.py", line 562, in check
    % f)
AssertionError: <built-in function fdopen> didn't raise a OSError with a bad file descriptor

----------
components: Tests
files: test_os_failure.txt
messages: 127743
nosy: ekrauss
priority: normal
severity: normal
status: open
title: test_fdopen: close failed in file object destructor
versions: Python 2.7
Added file: http://bugs.python.org/file20649/test_os_failure.txt

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

From report at bugs.python.org  Wed Feb  2 20:10:53 2011
From: report at bugs.python.org (Bob Van Zant)
Date: Wed, 02 Feb 2011 19:10:53 +0000
Subject: [New-bugs-announce] [issue11101] plistlib has no graceful way of
	handing None values
In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za>
Message-ID: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za>


New submission from Bob Van Zant <bob at veznat.com>:

The Apple plist format does not support None or Null values in its output. A Null value in plist is denoted by the absence of the key in the data structure.

The python plist writer generates a TypeError when a None value is encoded. This issue is to track dealing with None values.

A suggestion is to have a flag on the various plist write functions and methods that will allow ignoring None values.

No changes are required to the plist reader.

----------
components: Library (Lib)
files: plistlib.patch
keywords: patch
messages: 127750
nosy: bobveznat
priority: normal
severity: normal
status: open
title: plistlib has no graceful way of handing None values
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file20651/plistlib.patch

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

From report at bugs.python.org  Wed Feb  2 21:05:30 2011
From: report at bugs.python.org (Oren Held)
Date: Wed, 02 Feb 2011 20:05:30 +0000
Subject: [New-bugs-announce] [issue11102] configure doesn't find "major()"
	on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

The effect eventually is that on HP-UX v3 there are no os.major() and os.minor() functions.

I tried to dig deeper to find out what's wrong, and it seems that 'configure' script fails on 'major' check and thus disables the 'major' feature:

'configure' finds well that /usr/include/sys/sysmacros.h has makedev(), major(), minor() definitions (MAJOR_IN_SYSMACROS==1).

The problem is that including sys/sysmacros.h is not enough, it depends (but doesn't #include) sys/types.h for the definition of dev_t (needed by makedev() macro).


See attached config.log for configure's behavior.

----------
components: Build
files: config.log
messages: 127757
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: configure doesn't find "major()" on HP-UX v11.31
versions: Python 2.7
Added file: http://bugs.python.org/file20652/config.log

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

From report at bugs.python.org  Wed Feb  2 22:39:26 2011
From: report at bugs.python.org (Darren)
Date: Wed, 02 Feb 2011 21:39:26 +0000
Subject: [New-bugs-announce] [issue11103] Python 3.2 installer doesn't
	register file extensions on	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>


New submission from Darren <darrenb at sybase.com>:

The python installer should register the proper file type extensions. Files with .py extensions should have an "open" action associated with the python interpreter and there should also be an "Edit with IDLE" action associated with .py files as well.  I was able to configure both of these things manually on Windows XP but can not figure out how setup the "Edit with IDLE" action on Windows 7.

FWIW: I can run this command from a dos box and get the desired effect.
"C:\Python32\pythonw.exe" "C:\Python32\Lib\idlelib\idle.pyw" -n -e "Test.py"
and I expect the command to be registered with the .py file extension would be
"C:\Python32\pythonw.exe" "C:\Python32\Lib\idlelib\idle.pyw" -n -e "%1"


pythondb

The installer should just do this so python files have reasonable actions associated with them as soon as the install is complete.

----------
components: IDLE, Installation
messages: 127767
nosy: darren
priority: normal
severity: normal
status: open
title: Python 3.2 installer doesn't register file extensions on Windows 7
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb  3 01:05:44 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:05:44 +0000
Subject: [New-bugs-announce] [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>


New submission from John Dennis <jdennis at redhat.com>:

The behaviour of sdist has changed dramatically in Python 2.7. Some projects prefer to maintain their own manifest file instead of utilizing automatic manifest generation from a template. The defined behaviour of sdist is to check for the presence of both a template and a manifest, if the template is absent but a manifest exists sdist is supposed to read the existing manifest, it no longer does this. Instead it creates a default file list with the catastrophic result of omitting the bulk of a projects files.  

It appears this bug was introduced in r81255 and is discussed in #8688. Unfortunately #8688 contained a number of different issues and was closed addressing only a subset of the problems. Changeset r83996 was introduced to prevent sdist from overwriting a project maintained manifest by testing for a comment at the head of the manifest file. It's not clear to me this was necessary because the write_manifest() should never have been called if the template was absent but a manifest existed.

Even after the application of changeset r83996 one of the fundamental problems in #8688 remained, the manifest is not read. The solution is to check for both the manifest and template (as was formerly done) and if the template is absent but the manifest exists then the manifest should be read.

I have made modifications to get_file_list() to reintroduce the defined behaviour. With the introduction of r83996 it is now legal syntax to have comments in the manifest however read_manifest() was not enhanced to account for the possible presence of comments. I also modified read_manifest() to handle comments.

These suggested fixes are attached as a patch against the current 2.7 maintenance branch. I've also attached a file with the two modified methods because sometimes it's difficult to comprehend a patch.

----------
assignee: tarek
components: Distutils
messages: 127777
nosy: eric.araujo, jdennis, tarek
priority: normal
severity: normal
status: open
title: distutils sdist ignores MANIFEST
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  3 06:02:40 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2011 05:02:40 +0000
Subject: [New-bugs-announce] [issue11105] Compiling evil ast crashes
	interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>


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

You don't want to know why I was thinking about this...

$ ./python 
Python 3.2rc2+ (py3k:88302, Feb  1 2011, 19:02:10) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")
Segmentation fault

----------
messages: 127783
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: Compiling evil ast crashes interpreter
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb  3 18:31:11 2011
From: report at bugs.python.org (H Xu)
Date: Thu, 03 Feb 2011 17:31:11 +0000
Subject: [New-bugs-announce] [issue11106] python 2.6.6 and python 2.7.1
	cannot be built	successfully because of an segment fault on
	NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>


New submission from H Xu <xuhdev at gmail.com>:

Build python 2.6.6 and python 2.7.1 on a NetBSD-5.1-sparc machine.

1. Run './configure';
2. Run 'make';
3. Run 'make install'.

There will be a problem after run 'make install'.
The last few lines of error messages are like the following:

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

Stop.
make: stopped in /home/xuh/src/Python-2.6.6

Same thing with python 2.7.1.

----------
components: Build
messages: 127802
nosy: H.Xu
priority: normal
severity: normal
status: open
title: python 2.6.6 and python 2.7.1 cannot be built successfully because of an segment fault on NetBSD-5.1-sparc
type: compile error
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb  3 20:25:21 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 19:25:21 +0000
Subject: [New-bugs-announce] [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>


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

Follow-up to ticket 10227. The following facts seem to indicate that it would be worth caching constant instances of the slice type, such as in [:] or [:-1].

with cached slice instance:

$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)' 'l[s]'
1000000 loops, best of 3: 0.464 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None)' 'l[s]'
10000000 loops, best of 3: 0.149 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None,1)' 'l[s]'
10000000 loops, best of 3: 0.135 usec per loop

uncached normal usage:

$ ./python -m timeit -s 'l = list(range(100))' 'l[:]'
1000000 loops, best of 3: 0.499 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[:1]'
10000000 loops, best of 3: 0.171 usec per loop

Timings based on Python 3.2 rc2.

A quick grep against the py3k stdlib finds 2096 lines in 393 files that use constant slices.

----------
components: Interpreter Core
messages: 127804
nosy: scoder
priority: normal
severity: normal
status: open
title: Cache constant "slice" instances
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb  3 22:08:09 2011
From: report at bugs.python.org (Carlos Corbacho)
Date: Thu, 03 Feb 2011 21:08:09 +0000
Subject: [New-bugs-announce] [issue11108] Intermittent AttributeError when
	using time.strptime in	threads
In-Reply-To: <1296767289.19.0.293158150558.issue11108@psf.upfronthosting.co.za>
Message-ID: <1296767289.19.0.293158150558.issue11108@psf.upfronthosting.co.za>


New submission from Carlos Corbacho <cathectic at gmail.com>:

time.strptime() intermittently (and I mean _really_ intermittently) throws an AttributeError.

Steps to reproduce:

Run the attached script (you may have to do this quite a lot of times; in an evening of trying, I could only trigger this bug once...) - this just starts lots of threads so that we have lots of time.strptime()'s running in parallel.

Expected:

It just keeps running every time.

Actual:

On one run, the script bailed out almost immediately -

ccorbacho at valkyrie:~/chroots/trunk/home/ccorbacho/scratch/ccorbacho$ python test_time.py
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "test_time.py", line 13, in run
    time.strptime("30 Nov 00", "%d %b %y")
AttributeError: _strptime_time

---
This is with Python 2.6.6. However, at work we have been seeing this very intermittently with Python 2.5 in threaded code doing time.strptime() as well (though we just get AttributeError: strptime, but I don't have any code I can provide to reproduce on 2.5), hence I'm raising the bug.

----------
components: None
files: test_time.py
messages: 127822
nosy: ccorbacho
priority: normal
severity: normal
status: open
title: Intermittent AttributeError when using time.strptime in threads
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file20664/test_time.py

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

From report at bugs.python.org  Thu Feb  3 23:01:14 2011
From: report at bugs.python.org (Justin)
Date: Thu, 03 Feb 2011 22:01:14 +0000
Subject: [New-bugs-announce] [issue11109] socketserver.ForkingMixIn leaves
	zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>


New submission from Justin <justin.warkentin at gmail.com>:

This is the same issue as was reported here: http://bugs.python.org/issue1954. It is still a problem in Python 3.1. I'm writing a server that will be receiving a massive number of requests and I'd like to eliminate the zombie problem. Once I figured out what was going on, I tried adding a call to collect_children() in the serve_forever() loop. It worked very well. I've included a patch of what I did, however, I obviously can't leave this change in my socketserver.py because we will be deploying this on a lot of servers.

Is there any reason not to collect_children() in the serve_forever() loop? It seems like the place to do it to me. The patch will only collect children if there are any, so it doesn't have to call it every time through the loop.

----------
components: Library (Lib)
files: collect_children.patch
keywords: patch
messages: 127825
nosy: jwark
priority: normal
severity: normal
status: open
title: socketserver.ForkingMixIn leaves zombies
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file20665/collect_children.patch

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

From report at bugs.python.org  Fri Feb  4 02:26:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 01:26:08 +0000
Subject: [New-bugs-announce] [issue11110] Py_DECREF->Py_XDECREF in
	Module/_sqlite/module.c
In-Reply-To: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>
Message-ID: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Pretty straight forward change, but could potentially cause a NULL pointer deref in a rare situation.

diff --git a/Modules/_sqlite/module.c b/Modules/_sqlite/module.c
--- a/Modules/_sqlite/module.c
+++ b/Modules/_sqlite/module.c
@@ -329,7 +329,7 @@
         (pysqlite_statement_setup_types() < 0) ||
         (pysqlite_prepare_protocol_setup_types() < 0)
        ) {
-        Py_DECREF(module);
+        Py_XDECREF(module);
         return NULL;
     }

----------
components: Extension Modules
files: fix_sqlite.diff
keywords: patch
messages: 127853
nosy: brett.cannon, georg.brandl
priority: release blocker
severity: normal
stage: commit review
status: open
title: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
versions: Python 3.2
Added file: http://bugs.python.org/file20670/fix_sqlite.diff

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

From report at bugs.python.org  Fri Feb  4 02:50:05 2011
From: report at bugs.python.org (reynaldo)
Date: Fri, 04 Feb 2011 01:50:05 +0000
Subject: [New-bugs-announce] [issue11111] See "Gmail" on your Google homepage
In-Reply-To: <000e0cd215a2adb38b049b6b1962@google.com>
Message-ID: <000e0cd215a2adb38b049b6b1962@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Gmail" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 127856
nosy: renben
priority: normal
severity: normal
status: open
title: See "Gmail" on your Google homepage
Added file: http://bugs.python.org/file20671/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11111>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=builtin_gmail.xml&source=imag">See "Gmail" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://www.google.com/ig/modules/builtin_content/en_us/gmail.jpg" alt="screenshot">

From report at bugs.python.org  Fri Feb  4 04:06:03 2011
From: report at bugs.python.org (rmtew)
Date: Fri, 04 Feb 2011 03:06:03 +0000
Subject: [New-bugs-announce] [issue11112] UDPTimeoutTest derives from
	SocketTCPTest
In-Reply-To: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>
Message-ID: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>


New submission from rmtew <richard.m.tew at gmail.com>:

File: Lib\test\test_socket.py

Code: 

  class UDPTimeoutTest(SocketTCPTest):

Problem:

This test is intended to test UDP sockets, but derives from SocketTCPTest.  Logic dictates this should derive from SocketUDPTest.

I've searched for UDP (with differing case, as that seems to matter) in several different fields on this site, and found no relevant matches.

----------
components: Tests
messages: 127863
nosy: rmtew
priority: normal
severity: normal
status: open
title: UDPTimeoutTest derives from SocketTCPTest
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb  4 04:43:55 2011
From: report at bugs.python.org (Brian Jones)
Date: Fri, 04 Feb 2011 03:43:55 +0000
Subject: [New-bugs-announce] [issue11113] html.entities mapping dicts need
	updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In Python 3.2b2, html.entities.codepoint2name and name2codepoint only support the 252 HTML entity names defined in the HTML 4 spec from 1997. I'm wondering if there's a reason not to support W3C Recommendation 'XML Entity Definitions for Characters' 

http://www.w3.org/TR/xml-entity-names/

This standard contains significantly more characters, and it is noted in that spec that the HTML 5 drafts use that spec's entities. You can see the current HTML 5 'Named character references' here: 

http://www.w3.org/TR/html5/named-character-references.html#named-character-references

If this is just a matter of somebody going in to do the grunt work, let me know. 

If startup costs associated with importing a huge dictionary are a concern, perhaps a more efficient type that enables the same lookup interface can be defined. 

If other reasons exist to not move in this direction, please do let me know!

----------
components: Library (Lib), Unicode, XML
messages: 127865
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: html.entities mapping dicts need updating?
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  4 09:52:37 2011
From: report at bugs.python.org (Laurens)
Date: Fri, 04 Feb 2011 08:52:37 +0000
Subject: [New-bugs-announce] [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>


New submission from Laurens <3.14159265358 at xs4all.nl>:

file.tell() has become extremely slow in version 3.2, both rc1 and rc2. This problem did not exist in version 2.7.1, nor in version 3.1. It could be reproduced both on mac and windows xp.

----------
components: IO
messages: 127874
nosy: Laurens
priority: normal
severity: normal
status: open
title: file.tell extremely slow
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  4 10:39:23 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 04 Feb 2011 09:39:23 +0000
Subject: [New-bugs-announce] [issue11115] csv readers and writers should be
	context managers
In-Reply-To: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>
Message-ID: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>


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

The context managers should simply forward to the underlying file object.

----------
components: Library (Lib)
messages: 127876
nosy: djc
priority: normal
severity: normal
status: open
title: csv readers and writers should be context managers
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb  4 11:39:48 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 10:39:48 +0000
Subject: [New-bugs-announce] [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Following Issue 9124 discussion: it took longer than i thought, but now i could rework my thing and got errors.  I've also tried Lib/test/test_mailbox.py, and that produces 0xA errors and 0xA failures.  I'll attach the entire tracebacks and test output as email_mbox.txt.
My local Py3K repo is at changeset HG:33774ca03c96 (SVN:r88332)
Here are only the exceptions:

==========

| [Opening mailbox "OLD.sdaoden.mbox" as mbox
| * Box contains 8 messages
|   * Dispatching message 1
ERROR: failed to handle box "OLD.sdaoden.mbox"
  Traceback (most recent call last):
    File "./s-postman.py", line 1078, in _walk
      self._do_mailbox(mailbox)
    File "./s-postman.py", line 1088, in _do_mailbox
      Ticket.process_message(msg)
    File "./s-postman.py", line 987, in process_message
      print(msg)
    File "usr/lib/python3.2/email/message.py", line 152, in __str__
      return self.as_string()
    File "usr/lib/python3.2/email/message.py", line 167, in as_string
      g.flatten(self, unixfrom=unixfrom)
    File "usr/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "usr/lib/python3.2/email/generator.py", line 141, in _write
      self._write_headers(msg)
    File "usr/lib/python3.2/email/generator.py", line 176, in _write_headers
      self.write(header.encode(linesep=self._NL)+self._NL)
    File "usr/lib/python3.2/email/header.py", line 317, in encode
      formatter.feed(lines[0], charset)
  Exception: IndexError: list index out of range
Continue [yY - else no]? n
Exit due to errors as above

===========

PANIC: Box test.mdir: message-add failed, mails may be lost
       FIXME about fetch modus which saves the stuff somewhere
  Traceback (most recent call last):
    File "./s-postman.py", line 739, in add_ticket
      mailbox.add(ticket.message)
    File "usr/lib/python3.2/mailbox.py", line 269, in add
      self._dump_message(message, tmp_file)
    File "usr/lib/python3.2/mailbox.py", line 215, in _dump_message
      gen.flatten(message)
    File "usr/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "usr/lib/python3.2/email/generator.py", line 141, in _write
      self._write_headers(msg)
    File "usr/lib/python3.2/email/generator.py", line 373, in _write_headers
      self.write(header.encode(linesep=self._NL)+self._NL)
    File "usr/lib/python3.2/email/header.py", line 317, in encode
      formatter.feed(lines[0], charset)
  Exception: IndexError: list index out of range

==========

> Changing Ticket.process_message() to:
>    def process_message(msg):
>        print("Message-Type: ", msg.__name__)

ERROR: failed to handle box "src/s-postman/OLD.sdaoden.mbox"
  Traceback (most recent call last):
    File "./s-postman.py", line 1078, in _walk
      self._do_mailbox(mailbox)
    File "./s-postman.py", line 1088, in _do_mailbox
      Ticket.process_message(msg)
    File "./s-postman.py", line 987, in process_message
      print("Message-Type: ", msg.__name__)
  Exception: AttributeError: 'mboxMessage' object has no attribute '__name__'
Continue [yY - else no]? n
Exit due to errors as above

==========

> And this is about Lib/test/test_mailbox.py

21:30 ~/py3k.hg/Lib/test $ python3 test_mailbox.py > ~/tmp/test.txt

Traceback (most recent call last):
  File "test_mailbox.py", line 2091, in <module>
    test_main()
  File "test_mailbox.py", line 2086, in test_main
    support.run_unittest(*tests)
  File "/usr/lib/python3.2/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/usr/lib/python3.2/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Library (Lib)
files: email_mbox.txt
messages: 127880
nosy: sdaoden
priority: normal
severity: normal
status: open
title: mailbox and email errors
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20673/email_mbox.txt

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

From report at bugs.python.org  Fri Feb  4 16:26:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 04 Feb 2011 15:26:41 +0000
Subject: [New-bugs-announce] [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

This issue is a placeholder for exposing Async IO thru Python.

The relevant mail thread is at:

http://mail.python.org/pipermail/python-dev/2010-October/104770.html


Relevant resources:

http://feedproxy.google.com/~r/Wwwc0t0d0s0org/~3/snM0BJ8evv4/7147-Synchronicity-in-asynchronicity.html

http://www.opengroup.org/onlinepubs/000095399/basedefs/aio.h.html

----------
assignee: jcea
components: Extension Modules
messages: 127898
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Implementing Async IO
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb  4 19:50:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 18:50:28 +0000
Subject: [New-bugs-announce] [issue11118] Fix python3 None export
In-Reply-To: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>
Message-ID: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The None export of python3.dll is bogus; attached is a fix. This also regenerates python3stub.def, which contained some exports that had already been deleted from python3.def.

----------
files: none.diff
keywords: patch
messages: 127917
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Fix python3 None export
versions: Python 3.2
Added file: http://bugs.python.org/file20677/none.diff

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

From report at bugs.python.org  Fri Feb  4 20:24:23 2011
From: report at bugs.python.org (pen hill)
Date: Fri, 04 Feb 2011 19:24:23 +0000
Subject: [New-bugs-announce] [issue11119] Passing a socket to a process
	(multiprocessing module)
In-Reply-To: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>
Message-ID: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>


New submission from pen hill <imbenhill at gmail.com>:

When I run the following listing (server_multi.py) by using multiprocessing module of python, it runs successfully on a Linux machine. However, on a 64-bit windows machine I get the following error:

pickle.PicklingError: Can't pickle <built-in method recvfrom_into of _socket.socket object at 0x0000000002D2CF10>: it's not found as __main__.recvfrom_into

This module is from the book Foundations of Python Network Programming, 2nd Edition. I am pasting the code with the permission of the author. It seems that socket "listen_sock" cannot be pickled under 64-bit
Windows, however it can be pickled under Linux. How can we remove this issue on Windows? It is interesting that if I use the threading module, it works for both Windows and Linux. Thanks. 

server_multi.py :
#usage: $ python server_multi.py localhost process
#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - server_multi.py
# Using multiple threads or processes to serve several clients in parallel.

import sys, time, lancelot
from multiprocessing import Process
from server_simple import server_loop
from threading import Thread

WORKER_CLASSES = {'thread': Thread, 'process': Process}
WORKER_MAX = 10

def start_worker(Worker, listen_sock):
    worker = Worker(target=server_loop, args=(listen_sock,))
    worker.daemon = True  # exit when the main process does
    worker.start()
    return worker

if __name__ == '__main__':
    if len(sys.argv) != 3 or sys.argv[2] not in WORKER_CLASSES:
        print >>sys.stderr, 'usage: server_multi.py interface thread|process'
        sys.exit(2)
    Worker = WORKER_CLASSES[sys.argv.pop()]  # setup() wants len(argv)==2

    # Every worker will accept() forever on the same listening socket.

    listen_sock = lancelot.setup()
    workers = []
    for i in range(WORKER_MAX):
        workers.append(start_worker(Worker, listen_sock))

    # Check every two seconds for dead workers, and replace them.

    while True:
        time.sleep(2)
        for worker in workers:
            if not worker.is_alive():
                print worker.name, "died; starting replacement worker"
                workers.remove(worker)
                workers.append(start_worker(Worker, listen_sock))

lancelot.py:

#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - lancelot.py
# Constants and routines for supporting a certain network conversation.

import socket, sys

PORT = 1060
qa = (('What is your name?', 'My name is Sir Lancelot of Camelot.'),
      ('What is your quest?', 'To seek the Holy Grail.'),
      ('What is your favorite color?', 'Blue.'))
qadict = dict(qa)

def recv_until(sock, suffix):
    message = ''
    while not message.endswith(suffix):
        data = sock.recv(4096)
        if not data:
            raise EOFError('socket closed before we saw %r' % suffix)
        message += data
    return message

def setup():
    if len(sys.argv) != 2:
        print >>sys.stderr, 'usage: %s interface' % sys.argv[0]
        exit(2)
    interface = sys.argv[1]
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    sock.bind((interface, PORT))
    sock.listen(128)
    print 'Ready and listening at %r port %d' % (interface, PORT)
    return sock

server_simple.py:

#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - server_simple.py
# Simple server that only serves one client at a time; others have to wait.

import lancelot

def handle_client(client_sock):
    try:
        while True:
            question = lancelot.recv_until(client_sock, '?')
            answer = lancelot.qadict[question]
            client_sock.sendall(answer)
    except EOFError:
        client_sock.close()

def server_loop(listen_sock):
    while True:
        client_sock, sockname = listen_sock.accept()
        handle_client(client_sock)

if __name__ == '__main__':
    listen_sock = lancelot.setup()
    server_loop(listen_sock)

----------
components: None
messages: 127922
nosy: pen hill
priority: normal
severity: normal
status: open
title: Passing a socket to a process (multiprocessing module)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 20:48:16 2011
From: report at bugs.python.org (cardinalbiggles)
Date: Fri, 04 Feb 2011 19:48:16 +0000
Subject: [New-bugs-announce] [issue11120] threading.Thread.daemon
	Documentation Incomplete
In-Reply-To: <1296848896.87.0.703380092713.issue11120@psf.upfronthosting.co.za>
Message-ID: <1296848896.87.0.703380092713.issue11120@psf.upfronthosting.co.za>


New submission from cardinalbiggles <jmandersen at gmail.com>:

In the threading module, the documentation for Thread.isDaemon()/Thread.setDaemon() indicates they are the old API for Thread.daemon, which does not indicate the version in which it was introduced (2.6 I believe). 

Additionally, the documentation for Thread.setDaemon() should at least include the daemonic parameter, if not the full usage documentation for those targeting older versions.

Targeting Python 2.4, and being unable to (as) efficiently navigate the old documentation site, I have come to rely on the various 'Changed/New in version 2.X' messages in the current documentation. This caused some confusion on my part.

----------
assignee: docs at python
components: Documentation
messages: 127927
nosy: cardinalbiggles, docs at python
priority: normal
severity: normal
status: open
title: threading.Thread.daemon Documentation Incomplete
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 21:02:58 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 20:02:58 +0000
Subject: [New-bugs-announce] [issue11121] libpython3.so support with
	--enable-shared
In-Reply-To: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>
Message-ID: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When configuring r88333 with --enable-shared, the error message

./configure: line 4924: test: ==: unary operator expected

is produced. The attached patch fixes the problem.

----------
files: pydebug.diff
keywords: patch
messages: 127931
nosy: loewis
priority: release blocker
severity: normal
status: open
title: libpython3.so support with --enable-shared
Added file: http://bugs.python.org/file20679/pydebug.diff

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

From report at bugs.python.org  Fri Feb  4 22:19:22 2011
From: report at bugs.python.org (James)
Date: Fri, 04 Feb 2011 21:19:22 +0000
Subject: [New-bugs-announce] [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Hi distutils,

When I run:

./setup.py bdist --formats=rpm

on my source directory, I get the error:

rpm -ba --define _topdir /home/james/code/scantran/build/bdist.linux-x86_64/rpm --clean build/bdist.linux-x86_64/rpm/SPECS/scantran.spec
-ba: unknown option
error: command 'rpm' failed with exit status 1

It seems the problem can be fixed by installing the rpm-build package (on fedora 14 anyways) and so perhaps something should be done so that this is more obvious...

HTH,
James

----------
assignee: tarek
components: Distutils
messages: 127942
nosy: eric.araujo, purpleidea, tarek
priority: normal
severity: normal
status: open
title: bdist_rpm fails
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 23:41:23 2011
From: report at bugs.python.org ($$Coffeepot$$)
Date: Fri, 04 Feb 2011 22:41:23 +0000
Subject: [New-bugs-announce] [issue11123] problem with packaged dependency
	extracter script, pdeps
In-Reply-To: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>
Message-ID: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>


New submission from $$Coffeepot$$ <coffeepottttttttt at yahoo.com>:

This bug concerns the pdeps script, <python directory>\Tools\Scripts\pdeps.py. This script opens a list of files and extracts a list of their inter-dependencies.

I'm running Python 3.1.1 on Windows XP, installed via binary installer, but have confirmed that the bug is present in the source distribution of Python 3.2 rc2, the newest code I know of. (In fact, the only difference between the pdeps.py files in each version was the shebang line, 3.2 rc2 shebang line: "#! /usr/bin/env python3", 3.1.1 shebang line: "#! /usr/bin/env python".)

When I tried out the module I found a series of small bugs, basically typos, each of which caused the script to crash due to an unhandled exception.

1.

The relevant section of the unmodified pdeps.py file
----
# Compiled regular expressions to search for import statements
#
m_import = re.compile('^[ \t]*from[ \t]+([^ \t]+)[ \t]+')
m_from = re.compile('^[ \t]*import[ \t]+([^#]+)')


# Collect data from one file
#
def process(filename, table):
...
        if m_import.match(line) >= 0:
            (a, b), (a1, b1) = m_import.regs[:2]
        elif m_from.match(line) >= 0:
            (a, b), (a1, b1) = m_from.regs[:2]
...

The match method of a compiled regular expression returns an SREMatch object, so the conditionals must be changed. In addition, the regs data is a member of the match object itself, not the compiled expression object, so the right side of the assignments must also be changed.

modified version
----
...
        import_match = m_import.match(line)
        from_match = m_from.match(line)
        if import_match:
            (a, b), (a1, b1) = import_match.regs[:2]
        elif from_match:
            (a, b), (a1, b1) = from_match.regs[:2]
...

2.

unmodified
----
# Invert a table (this is again totally general).
# All keys of the original table are made keys of the inverse,
# so there may be empty lists in the inverse.
#
def inverse(table):
    inv = {}
    for key in table.keys():
        if not inv.has_key(key):
            inv[key] = []
        for item in table[key]:
            store(inv, item, key)
    return inv

Dictionaries have no has_key method, though I vaguely recall that they used to. That's a quick fix though.

modified
----
# Invert a table (this is again totally general).
# All keys of the original table are made keys of the inverse,
# so there may be empty lists in the inverse.
#
def inverse(table):
    inv = {}
    for key in table.keys():
        if key in inv:
            inv[key] = []
        for item in table[key]:
            store(inv, item, key)
    return inv

output of fc, windows file comparing utility, run on the pdeps file from 3.2 rc2, and the modified pdeps file from 3.1.1
----
>fc original-pdeps.py pdeps.py
Comparing files original-pdeps.py and PDEPS.PY
***** original-pdeps.py 
#! /usr/bin/env python3

***** PDEPS.PY
#! /usr/bin/env python

*****

***** original-pdeps.py 
            line = line[:-1] + nextline
        if m_import.match(line) >= 0:
            (a, b), (a1, b1) = m_import.regs[:2]
        elif m_from.match(line) >= 0:
            (a, b), (a1, b1) = m_from.regs[:2]
        else: continue
***** PDEPS.PY
            line = line[:-1] + nextline
        import_match = m_import.match(line)
        from_match = m_from.match(line)
        if import_match:
            (a, b), (a1, b1) = import_match.regs[:2]
        elif from_match:
            (a, b), (a1, b1) = from_match.regs[:2]
        else: continue
*****

***** original-pdeps.py 
    for key in table.keys():
        if not inv.has_key(key):
            inv[key] = []
***** PDEPS.PY
    for key in table.keys():
        if key in inv:
            inv[key] = []
*****

With these changes the pdep script works as expected.

This is a pretty lower priority bug imho. It prevents anyone from using the script, but fixing the bug took about 5 minutes, and I doubt the pdeps script gets much use anyway. This bug is unlikely to inconvenience anyone.

----------
components: Demos and Tools
messages: 127947
nosy: $$Coffeepot$$
priority: normal
severity: normal
status: open
title: problem with packaged dependency extracter script, pdeps
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb  5 00:12:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 23:12:21 +0000
Subject: [New-bugs-announce] [issue11124] test_posix failure on the Leopard
	buildbot
In-Reply-To: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>
Message-ID: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>


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

test_posix has started failing deterministically on the Leopard buildbot. Stephen, did you change something in its configuration?

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/786/steps/test/logs/stdio


======================================================================
FAIL: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_posix.py", line 390, in test_getgroups
    set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the first set but not the second:
108

----------
components: Library (Lib), Tests
messages: 127950
nosy: ixokai, ned.deily, pitrou, ronaldoussoren
priority: critical
severity: normal
status: open
title: test_posix failure on the Leopard buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb  5 00:47:21 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 04 Feb 2011 23:47:21 +0000
Subject: [New-bugs-announce] [issue11125] csv documentation should not use
	open() without close()
In-Reply-To: <1296863241.98.0.986933657012.issue11125@psf.upfronthosting.co.za>
Message-ID: <1296863241.98.0.986933657012.issue11125@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Many places open() is shown as a parameter to a csv method, but close() can't be called. This is not a practice we should be advocating. Better would be to show a 'with' statement, or at least a note explaining this isn't an ideal usage.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 127954
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: csv documentation should not use open() without close()
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  5 01:00:48 2011
From: report at bugs.python.org (jtidman)
Date: Sat, 05 Feb 2011 00:00:48 +0000
Subject: [New-bugs-announce] [issue11126] Wave.py does not always write
	proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>


New submission from jtidman <jtidman at siliconcoral.com>:

wave.py does not always honor the sampwidth setting, especially on little endian machines.  If sampwidth is not one and big_endian is not set, then datawritten will not be muliplied by sampwidth, causing the header to be incorrect, and the file to appear to contain less data than it chould.

----------
components: Library (Lib)
files: patch.txt
messages: 127956
nosy: jtidman
priority: normal
severity: normal
status: open
title: Wave.py does not always write proper length in header
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20682/patch.txt

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

From report at bugs.python.org  Sat Feb  5 09:30:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 08:30:26 +0000
Subject: [New-bugs-announce] [issue11127] sockets should not be pickleable
In-Reply-To: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>
Message-ID: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>


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

Like already done for file objects, sockets should refuse pickling by raising a TypeError.

----------
components: Library (Lib)
messages: 127976
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sockets should not be pickleable
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb  5 14:06:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 13:06:49 +0000
Subject: [New-bugs-announce] [issue11128] decimal.py: to_integral() corner
	cases
In-Reply-To: <1296911209.51.0.925327858699.issue11128@psf.upfronthosting.co.za>
Message-ID: <1296911209.51.0.925327858699.issue11128@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

to_integral() should behave like quantize() for negative exponents:

"Otherwise (the operand has a negative exponent) the result is the
 same as using the quantize operation using the given operand as the
 left-hand-operand, 1E+0 as the right-hand-operand, and the precision
 of the operand as the precision setting. The rounding mode is taken
 from the context, as usual."


There are some corner cases where this matters:


>>> from decimal import *
>>> c = Context(prec=1, Emin=-1, Emax=1, traps=[])
>>> d = Context(prec=4, Emin=-1, Emax=1, traps=[])
>>> 
>>> c.to_integral(Decimal("999.9"))
Decimal('1000')
>>> d.quantize(Decimal("999.9"), Decimal("1e0"))
Decimal('NaN')


Indeed, decNumber returns NaN for to_integral(). This is an odd
situation, since for the result it is possible to exceed the
precision but not Emax:


>>> c = Context(prec=3, Emin=-3, Emax=3, traps=[])
>>> d = Context(prec=4, Emin=-3, Emax=3, traps=[])
>>> c.to_integral(Decimal("999.9"))
Decimal('1000')
>>> d.quantize(Decimal("999.9"), Decimal("1e0"))
Decimal('1000')


The specification is on the side of decNumber, but I wonder if this is
an oversight.

----------
components: Library (Lib)
messages: 127986
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: to_integral() corner cases
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb  5 15:44:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Feb 2011 14:44:42 +0000
Subject: [New-bugs-announce] [issue11129] logging: allow multiple entries in
	qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

When configuration is specified in external file, qualname attribute should allow several values. Maybe comma separated.

----------
messages: 127992
nosy: techtonik
priority: normal
severity: normal
status: open
title: logging: allow multiple entries in qualname config
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  5 17:57:25 2011
From: report at bugs.python.org (ProgVal)
Date: Sat, 05 Feb 2011 16:57:25 +0000
Subject: [New-bugs-announce] [issue11130] SocketServer: server_address is...
	a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>


New submission from ProgVal <progval at gmail.com>:

Hello,

I have issues with a script I'm programming (TypeError at every client connection), so I edited BaseServer's __init__():
    def __init__(self, server_address, RequestHandlerClass):
        """Constructor.  May be extended, do not override."""
        if isinstance(server_address, socket._socketobject):
            raise Exception()
        self.server_address = server_address
        self.RequestHandlerClass = RequestHandlerClass
        self.__is_shut_down = threading.Event()
        self.__shutdown_request = False
And it raises sometimes this traceback:
Exception happened during processing of request from ('127.0.0.1', 32810)
Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 285, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 311, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 324, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.6/SocketServer.py", line 400, in __init__
    BaseServer.__init__(self, server_address, RequestHandlerClass)
  File "/usr/lib/python2.6/SocketServer.py", line 198, in __init__
    raise Exception()

Best regards,
ProgVal

----------
components: Library (Lib)
messages: 127999
nosy: ProgVal
priority: normal
severity: normal
status: open
title: SocketServer: server_address is... a socket
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb  5 19:04:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 18:04:49 +0000
Subject: [New-bugs-announce] [issue11131] decimal.py: plus/minus with
	ROUND_FLOOR
In-Reply-To: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>
Message-ID: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Another exciting corner case in plus/minus:

"The operations are evaluated using the same rules as add and subtract;
 the operations plus(a) and minus(a) (where a and b refer to any numbers)
 are calculated as the operations add(?0?, a) and subtract(?0?, b)
 respectively, where the ?0? has the same exponent as the operand."


But add and subtract have a special rule for the sign with ROUND_FLOOR:

"Otherwise, the sign of a zero result is 0 unless either both operands 
 were negative or the signs of the operands were different and the 
 rounding is round-floor."


So, +Decimal("-0") and -Decimal("0") should be a negative zero. I checked
this against decNumber. Currently:


>>> c = getcontext()
>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('0')
>>> -Decimal("0")
Decimal('0')

----------
components: Library (Lib)
messages: 128007
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: plus/minus with ROUND_FLOOR
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb  6 12:03:22 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 06 Feb 2011 11:03:22 +0000
Subject: [New-bugs-announce] [issue11132] compileall.compile_dir loses
	'optimize' parameter in	recursion.
In-Reply-To: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>
Message-ID: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

july at julynote:~/test> ls -R
.:
c.py  subdir

./subdir:
a.py  b.py
july at julynote:~/test> python3
Python 3.2rc2+ (py3k, Feb  6 2011, 13:06:04) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from compileall import compile_dir
>>> compile_dir('.', optimize=1)
Listing . ...
Compiling ./c.py ...
Listing ./subdir ...
Compiling ./subdir/a.py ...
Compiling ./subdir/b.py ...
1
>>> 
july at julynote:~/test> ls -R
.:
c.py  __pycache__  subdir

./__pycache__:
c.cpython-32.pyo

./subdir:
a.py  b.py  __pycache__

./subdir/__pycache__:
a.cpython-32.pyc  b.cpython-32.pyc
july at julynote:~/test>

It seems that the bug was introduced in svn revision 87019 (Add an "optimize" parameter to compile() to control the optimization level, and provide an interface to it in py_compile, compileall and PyZipFile.).

In recursion, 'optimize' parameter is lost and replaced by default -1 (optimize level of the interpreter).

Test patch added.

----------
components: Library (Lib)
files: compileall.compile_dir.optimize.test.diff
keywords: patch
messages: 128048
nosy: july
priority: normal
severity: normal
status: open
title: compileall.compile_dir loses 'optimize' parameter in recursion.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20696/compileall.compile_dir.optimize.test.diff

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

From report at bugs.python.org  Sun Feb  6 17:30:22 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Feb 2011 16:30:22 +0000
Subject: [New-bugs-announce] [issue11133] inspect.getattr_static code
	execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The documentation of getattr_static says:
"The only known case that can cause getattr_static to trigger code execution, and cause it to return incorrect results (or even break), is where a class uses __slots__ and provides a __dict__ member using a property or descriptor. If you find other cases please report them so they can be fixed or documented."

I'd like to report another case: when an object's __dict__ is an instance of a dict subclass which overrides dict.get:

>>> _sentinel = object()
>>> 
>>> class MyDict(dict):
...     def get(self, key, default=_sentinel):
...             print('Hello World!') # This code will execute
...             if default is _sentinel:
...                     return super().get(key)
...             else:
...                     return super().get(key, default)
... 
>>> class X:
...     def __init__(self):
...             self.__dict__ = MyDict()
... 
>>> x = X()
>>> inspect.getattr_static(x, 'foo', 0)
Hello World!
0
>>> 

(In line 1072. _check_instance calls MyDict.get: instance_dict.get(attr, _sentinel).)

----------
components: Library (Lib)
messages: 128067
nosy: durban, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static code execution
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  6 20:51:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 19:51:49 +0000
Subject: [New-bugs-announce] [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Three slots in type objects are missing in PEP 384. This patch adds them to the ABI.

----------
files: typeslots.diff
keywords: patch
messages: 128075
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Add missing type slots
versions: Python 3.2
Added file: http://bugs.python.org/file20705/typeslots.diff

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

From report at bugs.python.org  Sun Feb  6 21:02:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 20:02:06 +0000
Subject: [New-bugs-announce] [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

There are currently two ways to specify a type doc string in PyType_FromSpec; either through the doc field (which is not actually processed), or through Py_tp_doc (which works correctly).

The original concern for adding doc into the TypeSpec was that the slots may only refer to function pointers; as it turns out, putting character pointers in there works fine as well, so I recommend to drop the doc field in TypeSlot.

The patch also fixes some labelling in the xxlimited module.

----------
files: tp_doc.diff
keywords: patch
messages: 128077
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Redundant doc field in TypeSpec
versions: Python 3.2
Added file: http://bugs.python.org/file20706/tp_doc.diff

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

From report at bugs.python.org  Mon Feb  7 00:42:40 2011
From: report at bugs.python.org (John)
Date: Sun, 06 Feb 2011 23:42:40 +0000
Subject: [New-bugs-announce] [issue11136] imaplib IMAP4_SSL shutdown gets
	socket error in py 3.2
In-Reply-To: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>
Message-ID: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

windows vista
Python 3.2 rc2

situation: 
connected to gmail with IMAP4_SSL, did stuff, and finally IMAP4_SSL.close() 
IMAP4_SSL.logout()
IMAP4_SSL.shutdown() 

shutdown() gets this error:

socket.error: [Errno 10038] An operation was attempted on something that is not a socket

No problem in Python 3.1.2

For now I don't use shutdown(), and hope the socket is closed automatically when the interpreter exits (as open files are).

-- jh

----------
components: Library (Lib)
messages: 128092
nosy: jh45
priority: normal
severity: normal
status: open
title: imaplib IMAP4_SSL shutdown gets socket error in py 3.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb  7 03:18:52 2011
From: report at bugs.python.org (John)
Date: Mon, 07 Feb 2011 02:18:52 +0000
Subject: [New-bugs-announce] [issue11137] clarify use of imaplib IMAP4(_SSL)
	shutdown
In-Reply-To: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>
Message-ID: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

Attempting IMAP4_SSL.shutdown() after IMAP4_SSL.logout() throws an error because the socket is already closed. (I cannot test with plain IMAP4.)

Please add appropriate notice, perhaps under IMAP4.shutdown().

Perhaps something like "If you do not use open(), and do only login() and logout(), you do not need shutdown(), as logout() does it for you."

-- jh

----------
assignee: docs at python
components: Documentation
messages: 128096
nosy: docs at python, jh45
priority: normal
severity: normal
status: open
title: clarify use of imaplib IMAP4(_SSL) shutdown
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb  7 05:41:27 2011
From: report at bugs.python.org (Urago Keisuke)
Date: Mon, 07 Feb 2011 04:41:27 +0000
Subject: [New-bugs-announce] [issue11138] Docs: incollect example: "fill"
	and "align"
In-Reply-To: <1297053687.75.0.437678029921.issue11138@psf.upfronthosting.co.za>
Message-ID: <1297053687.75.0.437678029921.issue11138@psf.upfronthosting.co.za>


New submission from Urago Keisuke <bravo at resourcez.org>:

"Nesting arguments and more complex examples"
at http://docs.python.org/library/string.html#format-examples

Below example code is no errors:
>>> for align, text in zip('<^>', ['left', 'center', 'right']):
...     '{0:{align}{fill}16}'.format(text, fill=align, align=align)

I think meaning is as follows:
...     '{0:{fill}{align}16}'.format(text, fill=align, align=align)

----------
assignee: docs at python
components: Documentation
messages: 128099
nosy: Urago.Keisuke, docs at python
priority: normal
severity: normal
status: open
title: Docs: incollect example: "fill" and "align"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb  7 15:49:37 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 14:49:37 +0000
Subject: [New-bugs-announce] [issue11139] subprocess: Arguments to .bat
	scripts get interpreted by	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>


New submission from Arve Knudsen <arve.knudsen at gmail.com>:

As a regression from Python 2.6, when running .bat scripts on Windows with f.ex. subprocess.call under Python 2.7.1, arguments get interpreted by the shell. This bit me in the way that I could no longer pass arguments containing the character '|' to .bat scripts, something that works fine under Python 2.6.

To see the bug in action, run tst.py in the attached case.zip with Python 2.7.1. The case also demonstrates that the '|' character only gets interpreted when launching cmd scripts, not e.g. python.exe.

----------
components: Library (Lib)
files: case.zip
messages: 128119
nosy: Arve.Knudsen
priority: normal
severity: normal
status: open
title: subprocess: Arguments to .bat scripts get interpreted by shell
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20711/case.zip

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

From report at bugs.python.org  Mon Feb  7 16:35:27 2011
From: report at bugs.python.org (aaugustin)
Date: Mon, 07 Feb 2011 15:35:27 +0000
Subject: [New-bugs-announce] [issue11140] Error in the documentation of
	threading.Lock().release()
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>


New submission from aaugustin <aymeric.augustin at polyconseil.fr>:

The docs for the threading module state that:

> The release() method should only be called in the locked state; it changes the state to unlocked and returns immediately. If an attempt is made to release an unlocked lock, a RuntimeError will be raised.

However, I noticed that catching RuntimeError does not work. Actually release() raises thread.error, which inherits directly Exception.

I reproduced the behavior shown below in Python 2.6.6, 2.7.1 from MacPorts on Mac OS 10.6 and in Python 2.6.6 on Linux. The same happens in Python 3.2rc2 on Mac OS 10.6, except the thread module has been renamed to _thread so the exception becomes a _thread.error.

>>> import threading

>>> try:
...     threading.Lock().release()
... except RuntimeError:
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
thread.error: release unlocked lock

>>> try:
...     threading.Lock().release()
... except Exception, e:
...     print type(e)
...     print type(e).mro()
... 
<class 'thread.error'>
[<class 'thread.error'>, <type 'exceptions.Exception'>, <type 'exceptions.BaseException'>, <type 'object'>]

I do not know if this must be fixed in the docs or the code. Currently, the type of the exception is probably platform-dependant since the thread module is not provided on all platforms.

----------
components: Library (Lib)
messages: 128128
nosy: aaugustin
priority: normal
severity: normal
status: open
title: Error in the documentation of threading.Lock().release()
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  7 18:03:03 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 07 Feb 2011 17:03:03 +0000
Subject: [New-bugs-announce] [issue11141] 2.x range() in 3.x shelve
	documentation
In-Reply-To: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>
Message-ID: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The example in the shelve documentation (http://docs.python.org/dev/py3k/library/shelve.html#example) uses the old range() (which returned a list):

d['xx'] = range(4)  # this works as expected, but...
d['xx'].append(5)   # *this doesn't!* -- d['xx'] is STILL range(4)!

----------
assignee: docs at python
components: Documentation
messages: 128138
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: 2.x range() in 3.x shelve documentation
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb  7 18:33:39 2011
From: report at bugs.python.org (Erez Sh)
Date: Mon, 07 Feb 2011 17:33:39 +0000
Subject: [New-bugs-announce] [issue11142] xmlrpclib.ServerProxy with
	verbosity produces bad output
In-Reply-To: <1297100019.07.0.0200011843084.issue11142@psf.upfronthosting.co.za>
Message-ID: <1297100019.07.0.0200011843084.issue11142@psf.upfronthosting.co.za>


New submission from Erez Sh <erez27 at gmail.com>:

In xmlrpclib, a ServerProxy initialized with verbose=True produces an occasionally jumbled-up output, due to a multiple threads writing to stdout without synchronizing.

I noticed this happening only for incoming data (at line 1461:                 print "body:", repr(data) ).

I seem to have fixed it locally by accumulating all the data and printing it (within a lock) outside of the send/recv loop.

It is a useful feature for debugging and logging the 'raw' communication, but virtually useless if one can't rely on its output.

----------
components: Library (Lib)
messages: 128141
nosy: Erez.Sh
priority: normal
severity: normal
status: open
title: xmlrpclib.ServerProxy with verbosity produces bad output
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 18:38:58 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 17:38:58 +0000
Subject: [New-bugs-announce] [issue11143] Issue with the issue tracker
In-Reply-To: <1297100338.89.0.650994969187.issue11143@psf.upfronthosting.co.za>
Message-ID: <1297100338.89.0.650994969187.issue11143@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Should I report it here?  The issue is with this issue tracker itself.  If we search for "2147483647" using the "search" box on this site (look up to the right), then it works; but if we search for "2147483648" or a bigger number (without the quotes), then we get an internal error :-)

----------
messages: 128142
nosy: arigo
priority: normal
severity: normal
status: open
title: Issue with the issue tracker

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

From report at bugs.python.org  Mon Feb  7 18:45:55 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 17:45:55 +0000
Subject: [New-bugs-announce] [issue11144] int(float) may return a long for
	no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

On 32 bits, there is no reason to get a 'long' here:

>>> int(float(sys.maxint))
2147483647L
>>> int(int(float(sys.maxint)))
2147483647
>>> int(float(-sys.maxint-1))
-2147483648L
>>> int(int(float(-sys.maxint-1)))
-2147483648

On 64 bits, it's another story because floats cannot store 64 bits of precision.  However, -sys.maxint-1 can still be represented exactly in a float, and the same issue occurs:

>>> int(float(-sys.maxint-1))
-9223372036854775808L
>>> int(int(float(-sys.maxint-1)))
-9223372036854775808

----------
components: Interpreter Core
messages: 128143
nosy: arigo
priority: normal
severity: normal
status: open
title: int(float) may return a long for no reason
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 19:46:34 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 18:46:34 +0000
Subject: [New-bugs-announce] [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The expression  '%o' % x,  where x is a user-defined instance, usually ignores a user-defined __oct__() method.  I suppose that's fine; assuming this is the expected behavior, then the present issue is about the "usually" in my previous sentence.

If 'x' is an instance of a subclass of 'long', then the __oct__() is called.  It must be specifically a 'long' -- not, say, 'int' or 'str' or 'object'.  Moreover, there is a test in test_format.py (class Foobar) that checks that if this __oct__() returns a non-string, then we get a nice TypeError.  That's already strange -- why is __oct__() called in the first place?  But trying out more I get (CPython 2.7.1):

>>> class X(long):
...   def __oct__(self):
...     return 'abc'
... 
>>> '%o' % X()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: ../trunk/Objects/stringobject.c:4035: bad argument to internal function

----------
components: Interpreter Core
messages: 128148
nosy: arigo
priority: normal
severity: normal
status: open
title: '%o' % user-defined instance
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 20:25:06 2011
From: report at bugs.python.org (=?utf-8?q?Manuel_B=C3=A4renz?=)
Date: Mon, 07 Feb 2011 19:25:06 +0000
Subject: [New-bugs-announce] [issue11146] Add a feature similar to C++
	"using some_namespace"
In-Reply-To: <1297106706.4.0.712510956651.issue11146@psf.upfronthosting.co.za>
Message-ID: <1297106706.4.0.712510956651.issue11146@psf.upfronthosting.co.za>


New submission from Manuel B?renz <manuel at enigmage.de>:

In C++, the the approach to the namespace problem is having different namespaces that should not contain different definitions of the same name.
Members of a namespace can be accessed explicitly by e.g. calling "std::cout << etc." or "using namespace std; cout << etc."

I understand Pythons approach to be "objects can be used as namespaces and their attributes are the names they contain". I find this a very beautiful way of solving the issue, but it has a downside, in my opinion, because it lacks the "using" directive from C++.

If the object is a module, we can of course do "from mymodule import spam, eggs". But if it is not a module, this does not work.

Consider for example:

class Spam(object):
    def frobnicate(self):
        self.eggs = self.buy_eggs()
        self.scrambled = self.scramble(self.eggs)
        return self.scrambled > 42

This could be easier to implement and read if we had something like:

class Spam(object):
    def frobnicate(self):
        using self:
            eggs = buy_eggs()
            scrambled = scramble(eggs)
            return scrambled > 42

Of course this opens a lot of conceptual questions like how should this using block behave if self doesn't have an attribute called "eggs", but I think it is worth considering.

----------
messages: 128153
nosy: turion
priority: normal
severity: normal
status: open
title: Add a feature similar to C++ "using some_namespace"
type: feature request

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

From report at bugs.python.org  Tue Feb  8 04:16:06 2011
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 08 Feb 2011 03:16:06 +0000
Subject: [New-bugs-announce] [issue11147] _Py_ANNOTATE_MEMORY_ORDER has
	unused argument, effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Hi, Im buildiong blender3d with  -Werror and python 3.2 gives an error which doesnt happen in 3.1.

Tested with SVN r88378. on linux.
---
cc1: warnings being treated as errors
In file included from /opt/py32/include/python3.2d/Python.h:52:0,
                 from /data/src/blender/blender/source/blender/python/intern/bpy_app.h:27,
                 from /data/src/blender/blender/source/blender/python/intern/bpy_app.c:25:
/opt/py32/include/python3.2d/pyatomic.h: In function '_Py_ANNOTATE_MEMORY_ORDER':
/opt/py32/include/python3.2d/pyatomic.h:59:48: error: unused parameter 'address'


There are 2 ways to solve this:
pyatomic.h could include the line:
    (void)address;

Or the macro's which do nothing could be changed from...
#define _Py_ANNOTATE_HAPPENS_BEFORE(blah) /* empty */
to...
#define _Py_ANNOTATE_HAPPENS_BEFORE(blah) (void)blah

----------
messages: 128165
nosy: ideasman42
priority: normal
severity: normal
status: open
title: _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code which includes Python.h
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb  8 11:19:29 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Tue, 08 Feb 2011 10:19:29 +0000
Subject: [New-bugs-announce] [issue11148] Crash and error message from
	Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>


New submission from Pham Cong Dinh <pcdinh at gmail.com>:

Quite often, I got the following message printed out the console while I run my Python script

pthread_cond_signal: Undefined error: 0

Or it crashed

https://gist.github.com/799841

Tested with Python 2.6.1 and 2.6.6 (Mac)

What I am trying to do is to set up a logging component that collects all messages sent from child processes to a pipe created by the parent process. The logging component is controlled by a thread created by parent process

----------
components: Interpreter Core
messages: 128168
nosy: pcdinh
priority: normal
severity: normal
status: open
title: Crash and error message from Python VM
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb  8 11:46:47 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 08 Feb 2011 10:46:47 +0000
Subject: [New-bugs-announce] [issue11149] [PATCH] Configure should enable
	-fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>


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

clang (as with gcc 4.x) assumes signed integer overflow is undefined. But Python depends on the fact that signed integer overflow wraps. 

Currently configure script adds -fwrapv flag for GCC (added by me back in the day), same should be done with clang.

Patch attached.

----------
components: Build
files: clang-fwrapv.diff
keywords: patch
messages: 128170
nosy: cartman
priority: normal
severity: normal
status: open
title: [PATCH] Configure should enable -fwrapv for clang
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20717/clang-fwrapv.diff

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

From report at bugs.python.org  Tue Feb  8 12:46:46 2011
From: report at bugs.python.org (Yegor Bugayenko)
Date: Tue, 08 Feb 2011 11:46:46 +0000
Subject: [New-bugs-announce] [issue11150] SVN credentials can't be provided
	to easy_install
In-Reply-To: <1297165606.66.0.401299802091.issue11150@psf.upfronthosting.co.za>
Message-ID: <1297165606.66.0.401299802091.issue11150@psf.upfronthosting.co.za>


New submission from Yegor Bugayenko <team at fazend.com>:

I'm trying to install Python EGG with `easy_install`, providing a URL of Subversion repository, where sources are hosted:

    $ easy_install svn://user:secret at svn.example.com/repo/trunk/my-egg
    Authentication realm: <svn://svn.example.com:3690> repo
    Password for 'me':
    
The problem is that the repository is password protected. How can I provide the desired username/password to `easy_install`?

Everything works fine when I'm using `http://` protocol instead of `svn://`

----------
components: Installation
messages: 128173
nosy: yegor256
priority: normal
severity: normal
status: open
title: SVN credentials can't be provided to easy_install
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  8 14:09:55 2011
From: report at bugs.python.org (Noufal)
Date: Tue, 08 Feb 2011 13:09:55 +0000
Subject: [New-bugs-announce] [issue11151] Arguments to various types not
	specified in types module
In-Reply-To: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>
Message-ID: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>


New submission from Noufal <noufal at nibrahim.net.in>:

The documentation for the types module seems to have an obvious bug. The arguments to create the various types are not mentioned in the docs page on http://docs.python.org/library/types.html

This came to my attention from a stack overflow question here
http://stackoverflow.com/questions/4933325/where-can-i-find-documentation-for-calling-the-various-types-in-pythons-types-mo

----------
assignee: docs at python
components: Documentation
messages: 128175
nosy: docs at python, noufal
priority: normal
severity: normal
status: open
title: Arguments to various types not specified in types module
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  8 16:22:16 2011
From: report at bugs.python.org (labem)
Date: Tue, 08 Feb 2011 15:22:16 +0000
Subject: [New-bugs-announce] [issue11152] pb in zipfile module
In-Reply-To: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>
Message-ID: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>


New submission from labem <labem at E-i.com>:

Detected in Python version:
Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32

Error in zipfile module: Zip files with no compressed files may contain only 
   [end of central directory record] bloc
without anything else. In that case, when _EndRecData(fpin) function tries to call:
         return _EndRecData64(fpin, -sizeEndCentDir, endrec)
it makes _EndRecData64() trying to seek data in the file before the beginning of the file and generates IOError "Invalid Argument" which is :
* either badly (in is_zipfile()), 
* or not catched (in __init()__._GetContents()._RealGetContents().EndRecData()).

Correction seems easy (not tested) and just need to replace:
        # Try to read the "Zip64 end of central directory" structure
        return _EndRecData64(fpin, -sizeEndCentDir, endrec)
by:
        # check if other block are present
        if filesize > sizeEndCentDir:
            # Try to read the "Zip64 end of central directory" structure
            return _EndRecData64(fpin, -sizeEndCentDir, endrec)
        else:
        		# no other block present
            return endrec

----------
components: Library (Lib)
messages: 128180
nosy: Emmanuel LAB
priority: normal
severity: normal
status: open
title: pb in zipfile module
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb  8 21:41:19 2011
From: report at bugs.python.org (Matthew M. Boedicker)
Date: Tue, 08 Feb 2011 20:41:19 +0000
Subject: [New-bugs-announce] [issue11153] urllib2 basic auth parser handle
	unquoted realm in	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>


New submission from Matthew M. Boedicker <matthewm at boedicker.org>:

I am working with a web server that does not quote the realm in the WWW-Authenticate header.

This patch will make the realm parsing handle unquoted realm as well as some other invalid variations.

I tried doing it by modifying the regex only but could not get it to handle all cases.

----------
components: Library (Lib)
files: urllib2_unquoted_realm.diff
keywords: patch
messages: 128190
nosy: mmb
priority: normal
severity: normal
status: open
title: urllib2 basic auth parser handle unquoted realm in WWW-Authenticate header
Added file: http://bugs.python.org/file20719/urllib2_unquoted_realm.diff

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

From report at bugs.python.org  Tue Feb  8 23:43:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Feb 2011 22:43:56 +0000
Subject: [New-bugs-announce] [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>


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

It would be great if the "__pycache__" name could be set by an environment variable.  I would like to rename it to ".pycache" so that it doesn't pollute my directory listings.

----------
assignee: barry
messages: 128194
nosy: barry, rhettinger
priority: normal
severity: normal
status: open
title: Alternate name for __pycache__
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  9 01:35:47 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Wed, 09 Feb 2011 00:35:47 +0000
Subject: [New-bugs-announce] [issue11155] multiprocessing.Queue's put()
	signature differs from docs
In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>
Message-ID: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>


New submission from Erik Cederstrand <ec at 1calendar.dk>:

In Python 2.6.6 on OSX:

>>> import inspect
>>> from multiprocessing import Queue
>>> q = Queue()
>>> print(inspect.getargspec(q.put))
ArgSpec(args=['self', 'obj', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None))
>>> from Queue import Queue
>>> q = Queue()
>>> print(inspect.getargspec(q.put))
ArgSpec(args=['self', 'item', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None))

Notice the 'obj' argument in the multiprocessing version and the 'item' argument in the Queue version. I think 'obj' should be renamed to 'item' to be in line with the other implementation and to agree with the docs: (http://docs.python.org/library/multiprocessing.html?highlight=multiprocessing#multiprocessing.Queue.put):

    put(item[, block[, timeout]])

----------
assignee: docs at python
components: Documentation
messages: 128200
nosy: Erik.Cederstrand, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.Queue's put() signature differs from docs
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 03:10:00 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Wed, 09 Feb 2011 02:10:00 +0000
Subject: [New-bugs-announce] [issue11156] email.encoders.encode_base64
	create a single long line
In-Reply-To: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>
Message-ID: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>


New submission from Yves Dorfsman <yves at zioup.com>:

email.encoders.encode_base64 returns a str of a single long line instead of breaking it up into 76 chars line as per RFC 2045, and as implemented by email.base64mime.

Solution:
In /usr/lib/python3.1/email/encoders.py, use encodebytes instead of b64encode:

--- encoders.py 2011-02-08 09:37:21.025030051 -0700
+++ encoders.py.yves    2011-02-08 09:38:04.945608365 -0700
@@ -12,7 +12,7 @@
     ]
 
 
-from base64 import b64encode as _bencode
+from base64 import encodebytes as _bencode
 from quopri import encodestring as _encode

----------
components: Library (Lib)
messages: 128202
nosy: yves at zioup.com
priority: normal
severity: normal
status: open
title: email.encoders.encode_base64 create a single long line
versions: Python 3.1

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

From report at bugs.python.org  Wed Feb  9 06:37:30 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 09 Feb 2011 05:37:30 +0000
Subject: [New-bugs-announce] [issue11157] Use socket.accept4 syscall under
	linux
In-Reply-To: <1297229850.72.0.00775605650951.issue11157@psf.upfronthosting.co.za>
Message-ID: <1297229850.72.0.00775605650951.issue11157@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

socket.accept() should have optional argument flags. see 'man accept4'
It should use fcntl() if accept4() not supported.

This is performance issue.

----------
components: IO, Library (Lib)
messages: 128205
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Use socket.accept4 syscall under linux
type: feature request

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

From report at bugs.python.org  Wed Feb  9 09:25:51 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Wed, 09 Feb 2011 08:25:51 +0000
Subject: [New-bugs-announce] [issue11158] Parent process did not quit after
	sys.exit()
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>


New submission from Pham Cong Dinh <pcdinh at gmail.com>:

Hi,

I was implementing a multiple process compatible logging which child processes are expected to send all messages to the parent process via a queue and then the parent process serializes and flushes them into a log file. The idea is built around multiprocessing.Queue()

The problem is the first child process is always blocked while subsequent ones can run smoothly. It seems to be blocked on semaphore_wait_signal_trap

Environment
===========
Mac OS X 10.6.5 
Python 2.6.6

Reproduction script:
====================
https://gist.github.com/818114

Command to run
====================

python log.py

Console message
===============
Dinh-Phams-MacBook-Pro:task dinhpham$ python log.py
Parent PID 90401
90403
Parent PID 90401
Parent PID 90401
90404
Parent PID 90401
90405
No child process exits
90406
Child process ID 90406
Child process ID 90404
Child process ID 90405
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
Child process PID 90404 will exits now
Child process PID 90406 will exits now
Child process PID 90405 will exits now
The child process 90406 exits
The child process 90405 exits
The child process 90404 exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
^C[90403]
Parent process exits
Dinh-Phams-MacBook-Pro:task dinhpham$ 
 


=========> All the process exits except the first child process one (90403)

----------
components: Interpreter Core
messages: 128206
nosy: pcdinh
priority: normal
severity: normal
status: open
title: Parent process did not quit after sys.exit()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 15:20:03 2011
From: report at bugs.python.org (Rickard Lindberg)
Date: Wed, 09 Feb 2011 14:20:03 +0000
Subject: [New-bugs-announce] [issue11159] Sax parser crashes if given
	unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>


New submission from Rickard Lindberg <ricli85 at gmail.com>:

The error is the following:

    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/__init__.py", line 31, in parse
        parser.parse(filename_or_stream)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
        xmlreader.IncrementalParser.parse(self, source)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/xmlreader.py", line 119, in parse
        self.prepareParser(source)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 121, in prepareParser
        self._parser.SetBase(source.getSystemId())
    UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 0: ordinal not in range(128)

The following bash script can be used to reproduce the error:

    #!/bin/sh

    cat > ?.timeline <<EOF
    <?xml version="1.0" encoding="utf-8"?>
    <timeline>
      <version>0.13.0devb38ace0a572b+</version>
      <categories>
      </categories>
      <events>
        <event>
          <start>2011-02-01 00:00:00</start>
          <end>2011-02-03 08:46:00</end>
          <text>asdsd</text>
        </event>
      </events>
      <view>
        <displayed_period>
          <start>2011-01-24 16:38:11</start>
          <end>2011-02-23 16:38:11</end>
        </displayed_period>
        <hidden_categories>
        </hidden_categories>
      </view>
    </timeline>
    EOF

    python <<EOF
    # encoding: utf-8
    from xml.sax import parse
    from xml.sax.handler import ContentHandler
    parse(open(u"?.timeline", 'r'), ContentHandler())
    EOF

If I instead do this, it works fine:

    parse(u"?.timeline".encode("utf-8"), ContentHandler())

Also:

    >>> sys.getfilesystemencoding()
    'UTF-8'

I heard from another user that this was not a problem with Python 3.1.2.

----------
components: XML
messages: 128212
nosy: ricli85
priority: normal
severity: normal
status: open
title: Sax parser crashes if given unicode file name
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  9 16:09:00 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 09 Feb 2011 15:09:00 +0000
Subject: [New-bugs-announce] [issue11160] ZipFile.comment expects bytes
In-Reply-To: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>
Message-ID: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>


New submission from Xuanji Li <xuanji at gmail.com>:

The documentation for zipfile describes ZipFile.comment as "The comment text associated with the ZIP file." From reading this I expect that setting it to a string is ok; however ZipFile.comment must actually be set to bytes (or a bytes-like object, I am not very sure).

This may also unexpectedly affect old code because I saw one patch on the bug tracker that was written just last year that set ZipFile.comment to a string. 

IMO there are 2 ways to fix:

1) Change docs to mention that ZipFile.comment only accepts bytes
2) Patch zipfile.py to accept string and try to convert, throwing an error if the conversion fails

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 128217
nosy: docs at python, haypo, xuanji
priority: normal
severity: normal
status: open
title: ZipFile.comment expects bytes
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  9 19:03:19 2011
From: report at bugs.python.org (paul clinch)
Date: Wed, 09 Feb 2011 18:03:19 +0000
Subject: [New-bugs-announce] [issue11161] futures.ProcessPoolExecutor hangs
In-Reply-To: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>
Message-ID: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>


New submission from paul clinch <pclinch at internet-glue.co.uk>:

The example ``16.4.3.1. ProcessPoolExecutor Example`` hangs in IDLE silently,  and hangs the interactive python shell with ``AttributeError: 'module' object has no attribute 'is_prime'``.

is_prime(9) was tested before running.

Platform is windows XP.

``c:\Python32\python.exe -m test.test_concurrent_futures``

passes all tests.

----------
components: IDLE
messages: 128228
nosy: pclinch
priority: normal
severity: normal
status: open
title: futures.ProcessPoolExecutor hangs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  9 20:46:23 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 09 Feb 2011 19:46:23 +0000
Subject: [New-bugs-announce] [issue11162] Add tuple/list sep to string split
	method
In-Reply-To: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>
Message-ID: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I was hoping that I could use a list/tuple of separators for the split method:

    "abcde".split(["b", "d"])

vs.

    import re
    re.split("b|d", "abcde")

That's one extra LOC, and (worse still) forces me to learn regexp.

Does this suggested 'improvement' make sense?

----------
components: Library (Lib)
messages: 128234
nosy: tshepang
priority: normal
severity: normal
status: open
title: Add tuple/list sep to string split method

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

From report at bugs.python.org  Wed Feb  9 21:40:45 2011
From: report at bugs.python.org (Michael Grazebrook)
Date: Wed, 09 Feb 2011 20:40:45 +0000
Subject: [New-bugs-announce] [issue11163] iter() documentation code doesn't
	work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>


New submission from Michael Grazebrook <michael at grazebrook.com>:

This code fragment from the documentation of iter() doesn't work as intended. Change "STOP" to "STOP\n". Maybe also check for EOF as it hangs.

with open("mydata.txt") as fp:
    for line in iter(fp.readline, "STOP"):
        process_line(line)

Or maybe this makes a better example because it's clearer wha'ts going on:

square_generator = (i * i for i in range(100000))
for n in iter( square_generator.next, 144):
    print n

----------
assignee: docs at python
components: Documentation
messages: 128238
nosy: docs at python, mgrazebrook
priority: normal
severity: normal
status: open
title: iter() documentation code doesn't work
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 23:10:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 09 Feb 2011 22:10:28 +0000
Subject: [New-bugs-announce] [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Lib/xml/__init__.py since r16544 tries to replace xml package with _xmlplus package from PyXML. PyXML is no longer maintained and doesn't support Python 3, so it should be safe to remove PyXML-related code in Lib/xml/__init__.py in Python 3.1 / 3.2.

----------
components: Library (Lib), XML
messages: 128242
nosy: Arfrever, akuchling, fdrake, jkloth, loewis
priority: normal
severity: normal
status: open
title: xml shouldn't use _xmlplus
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb  9 23:56:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Feb 2011 22:56:11 +0000
Subject: [New-bugs-announce] [issue11165] Document PyEval_Call* functions
In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>
Message-ID: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>


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

There are currently undocumented PyEval_Call* equivalents to a number of the PyObject_Call* functions.

Since there are resources out there on the web that direct people to use the currently undocumented PyEval functions, it would be good to document those properly, and recommend people typically use the PyObject_Call* variants instead (as the latter include all the stack and interpreter state integrity protection code, while the PyEval variants assume that has all already been handled).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 128248
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PyEval_Call* functions
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 10 04:40:03 2011
From: report at bugs.python.org (Dan Mahn)
Date: Thu, 10 Feb 2011 03:40:03 +0000
Subject: [New-bugs-announce] [issue11166] No exit when daemon thread is
	running.
In-Reply-To: <1297309203.91.0.996465848565.issue11166@psf.upfronthosting.co.za>
Message-ID: <1297309203.91.0.996465848565.issue11166@psf.upfronthosting.co.za>


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

I have a python-based test script that creates a daemon thread.  The foreground basically runs a loop of commands, while the daemon thread sends some UDP data on the network.  To stop the script, I use Control-C.  This is running under 64-bit Windows (Vista) with 64-bit Python.

This script was developed under Python version 3.0, and has been running fine with 3.1.  I downloaded 3.2RC1 and noticed that the script does not exit with the typical Ctrl-C.  I also tried 3.2RC2, which had the same effect.  If I do not start the background thread, the test exits normally.

If I use Python 3.1, but I don't set the daemon attribute on the background thread, the operation duplicates the problem.  Therefore, I believe there is a problem with 3.2 handling of daemon threads.

----------
components: None
messages: 128260
nosy: dmahn
priority: normal
severity: normal
status: open
title: No exit when daemon thread is running.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 10:14:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Feb 2011 09:14:17 +0000
Subject: [New-bugs-announce] [issue11167] Overflow in unicode_hash
In-Reply-To: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>
Message-ID: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Due to an integer overflow in unicode_hash, the python interpreter
crashes if built with -ftrapv:

./configure --with-pydebug CFLAGS="-ftrapv"



Starting program: /home/stefan/svn/py3k/python 
[Thread debugging using libthread_db enabled]

Program received signal SIGABRT, Aborted.
0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff71ea5c0 in *__GI_abort () at abort.c:92
#2  0x00000000005e30a0 in __mulvdi3 ()
#3  0x000000000046304b in unicode_hash (self=0x7ffff7fab110) at Objects/unicodeobject.c:7600
#4  0x000000000041a313 in PyObject_Hash (v=0x7ffff7fab110) at Objects/object.c:762
#5  0x00000000005a9093 in PyDict_GetItem (op=0x8be030, key=0x7ffff7fab110) at Objects/dictobject.c:715
#6  0x000000000046d88c in PyUnicode_InternInPlace (p=0x7fffffffdf38) at Objects/unicodeobject.c:10026
#7  0x000000000046da8b in PyUnicode_InternFromString (cp=0x5e7c99 "__len__") at Objects/unicodeobject.c:10065
#8  0x0000000000445eba in init_slotdefs () at Objects/typeobject.c:5801
#9  0x000000000044633b in add_operators (type=0x846400) at Objects/typeobject.c:5955
#10 0x000000000043e950 in PyType_Ready (type=0x846400) at Objects/typeobject.c:3860
#11 0x000000000043e87e in PyType_Ready (type=0x846000) at Objects/typeobject.c:3824
#12 0x000000000041c786 in _Py_ReadyTypes () at Objects/object.c:1513
#13 0x00000000004c99a6 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:229
#14 0x00000000004c9d78 in Py_Initialize () at Python/pythonrun.c:321
#15 0x00000000004ead8c in Py_Main (argc=1, argv=0x7ffff7fa9040) at Modules/main.c:597
#16 0x00000000004187cf in main (argc=1, argv=0x7fffffffe3c8) at ./Modules/python.c:59



Breakpoint 1, unicode_hash (self=0x7ffff7fab110) at Objects/unicodeobject.c:7594
7594        if (self->hash != -1)
(gdb) n
7596        len = Py_SIZE(self);
(gdb) n
7597        p = self->str;
(gdb) n
7598        x = *p << 7;
(gdb) n
7599        while (--len >= 0)
(gdb) p x
$1 = 12160
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n
7599        while (--len >= 0)
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n
7599        while (--len >= 0)
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n

Program received signal SIGABRT, Aborted.
0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) quit



This might be related to issue #10156 (unicode initialization is
not clearly defined).

----------
components: Interpreter Core
messages: 128270
nosy: georg.brandl, skrah
priority: critical
severity: normal
stage: needs patch
status: open
title: Overflow in unicode_hash
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 13:21:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 12:21:42 +0000
Subject: [New-bugs-announce] [issue11168] UnicodeEncodeError on recusion
	limit if the script	filename is undecodable
In-Reply-To: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>
Message-ID: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>


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

If the script filename is not decodable from the filesystem encoding, Python fails with a UnicodeEncodeError when we reach the recursion limit. The problem doesn't come from the user script, but from Python internals. It is difficult to understand and the user expects a 


A longer explanation:

test_runpy fails with a pydebug build if the script filename is not encodable to UTF-8. In pydebug build only, PyEval_EvalFrameEx() encodes the frame filename to UTF-8. If the filename contains a surrogate character (which only occurs on UNIX with undecodable filename),the encoding function fails. PyEval_EvalFrameEx() ignores the error except if we hit the recusion limit (if the overflowed attribute of the thread state if set): in this case, the error is not ignored.

To reproduce the problem, change the Python directory (your local repository) to an undecodable filename (eg. b'py3k\xe9\xff' with UTF-8 locale encoding) and run: ./python Lib/test/regrtest.py test_py.


Solutions :

I propose to remove the filename variable from PyEval_EvalFrameEx() because it is only used by the old gdb macros: python-gdb.py doesn't need it anymore.

=> see attached patch

Or if you really want to keep it, tstate->overflowed should be reinitialized. But on overflow, other variables are changed, like _Py_CheckRecursionLimit. I don't know this code enough to write a correct patch, but the minimal patch is:

--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -1234,7 +1234,7 @@ PyEval_EvalFrameEx(PyFrameObject *f, int throwflag)
         filename = _PyUnicode_AsString(co->co_filename);
         if (filename == NULL && tstate->overflowed) {
             /* maximum recursion depth exceeded */
-            goto exit_eval_frame;
+            tstate->overflowed = 0;
         }
         PyErr_Restore(error_type, error_value, error_traceback);
     }

----------
components: Unicode
files: ceval_filename.patch
keywords: patch
messages: 128285
nosy: haypo
priority: normal
severity: normal
status: open
title: UnicodeEncodeError on recusion limit if the script filename is undecodable
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20728/ceval_filename.patch

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

From report at bugs.python.org  Thu Feb 10 13:38:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 12:38:46 +0000
Subject: [New-bugs-announce] [issue11169] compileall doesn't support the PEP
	383 (undecodable	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>


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

The compileall uses print("bla", filename, "bla") to write messages to the console. But the print fails if the filename cannot be encoded to the console encoding. It occurs if the filename is an undecodable filename encoded by the PEP 383 using surrogates. For example, UTF-8 cannot encode surrogates.

Attached patch uses repr() to escape surrogates: it adds also quotes to the filename. I don't know if it is a problem to add quotes. I prefer quotes, but it is more readable if the path or the filename contain spaces.

----------
components: Unicode
files: compileall_surrogates.patch
keywords: patch
messages: 128288
nosy: haypo
priority: normal
severity: normal
status: open
title: compileall doesn't support the PEP 383 (undecodable paths/filenames)
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20729/compileall_surrogates.patch

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

From report at bugs.python.org  Thu Feb 10 13:58:22 2011
From: report at bugs.python.org (didzis)
Date: Thu, 10 Feb 2011 12:58:22 +0000
Subject: [New-bugs-announce] [issue11170] (MacOS X) Crash on non-english
	language keyboard input	in Text widget
In-Reply-To: <1297342702.16.0.660188082743.issue11170@psf.upfronthosting.co.za>
Message-ID: <1297342702.16.0.660188082743.issue11170@psf.upfronthosting.co.za>


New submission from didzis <g_didzis at inbox.lv>:

In simple text edit trying to input non-english characters with keyboard ends with a crash on MacOS X (10.6).

For example, to input Latvian language characters, apostrophe should be pressed followed by some letter (a, e, i, u, k, l, ...)

Tkinter crashes immediately after apostrophe was pressed on keyboard.

Terminal output:

2011-02-10 14:52:29.444 Python[10633:613] An uncaught exception was raised
2011-02-10 14:52:29.448 Python[10633:613] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
2011-02-10 14:52:29.450 Python[10633:613] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff88d407b4 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff86f480f3 objc_exception_throw + 45
	2   CoreFoundation                      0x00007fff88d405d7 +[NSException raise:format:arguments:] + 103
	3   CoreFoundation                      0x00007fff88d40564 +[NSException raise:format:] + 148
	4   Foundation                          0x00007fff8384e5e1 -[NSCFString characterAtIndex:] + 97
	5   Tk                                  0x00000001010b5bcf Tk_SetCaretPos + 663
	6   Tk                                  0x00000001010bbd94 Tk_MacOSXSetupTkNotifier + 699
	7   Tcl                                 0x00000001007542ae Tcl_DoOneEvent + 297
	8   _tkinter.so                         0x00000001006d262d Tkapp_MainLoop + 413
	9   Python                              0x00000001000c124d PyEval_EvalFrameEx + 22397
	10  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	11  Python                              0x00000001000c0d8a PyEval_EvalFrameEx + 21178
	12  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	13  Python                              0x000000010003dd80 function_call + 176
	14  Python                              0x000000010000c9f2 PyObject_Call + 98
	15  Python                              0x000000010001eebb instancemethod_call + 363
	16  Python                              0x000000010000c9f2 PyObject_Call + 98
	17  Python                              0x00000001000ba817 PyEval_CallObjectWithKeywords + 87
	18  Python                              0x000000010002214e PyInstance_New + 126
	19  Python                              0x000000010000c9f2 PyObject_Call + 98
	20  Python                              0x00000001000be813 PyEval_EvalFrameEx + 11587
	21  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	22  Python                              0x00000001000c3066 PyEval_EvalCode + 54
	23  Python                              0x00000001000e7b2e PyRun_FileExFlags + 174
	24  Python                              0x00000001000e7de9 PyRun_SimpleFileExFlags + 489
	25  Python                              0x00000001000fe75c Py_Main + 2940
	26  Python                              0x0000000100000f14 0x0 + 4294971156
)
terminate called after throwing an instance of 'NSException'
Abort trap

----------
components: Tkinter
messages: 128289
nosy: didzis
priority: normal
severity: normal
status: open
title: (MacOS X) Crash on non-english language keyboard input in Text widget
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 10 14:47:46 2011
From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=)
Date: Thu, 10 Feb 2011 13:47:46 +0000
Subject: [New-bugs-announce] [issue11171] Python 2.7.1 does not start when
	"./configure" is used	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>


New submission from Berthold H?llmann <hoel at users.sourceforge.net>:

I do get (with 2.7.1):

> python
Traceback (most recent call last):
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 287, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/gltools/python/Python-2.7/lib/python2.7/config/Makefile (No such file or directory)

The Makefile is platform dependendent und is located at

/usr/local/gltools/python/Python-2.7/linux_x86_64/lib/python2.7/config/Makefile

This problem is fixed for me by a simple pach:

> diff -c /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py~
*** /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py     2011-02-10 14:33:34.000015000 +0100
--- /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py~    2011-02-10 14:28:17.001245000 +0100
***************
*** 271,277 ****
  def _get_makefile_filename():
      if _PYTHON_BUILD:
          return os.path.join(_PROJECT_BASE, "Makefile")
!     return os.path.join(get_path('platstdlib'), "config", "Makefile")
  
  
  def _init_posix(vars):
--- 271,277 ----
  def _get_makefile_filename():
      if _PYTHON_BUILD:
          return os.path.join(_PROJECT_BASE, "Makefile")
!     return os.path.join(get_path('stdlib'), "config", "Makefile")
  
  
  def _init_posix(vars):

----------
components: Installation
messages: 128292
nosy: hoel
priority: normal
severity: normal
status: open
title: Python 2.7.1 does not start when "./configure" is used with  "--prefix" != "--exec-prefix"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 10 15:03:01 2011
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 10 Feb 2011 14:03:01 +0000
Subject: [New-bugs-announce] [issue11172] Avoid '.' as runpath on AIX
In-Reply-To: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>
Message-ID: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner <michael.haubenwallner at salomon.at>:

Spotted in issue#941346 msg#128214, the "-L$(srcdir)" should be removed from BLDSHARED on AIX:

The problem is that '-L$(srcdir)' adds '$(srcdir)' to the runpath too (as there is no '-blibpath' argument), opening a security hole for libpythonX.Y.so as well as the modules.so.

As LDLIBRARY points to the immediate file 'libpython$(VERSION).so' instead of '-lpython$(VERSION)', I don't see the need for '-L$(srcdir)' at all.

----------
components: Build
files: python-2.7.1-aix-safe-runpath.patch
keywords: patch
messages: 128293
nosy: haubi
priority: normal
severity: normal
status: open
title: Avoid '.' as runpath on AIX
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20730/python-2.7.1-aix-safe-runpath.patch

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

From report at bugs.python.org  Thu Feb 10 16:19:15 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Feb 2011 15:19:15 +0000
Subject: [New-bugs-announce] [issue11173] Undocumented public APIs in Python
	3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

Mark Shannon on python-dev:

The following API functions were removed from 3.1.3:

PyAST_Compile
PyCObject_AsVoidPtr
PyCObject_FromVoidPtr
PyCObject_FromVoidPtrAndDesc
PyCObject_GetDesc
PyCObject_Import
PyCObject_SetVoidPtr
PyCode_CheckLineNumber
Py_CompileStringFlags
PyEval_CallObject
PyOS_ascii_atof
PyOS_ascii_formatd
PyOS_ascii_strtod
PyThread_exit_prog
PyThread__PyThread_exit_prog
PyThread__PyThread_exit_thread
PyUnicode_SetDefaultEncoding

And the following were added to 3.2,
of which only 2 are documented:

PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc    (documented)
PyErr_SyntaxLocationEx
PyErr_WarnFormat
PyFrame_GetLineNumber
PyImport_ExecCodeModuleWithPathnames
PyImport_GetMagicTag
PyLong_AsLongLongAndOverflow    (documented)
PyModule_GetFilenameObject
Py_SetPath
PyStructSequence_GetItem
PyStructSequence_NewType
PyStructSequence_SetItem
PySys_AddWarnOptionUnicode
PySys_AddXOption
PySys_FormatStderr
PySys_FormatStdout
PySys_GetXOptions
PyThread_acquire_lock_timed
PyType_FromSpec
PyUnicode_AsUnicodeCopy
PyUnicode_AsWideCharString
PyUnicode_EncodeFSDefault
PyUnicode_FSDecoder
Py_UNICODE_strcat
Py_UNICODE_strncmp
Py_UNICODE_strrchr
PyUnicode_TransformDecimalToASCII

For added confusion PySys_SetArgvEx is documented as
new in 3.2, but exists in 3.1.3

Note that this only include functions.
The API also includes a number of macros such as
Py_False and Py_RETURN_FALSE, types ,
and data like PyBool_Type.

----------
assignee: docs at python
components: Documentation
messages: 128294
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Undocumented public APIs in Python 3.2
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 16:45:53 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:45:53 +0000
Subject: [New-bugs-announce] [issue11174] add argparse formatting option to
	display type names for	metavar
In-Reply-To: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>
Message-ID: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

I generally like my command line arguments that take a
value to specify the type, e.g.,

   --runs int      how many runs to do

Naturally I can do this using the metavars argument in every
add_argument() call, but that can become tedious. So I suggest adding a
metavars argument to the ArgumentParser constructor; default
metavars=None (current behaviour); metavars=type (show type names). And
of course, allow metavars specified in add_argument() calls to override
on a case by case basis.

----------
components: Library (Lib)
messages: 128300
nosy: bethard
priority: low
severity: normal
stage: needs patch
status: open
title: add argparse formatting option to display type names for metavar
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 16:47:13 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:47:13 +0000
Subject: [New-bugs-announce] [issue11175] allow argparse FileType to accept
	encoding and errors	arguments
In-Reply-To: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>
Message-ID: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

Allow FileType to accept encoding and errors arguments
and pass these as keyword arguments to codecs.open() instead of open().

----------
components: Library (Lib)
messages: 128301
nosy: bethard
priority: low
severity: normal
stage: needs patch
status: open
title: allow argparse FileType to accept encoding and errors arguments
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 16:48:57 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:48:57 +0000
Subject: [New-bugs-announce] [issue11176] give more meaningful argument
	names in argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

I personally am not keen on the foo/bar/baz examples. I
know that you're trying to be generic but IMO it would be much easier to
understand if you used meaningful names. Also, I think that the very
first example you give (which does use meaningful names:-) is too
clever. I'd suggest using something simpler: in fact I'd use exactly the
same example that optparse uses (--file && --quiet) since that is easy
to understand and relate to straight away, and maybe add a --line option
that takes a list of ints (ostensibly line numbers of lines to extract
from the file) if you want to show that argparse leaves optparse in the
dust. And you can always show how to get actual file objects later on.

----------
assignee: docs at python
components: Documentation
messages: 128302
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: give more meaningful argument names in argparse documentation
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 19:33:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 10 Feb 2011 18:33:44 +0000
Subject: [New-bugs-announce] [issue11177] Set asyncore create_socket default
	argument
In-Reply-To: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>
Message-ID: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

At the current state asyncore implicitly supports TCP (SOCK_STREAM) sockets only, despite UDP support might be added in the future.
For simplicity, create_socket() should assume TCP/IP by default.
This would avoid the user to "import socket" and specify the two constants every time, which is annoying.

----------
files: asyncore_create_socket.patch
keywords: patch
messages: 128327
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Set asyncore create_socket default argument
versions: Python 3.3
Added file: http://bugs.python.org/file20735/asyncore_create_socket.patch

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

From report at bugs.python.org  Thu Feb 10 21:19:08 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 10 Feb 2011 20:19:08 +0000
Subject: [New-bugs-announce] [issue11178] Running tests inside a package by
	module name fails
In-Reply-To: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>
Message-ID: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>


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

Reported by a user and verified by me with both Python 2.7 and 3.2.

Trying to run tests by module or package name seems to fail.

directory structure:

    project root: C:\Users\hpierson\Projects\pytest
        \test
            __init__.py (empty)
            testfoo.py (sample test file

running test package by name - no tests discovered

C:\Users\hpierson\Projects\pytest
PS? cpy C:\Python31\Scripts\unit2.py test

----------------------------------------------------------------------
Ran 0 tests in 0.000s

 

running test module by name - can't find module

C:\Users\hpierson\Projects\pytest
PS? cpy C:\Python31\Scripts\unit2.py test.testfoo
Traceback (most recent call last):
  File "C:\Python31\Scripts\unit2.py", line 7, in <module>
    main_()
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 237, in main_
    main(module=None)
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 94, in __init__
    self.parseArgs(argv)
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 149, in parseArgs
    self.createTests()
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 158, in createTests
    self.module)
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 133, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 133, in <listcomp>
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 101, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'testfoo'

----------
assignee: michael.foord
components: Library (Lib)
messages: 128337
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Running tests inside a package by module name fails
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Feb 11 01:11:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 00:11:43 +0000
Subject: [New-bugs-announce] [issue11179] ccbench doesn't work on 3.1/2.7
In-Reply-To: <1297383103.21.0.0381281186819.issue11179@psf.upfronthosting.co.za>
Message-ID: <1297383103.21.0.0381281186819.issue11179@psf.upfronthosting.co.za>


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

The ccbench shipped with 3.2 is supposed to work with older versions but:

Traceback (most recent call last):
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 609, in <module>
    main()
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 564, in main
    latency_client(**kwargs)
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 279, in latency_client
    with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
AttributeError: 'socket' object has no attribute '__exit__'

----------
assignee: pitrou
components: Demos and Tools
messages: 128353
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ccbench doesn't work on 3.1/2.7
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb 11 02:15:56 2011
From: report at bugs.python.org (newacct)
Date: Fri, 11 Feb 2011 01:15:56 +0000
Subject: [New-bugs-announce] [issue11180] More efficient
	nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>


New submission from newacct <spoon.reloaded at gmail.com>:

heapq.nlargest()/nsmallest() currently use a size-k heap to get the k largest/smallest items. This takes O(n log k): heapifying the first k elements (O(k)); iterating through (n-k) elements of the list, each insertion/deletion takes O(log k), for O((n-k)log k); and then sorting the elements at the end for O(k log k).

There are several more efficient ways to do this:

1) O(n + k log n): Put the entire list into the heap at once. This takes O(n). Then we can take out the k largest / smallest from the heap in sorted order, each taking O(log n), for a total of O(n + k log n), which is much better than O(n log k) if k is small and n is big. Unfortunately, this takes a lot (O(n)) of memory.

2) O(n + k log k): Use the linear time (O(n)) selection algorithm to find out what the k'th largest/smallest element is. (http://en.wikipedia.org/wiki/Selection_algorithm#Linear_general_selection_algorithm_-_Median_of_Medians_algorithm) Then, partition (a la Quicksort) the elements into the ones bigger and smaller than this; this is also O(n). Maybe the partitioning can happen as part of the selection algorithm. At the end, sort the k elements, for O(k log k). If we remove the requirement that the result has to be sorted, then this algorithm is just O(n).

----------
messages: 128357
nosy: newacct
priority: normal
severity: normal
status: open
title: More efficient nlargest()/nsmallest()
type: performance

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

From report at bugs.python.org  Fri Feb 11 03:47:00 2011
From: report at bugs.python.org (Adi Roiban)
Date: Fri, 11 Feb 2011 02:47:00 +0000
Subject: [New-bugs-announce] [issue11181] TLS end connection not detected
	properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>


New submission from Adi Roiban <adi at roiban.ro>:

FTP_TLS.retrybinary should detect the end of a TLS read in the same way as FTP.TLS_retryline does.

it should be something like this... catching ssl.ZeroReturnError as a valid expection for signaling EOF.

                    try:
                        data = conn.recv(blocksize)
                    except ssl.ZeroReturnError:
                        # pyOpenSSL does not return 0, but rather
                        # SSL.ZeroReturnError
                        pass
                    if not data:
                        break
                    callback(data)

----------
components: Library (Lib)
messages: 128360
nosy: adiroiban
priority: normal
severity: normal
status: open
title: TLS end connection not detected properly in retrbinary
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb 11 07:29:15 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 11 Feb 2011 06:29:15 +0000
Subject: [New-bugs-announce] [issue11182] pydoc.Scanner class not used by
	anything
In-Reply-To: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>
Message-ID: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>


New submission from Ron Adam <ron_adam at users.sourceforge.net>:

There doesn't seem to be any references to it in any other part of pydoc, or the Library for that matter.  Searching for it on google code search (and also google web search) only turns up auto generated API references for python editing tools like VIM, and of course it's existence in pydoc itself.

This doesn't appear to be related to the ModuleScanner class in any way other than possibly being a bit of left over example code.

Can it be removed?

----------
components: Library (Lib)
messages: 128365
nosy: ron_adam
priority: normal
severity: normal
status: open
title: pydoc.Scanner class not used by anything
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 11 11:08:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 10:08:30 +0000
Subject: [New-bugs-announce] [issue11183] Finer-grained exceptions for the
	ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>


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

pyOpenSSL (*) has the good idea of defining exception subclasses for the various OpenSSL error codes (ZeroReturnError, WantReadError, etc.). The ssl module could do the same.

(*) http://packages.python.org/pyOpenSSL/openssl-ssl.html

----------
components: Library (Lib)
messages: 128370
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Finer-grained exceptions for the ssl module
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 11 12:37:52 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 11:37:52 +0000
Subject: [New-bugs-announce] [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I get 2 errors when running test_io.py with trunk on AIX. 

======================================================================
ERROR: test_large_file_ops (__main__.CIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
OverflowError: Python int too large to convert to C long

======================================================================
ERROR: test_large_file_ops (__main__.PyIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
OverflowError: Python int too large to convert to C long

----------------------------------------------------------------------
Ran 395 tests in 27.958s

FAILED (errors=2, skipped=8)

thanks in advance

----------
components: IO
messages: 128374
nosy: sable
priority: normal
severity: normal
status: open
title: test_io error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 12:40:02 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 11:40:02 +0000
Subject: [New-bugs-announce] [issue11185] test_wait4 error on AIX
In-Reply-To: <1297424402.38.0.348928652961.issue11185@psf.upfronthosting.co.za>
Message-ID: <1297424402.38.0.348928652961.issue11185@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I get an error when running test_wait4 with trunk on AIX:

test_wait (__main__.Wait4Test) ... FAIL

======================================================================
FAIL: test_wait (__main__.Wait4Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "./Lib/test/test_wait4.py", line 23, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 0 != 1486954

----------------------------------------------------------------------
Ran 1 test in 12.030s

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_wait4.py", line 32, in <module>
    test_main()
  File "./Lib/test/test_wait4.py", line 28, in test_main
    run_unittest(Wait4Test)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "./Lib/test/test_wait4.py", line 23, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 0 != 1486954

Thanks in advance

----------
messages: 128375
nosy: sable
priority: normal
severity: normal
status: open
title: test_wait4 error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 13:55:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 12:55:09 +0000
Subject: [New-bugs-announce] [issue11186] pydoc: HTMLDoc.index() doesn't
	support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>


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

If you have an undecodable filenames on UNIX, Python 3 escapes undecodable bytes using surrogates. pydoc: HTMLDoc.index() uses indirectly os.listdir() which does such operation, and later filenames are encoded to UTF-8 (the whole HTML content is encoded to UTF-8).

In practice, you cannot import such .py file, you run them using "python script.py", so we can maybe just ignore modules with undecodable filenames. For example:

def isUndecodableFilename(filename):
  return any((0xD800 <= ord(ch) <= 0xDFFF) for ch in filename)

Or we can escape the surrogate characters, but I don't know how. Write "\uDC80" in a HTML document is not a good idea, especially in an URL (e.g. Firefox replaces \ by / in URLs).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 128382
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: pydoc: HTMLDoc.index() doesn't support PEP 383
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb 11 14:04:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 13:04:11 +0000
Subject: [New-bugs-announce] [issue11187] PyUnicode_AsEncodedString: the
	bootstrap hack is no more	needed
In-Reply-To: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>
Message-ID: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>


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

Since version 3.2, Python uses the locale encoding in PyUnicode_EncodeFSDefault() using _Py_wchar2char() and _Py_char2wchar() until the codec registry is initialized and the locale codec is loaded (until initfsencoding() is done).

Before Python 3.2, Python used ASCII in PyUnicode_AsEncodedString() at bootstrap  (before the codec registry was initialized): we don't need this hack anymore and it is bad to use ASCII instead of the locale encoding (encode/decode can fail).

This ticket is just a reminder for me: I am waiting Python 3.3 to remove PyUnicode_AsEncodedString() bootstrap hack ;-)

----------
components: Interpreter Core
files: unicode_asencodedstring_bootstrap.patch
keywords: patch
messages: 128384
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_AsEncodedString: the bootstrap hack is no more needed
versions: Python 3.3
Added file: http://bugs.python.org/file20744/unicode_asencodedstring_bootstrap.patch

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

From report at bugs.python.org  Fri Feb 11 15:51:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:51:10 +0000
Subject: [New-bugs-announce] [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following errors on test_time on AIX:

======================================================================
ERROR: test_mktime (test.test_time.TestAsctime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (test.test_time.Test4dyearBool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
FAIL: test_negative (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 337, in test_negative
    self.assertIn(text, ('-1', '-001'))
AssertionError: '000/' not found in ('-1', '-001')

----------------------------------------------------------------------
Ran 42 tests in 1.217s

FAILED (failures=1, errors=3)

Haven't investigated yet.

----------
messages: 128396
nosy: sable
priority: normal
severity: normal
status: open
title: test_time error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 15:57:25 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:57:25 +0000
Subject: [New-bugs-announce] [issue11189] test_resource error on AIX
In-Reply-To: <1297436245.22.0.679544403008.issue11189@psf.upfronthosting.co.za>
Message-ID: <1297436245.22.0.679544403008.issue11189@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error on test_resource on AIX:

test_resource
test test_resource failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_resource.py", line 28, in test_fsize_ismax
    self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 2147483647 != 1073741312

I haven't investigated yet.

----------
messages: 128397
nosy: sable
priority: normal
severity: normal
status: open
title: test_resource error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 15:59:01 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:59:01 +0000
Subject: [New-bugs-announce] [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following errors on test_locale on AIX:

======================================================================
FAIL: test_strcoll_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_locale.py", line 364, in test_strcoll_with_diacritic
    self.assertLess(locale.strcoll('?', 'b'), 0)
AssertionError: 1 not less than 0

======================================================================
FAIL: test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_locale.py", line 367, in test_strxfrm_with_diacritic
    self.assertLess(locale.strxfrm('?'), locale.strxfrm('b'))
AssertionError: '\u01e2\u0100' not less than '\u0164\u0100'

----------------------------------------------------------------------
Ran 35 tests in 0.020s

FAILED (failures=2)

I haven't investigated yet.

----------
messages: 128398
nosy: sable
priority: normal
severity: normal
status: open
title: test_locale error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 16:02:16 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:02:16 +0000
Subject: [New-bugs-announce] [issue11191] test_search_cpp error on AIX (aith
	xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error in distutils on AIX.

======================================================================
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/unixccompiler.py", line 166, in preprocess
    self.spawn(pp_args)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/ccompiler.py", line 911, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'xlc' failed with exit status 40

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/tests/test_config_cmd.py", line 47, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='// xxx')
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/command/config.py", line 203, in search_cpp
    src, out = self._preprocess(body, headers, include_dirs, lang)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/command/config.py", line 126, in _preprocess
    self.compiler.preprocess(src, out, include_dirs=include_dirs)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/unixccompiler.py", line 168, in preprocess
    raise CompileError(msg)
distutils.errors.CompileError: command 'xlc' failed with exit status 40

I haven't investigated yet.

----------
assignee: tarek
components: Distutils
messages: 128399
nosy: eric.araujo, sable, tarek
priority: normal
severity: normal
status: open
title: test_search_cpp error on AIX (aith xlc)
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 16:05:51 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:05:51 +0000
Subject: [New-bugs-announce] [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error in test_socket on AIX:

======================================================================
FAIL: testGetaddrinfo (__main__.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 640, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 0 != 1

----------------------------------------------------------------------
Ran 158 tests in 16.904s

FAILED (failures=1, skipped=4)
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 2012, in <module>
    test_main()
  File "./Lib/test/test_socket.py", line 2008, in test_main
    support.run_unittest(*tests)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 640, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 0 != 1

[119732 refs]

I haven't investigated yet.

----------
messages: 128400
nosy: sable
priority: normal
severity: normal
status: open
title: test_socket error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 16:28:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:28:21 +0000
Subject: [New-bugs-announce] [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

The following tests fail in test_subprocess on AIX:

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_subprocess.py", line 1039, in test_undecodable_env
    self.assertEqual(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


======================================================================
FAIL: test_undecodable_env (test.test_subprocess.ProcessTestCasePOSIXPurePython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_subprocess.py", line 1039, in test_undecodable_env
    self.assertEqual(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


----------------------------------------------------------------------
Ran 267 tests in 366.280s

FAILED (failures=2, skipped=22)

I haven't investigated yet.

----------
messages: 128402
nosy: sable
priority: normal
severity: normal
status: open
title: test_subprocess error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 11 18:40:58 2011
From: report at bugs.python.org (O.C.)
Date: Fri, 11 Feb 2011 17:40:58 +0000
Subject: [New-bugs-announce] [issue11194] "lock.__exit__ == lock.release"
	should be False
In-Reply-To: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>
Message-ID: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>


New submission from O.C. <oc-spam66 at laposte.net>:

Hello,

if 'lock' is a threading.Lock, the functions lock.__exit__() and lock.release() are different. The former takes 3 arguments, while the latter takes no argument. However, "lock.__exit__ == lock.release" returns True. Shouldn't it return False ?

Best regards,

O.C.

Details:
In [20]: lock=threading.Lock()
In [21]: lock.acquire()
In [22]: lock.__exit__(None,None,None)
In [23]: lock.locked()
Out[23]: False
In [24]: lock.acquire()
In [25]: lock.release(None,None,None)
TypeError: release() takes no arguments (3 given)
In [26]: lock.__exit__==lock.release
Out[26]: True

----------
components: Library (Lib)
messages: 128409
nosy: dghjfrdj
priority: normal
severity: normal
status: open
title: "lock.__exit__ == lock.release" should be False
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Feb 11 19:01:57 2011
From: report at bugs.python.org (Daniele Varrazzo)
Date: Fri, 11 Feb 2011 18:01:57 +0000
Subject: [New-bugs-announce] [issue11195] next fixer fooled by trailing
	cheracters
In-Reply-To: <1297447317.1.0.237374543357.issue11195@psf.upfronthosting.co.za>
Message-ID: <1297447317.1.0.237374543357.issue11195@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo <piro at develer.com>:

An expression such as "x = i.next()[0]" is not fixed by 2to3 in Python 3.1. "x = (i.next())[0]" works instead.

https://github.com/dvarrazzo/psycopg/commit/9e9c22163706b0fffb9da67fe50ea23f91fe1c72

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128412
nosy: piro
priority: normal
severity: normal
status: open
title: next fixer fooled by trailing cheracters
versions: Python 3.1

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

From report at bugs.python.org  Fri Feb 11 19:31:23 2011
From: report at bugs.python.org (Geza)
Date: Fri, 11 Feb 2011 18:31:23 +0000
Subject: [New-bugs-announce] [issue11196] add possibility for returning
	value the way Matlab does	it
In-Reply-To: <1297449083.34.0.083242555251.issue11196@psf.upfronthosting.co.za>
Message-ID: <1297449083.34.0.083242555251.issue11196@psf.upfronthosting.co.za>


New submission from Geza <kgeza7 at gmail.com>:

It would be nice if you could write a function like this (besides, of course, the current way):

def result=functionname(params):
  ...
  result=something

It would suffice for most functions, since you usually always return one type of value, and it can be very convenient in certain cases.
This is the way it is done e.g. in Matlab.

Advantages: 
- You can easily see what the function returns (e.g. by writing a tuple as the return value), without having to read the function body, or without hoping to find it in the comments.
- You can initialize the return values, and then care about the cases where they change.
- If you change the setup of the return value (e.g. insert a new item into the tuple), you do not need to change the "return" statement at possibly several places in the function body.

Disadvantages:
- I suggest it as an addition, so there isn't really. One person may decide to use one way, one the other.
- Of course, if you mix using the two ways, you may need to look at the function header to see which one you used.

Some more details to the idea:
- The return values are initialized to None.
- You can use the "return" statement just as before, but without arguments, to return from anywhere in the code.
- If you specify arguments to the "return" statement, Python stops with an exception.

The idea at this stage of Python development may be surprising, but I hope that nevertheless you will consider the idea seriously.

Thanks, and best regard!

----------
components: Interpreter Core
messages: 128416
nosy: Geza
priority: normal
severity: normal
status: open
title: add possibility for returning value the way Matlab does it
type: feature request

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

From report at bugs.python.org  Fri Feb 11 19:46:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Feb 2011 18:46:11 +0000
Subject: [New-bugs-announce] [issue11197] information leakage with
	SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

As reported to the PSRT:

Python's SimpleHTTPServer class is a simple HTTP server, documented as
serving up the content of the pwd and below readonly via GET and HEAD
commands:

 $ python -m SimpleHTTPServer
 Serving HTTP on 0.0.0.0 port 8000 ...

However, by inserting "../" path fragments within the path section of
the URL, it's possible to traverse other directories within the
filesystem.

For example:

 lynx localhost:8000/../../../../..

shows 5 directories above in the directory structure.

I was also able to browse /proc and /sys on this example using:

 lynx localhost:8000/../../../../../../../../proc
 lynx localhost:8000/../../../../../../../../sys

(by browsing to find the correct number of ".." entries to locate the
root directory); arguable this could be leaking much more information
about the host than the administrator might be expecting (e.g. other
programs being executed on the host, command-line arguments of those
programs etc)

This has been fixed in CGIHTTPServer; see
 http://bugs.python.org/issue2254
and:
 http://svn.python.org/view?view=rev&revision=71303

Guido recommended to not make this secret since no one should be using SimpleHTTPServer in production. He also said this should get fixed.

----------
components: Library (Lib)
messages: 128420
nosy: barry, benjamin.peterson, brett.cannon, dmalcolm, georg.brandl, gps
priority: release blocker
severity: normal
stage: needs patch
status: open
title: information leakage with SimpleHTTPServer
type: security
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb 11 20:29:07 2011
From: report at bugs.python.org (muxum)
Date: Fri, 11 Feb 2011 19:29:07 +0000
Subject: [New-bugs-announce] [issue11198] re sub subn backreferrence too few
	replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>


New submission from muxum <mxgnone at gmx.de>:

#download/try this: http://ideone.com/QA6Fg

from re import *
 
s = 'a->b\na->b\nc->b\nc->b\na->d\na->d\ne->b\ne->b\na->f\na->f\ng->b\ng->b\na->h\na->h\ni->b\ni->b\na->j\na->j\nk->b\nk->b\n'
res = subn(r"(.*\n)(\1)+",r"replaced:\1",s,M)
 
print("output: " + res[0])
print("replace count: %d" % res[1])
 
# if it works right the next print wont show
if res[1] == 8: print("WEIRD: too few replacements ("+str(res[1])+")")

#i'd expect this to replace all ocurrences not only the first 8 times

----------
components: Regular Expressions
messages: 128422
nosy: muxum
priority: normal
severity: normal
status: open
title: re sub subn backreferrence too few replacements
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Feb 12 14:00:05 2011
From: report at bugs.python.org (rg3)
Date: Sat, 12 Feb 2011 13:00:05 +0000
Subject: [New-bugs-announce] [issue11199] urllib hangs when closing
	connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>


New submission from rg3 <sarbalap+freshmeat at gmail.com>:

If you run the attached program, you can see the program hangs in the connection close stage. Uncommenting the sleep line makes the program work, so I suspect some kind of race condition.

The URL used belongs to a Slackware Linux mirror. I have not been able to reproduce this problem when using a different FTP mirror or using HTTP mirrors. 

The remote server seems to be using pure-ftpd. I have built the software and tested on localhost, but I could not reproduce the problem either.

----------
components: Extension Modules
files: test.py
messages: 128444
nosy: rg3
priority: normal
severity: normal
status: open
title: urllib hangs when closing connection
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20750/test.py

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

From report at bugs.python.org  Sat Feb 12 19:28:07 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sat, 12 Feb 2011 18:28:07 +0000
Subject: [New-bugs-announce] [issue11200] Addition of abiflags breaks
	distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

When trying to build distribute on the latest python-3.2rc I get the following traceback in the unittests (two others that are similar as well):

======================================================================
ERROR: test_develop (setuptools.tests.test_develop.TestDevelopTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.2/distutils/util.py", line 283, in subst_vars
    return re.sub(r'\$([a-zA-Z_][a-zA-Z_0-9]*)', _subst, s)
  File "/usr/lib/python3.2/re.py", line 167, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/usr/lib/python3.2/distutils/util.py", line 280, in _subst
    return os.environ[var_name]
  File "/usr/lib/python3.2/os.py", line 450, in __getitem__
    value = self._data[self.encodekey(key)]
KeyError: b'abiflags'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "build/src/setuptools/tests/test_develop.py", line 52, in test_develop
    cmd.ensure_finalized()
  File "/usr/lib/python3.2/distutils/cmd.py", line 109, in ensure_finalized
    self.finalize_options()
  File "build/src/setuptools/command/develop.py", line 51, in finalize_options
    easy_install.finalize_options(self)
  File "build/src/setuptools/command/easy_install.py", line 225, in finalize_options
    self.expand_dirs()
  File "build/src/setuptools/command/easy_install.py", line 335, in expand_dirs
    'install_scripts', 'install_data',])
  File "build/src/setuptools/command/easy_install.py", line 323, in _expand_attrs
    val = subst_vars(val, self.config_vars)
  File "/usr/lib/python3.2/distutils/util.py", line 285, in subst_vars
    raise ValueError("invalid variable '$%s'" % var)
ValueError: invalid variable '$b'abiflags''

It seems that something in the addition of abiflags is causing distutils to search for abiflags in os.environ.  After talking with tarek on IRC we decided to open a bug here to see whether this is desirable change in behaviour within the stdlib.

The revision introducing abiflags is here: http://svn.python.org/view?view=rev&revision=85697

----------
components: Library (Lib)
messages: 128448
nosy: a.badger, barry, doko, tarek
priority: normal
severity: normal
status: open
title: Addition of abiflags breaks distutils
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 12 19:47:18 2011
From: report at bugs.python.org (Ana Koren)
Date: Sat, 12 Feb 2011 18:47:18 +0000
Subject: [New-bugs-announce] [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>


New submission from Ana Koren <ana.koren at gmail.com>:

I'm running Windows 7 (32-bit) and I downloaded Python 2.7.1 Windows Installer but I can't install it. I get this message:
"The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2203."

----------
messages: 128449
nosy: corenova
priority: normal
severity: normal
status: open
title: Python installation error 2203
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 12 19:54:56 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 18:54:56 +0000
Subject: [New-bugs-announce] [issue11202] Win32: shutil.move does not
	inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>


New submission from Anders ?sthus <grapz666 at gmail.com>:

Hi

I'm running Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32 (Server 2008 R2).

I've discovered that when moving files with shutil.move, the file won't inherit the security settings as it should.

When using shutil.copy, it does get the right permissions.

----------
components: IO
messages: 128452
nosy: Anders.?sthus
priority: normal
severity: normal
status: open
title: Win32: shutil.move does not inherit permissions
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 12 20:40:32 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Sat, 12 Feb 2011 19:40:32 +0000
Subject: [New-bugs-announce] [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>


New submission from K Richard Pixley <rich at noir.com>:

The documentation for gzip should include the "close" method.

It's use in the 2.7 documentation implies it's existence but it should also be stated explicitly that it exists.

In the 3.x documentation, the use of "close" not in the examples since the examples use context manager.  For 3.x documentation there should be both an explicit mention of the "close" method as well as an explicit mention that GzipFile supports the context manager protocol.

Yes, the use of the context manager in the examples implies that this is true but documentation on other modules states so explicitly so this module should too.

----------
assignee: docs at python
components: Documentation
messages: 128460
nosy: docs at python, teamnoir
priority: normal
severity: normal
status: open
title: gzip doc is behind
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Feb 13 00:19:58 2011
From: report at bugs.python.org (John Machin)
Date: Sat, 12 Feb 2011 23:19:58 +0000
Subject: [New-bugs-announce] [issue11204] re module: strange behaviour of
	space inside {m, n}
In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>
Message-ID: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at lexicon.net>:

A pattern like r"b{1,3}\Z" matches "b", "bb", and "bbb", as expected. There is no documentation of the behaviour of r"b{1, 3}\Z" -- it matches the LITERAL TEXT "b{1, 3}" in normal mode and "b{1,3}" in verbose mode.

# paste the following at the interactive prompt:
pat = r"b{1, 3}\Z"
bool(re.match(pat, "bb")) # False
bool(re.match(pat, "b{1, 3}")) # True
bool(re.match(pat, "bb", re.VERBOSE)) # False
bool(re.match(pat, "b{1, 3}", re.VERBOSE)) # False
bool(re.match(pat, "b{1,3}", re.VERBOSE)) # True

Suggested change, in decreasing order of preference:
(1) Ignore leading/trailing spaces when parsing the m and n components of {m,n}
(2) Raise an exception if the exact syntax is not followed
(3) Document the existing behaviour

Note: deliberately matching the literal text would be expected to be done by escaping the left brace:

pat2 = r"b\{1, 3}\Z"
bool(re.match(pat2, "b{1, 3}")) # True

and this is not prevented by the suggested changes.

----------
messages: 128472
nosy: sjmachin
priority: normal
severity: normal
status: open
title: re module: strange behaviour of space inside {m, n}
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Feb 13 10:39:13 2011
From: report at bugs.python.org (takayuki)
Date: Sun, 13 Feb 2011 09:39:13 +0000
Subject: [New-bugs-announce] [issue11205] Evaluation order of dictionary
	display is different from	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>


New submission from takayuki <takayuki988 at star.odn.ne.jp>:

Running the following code shows "2 1 4 3", but in reference manual
http://docs.python.org/reference/expressions.html#expression-lists
the evaluation order described as
{expr1: expr2, expr3: expr4}

def f(i):
    print i
    return i

{f(1):f(2), f(3):f(4)}

I found some of past discussions about this problem, for example,
http://mail.python.org/pipermail/python-dev/2002-November/030461.html
http://mail.python.org/pipermail/python-dev/2002-November/030458.html
http://bugs.python.org/issue448679
http://svn.python.org/view?view=rev&revision=30148
, but current implementation seems not to reflect these accomplishment.

In present, which behaviour is legal?

----------
components: None
messages: 128482
nosy: takayuki
priority: normal
severity: normal
status: open
title: Evaluation order of dictionary display is different from reference manual.
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb 13 11:26:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Feb 2011 10:26:38 +0000
Subject: [New-bugs-announce] [issue11206] test_readline unconditionally
	calls clear_history()
In-Reply-To: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>
Message-ID: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This function apparently is not available in all readline versions; e.g. the GNU readline 5.2 currently installed on dinsdale.

This can be fixed (together with the unconditional reliance of test_distutils and test_zipfile on zlib) after 3.2 final.

----------
components: Tests
messages: 128485
nosy: georg.brandl
priority: high
severity: normal
stage: needs patch
status: open
title: test_readline unconditionally calls clear_history()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Feb 13 22:56:03 2011
From: report at bugs.python.org (David Knapp)
Date: Sun, 13 Feb 2011 21:56:03 +0000
Subject: [New-bugs-announce] [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>


New submission from David Knapp <psychicsurgeon at gmail.com>:

Python had a seg fault with the following simple code.

>>> import PIL.Image as Img
>>> import numpy as np
>>> i = Img.open('/home/falmarri/Dropbox/obey.jpg')
>>> n = np.array(bytearray(i.tostring()),dtype=np.uint16)
zsh: segmentation fault  python

Running it under gdb gave the following

(gdb) run g19_framebuffer.py
Starting program: /usr/bin/python g19_framebuffer.py
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
_unaligned_strided_byte_copy (dst=0xcb9543 "\366\377\177", outstrides=1, src=0x7ffff3503da5 <Address 0x7ffff3503da5 out of bounds>, 
    instrides=4969607, N=10000, elsize=<value optimized out>) at /usr/include/bits/string3.h:52
warning: Source file is more recent than executable.
52        return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));


It could be that I'm doing it wrong though.

----------
messages: 128523
nosy: David.Knapp
priority: normal
severity: normal
status: open
title: Pythong seg fault with PIL/numpy
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 14 00:04:56 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 13 Feb 2011 23:04:56 +0000
Subject: [New-bugs-announce] [issue11208] example misprint in documentation
	whatsnew/3.2
In-Reply-To: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>
Message-ID: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

>>> list(accumulate(8, 2, 50))

fails. Correct version is

>>> list(accumulate([8, 2, 50]))

----------
assignee: docs at python
components: Documentation
files: whatsnew.3.2.accumulate.example.diff
keywords: patch
messages: 128529
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: example misprint in documentation whatsnew/3.2
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20757/whatsnew.3.2.accumulate.example.diff

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

From report at bugs.python.org  Mon Feb 14 06:17:50 2011
From: report at bugs.python.org (Johannes Ammon)
Date: Mon, 14 Feb 2011 05:17:50 +0000
Subject: [New-bugs-announce] [issue11209] Example for itertools.count is
	misleading
In-Reply-To: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>
Message-ID: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>


New submission from Johannes Ammon <johannes.ammon at gmail.com>:

The example code for itertools.count (http://docs.python.org/library/itertools.html#itertools.count) says 

    # count(2.5, 0.5) -> 3.5 3.0 4.5 ...

I think that should read

    # count(2.5, 0.5) -> 2.5 3.0 3.5 ...

----------
assignee: docs at python
components: Documentation
messages: 128533
nosy: docs at python, jammon
priority: normal
severity: normal
status: open
title: Example for itertools.count is misleading
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 14 11:15:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 10:15:21 +0000
Subject: [New-bugs-announce] [issue11210]
	PyErr_SetFromWindowsErrWithFilenameObject() doesn't	exist:
	remove it from pyerrors.h
In-Reply-To: <1297678521.8.0.172330383513.issue11210@psf.upfronthosting.co.za>
Message-ID: <1297678521.8.0.172330383513.issue11210@psf.upfronthosting.co.za>


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

PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithFilenameObject(int, const char *); has a strange prototype: "FilenameObject" usually indicates a PyObject* argument, not a char* argument. The function doesn't exist in Python/errors.c, but there is a PyErr_SetExcFromWindowsErrWithFilenameObject() function.

PyErr_SetFromWindowsErrWithFilenameObject() was introduced in pyerrors.h by r28999 (8 years ago), but I am unable to find any concrete implementation.


Attached patch removes PyErr_SetFromWindowsErrWithFilenameObject() from pyerrors.h.

----------
components: Interpreter Core, Unicode
files: pyerrors_h.patch
keywords: easy, patch
messages: 128536
nosy: haypo
priority: normal
severity: normal
status: open
title: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: remove it from pyerrors.h
versions: Python 3.3
Added file: http://bugs.python.org/file20759/pyerrors_h.patch

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

From report at bugs.python.org  Mon Feb 14 16:08:19 2011
From: report at bugs.python.org (Toni Mueller)
Date: Mon, 14 Feb 2011 15:08:19 +0000
Subject: [New-bugs-announce] [issue11211] gzip.open() fails for gzipped file
In-Reply-To: <1297696099.3.0.962769507979.issue11211@psf.upfronthosting.co.za>
Message-ID: <1297696099.3.0.962769507979.issue11211@psf.upfronthosting.co.za>


New submission from Toni Mueller <tonimueller at users.sourceforge.net>:

I have files that I would like to read with Python, but can't:

$ python jmlreader.py woerter-allg.jml
Traceback (most recent call last):
  File "jmlreader.py", line 14, in <module>
    readFile(sys.argv[1])
  File "jmlreader.py", line 10, in readFile
    for line in f:
  File "/usr/lib/python2.6/gzip.py", line 438, in next
    line = self.readline()
  File "/usr/lib/python2.6/gzip.py", line 393, in readline
    c = self.read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 219, in read
    self._read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 255, in _read
    self._read_gzip_header()
  File "/usr/lib/python2.6/gzip.py", line 156, in _read_gzip_header
    raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file

The file itself is a gzipped file, though: 

$ gzip -cd woerter-allg.jml|head
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Lesson>
<Category name="All">
<Deck>
<Card AmountLearnedBack="0" AmountLearnedFront="0" Backside="yu3 yan2  (zhong3)&#10;&#10;Sprache" DateCreated="02-Mar-2009 16:05:15" DateModified="02-Mar-2009 16:05:15" DateTouched="02-Mar-2009 16:05:15" Frontside="?????" TestsHit="0" TestsTotal="0">
<Side/>
<Side/>
</Card>
<Card AmountLearnedBack="0" AmountLearnedFront="0" Backside="shu4&#10;&#10;Baum, pflanzen, hervorbringen" DateCreated="02-Mar-2009 16:06:26" DateModified="02-Mar-2009 16:06:49" DateTouched="02-Mar-2009 16:06:26" Frontside=" ?" TestsHit="0" TestsTotal="0">
<Side/>

Unfortunately, the file is a bit weird:

$ file woerter-allg.jml
woerter-allg.jml: Zip archive data, at least v2.0 to extract

Rewriting the program with zlib, instead of gzip, didn't help a bit:

$ python jmlreader.py woerter-allg.jml.gz 
Traceback (most recent call last):
  File "jmlreader.py", line 15, in <module>
    readFile(sys.argv[1])
  File "jmlreader.py", line 11, in readFile
    unc = zlib.decompress(s)
zlib.error: Error -3 while decompressing data: incorrect header check


IOW, the file was actually compressed with gzip, not zip.

It would be nice if the gzip module could read the file. I've attached a file that reproduces the problem.

----------
components: Extension Modules
files: test.jml
messages: 128550
nosy: tonimueller
priority: normal
severity: normal
status: open
title: gzip.open() fails for gzipped file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20760/test.jml

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

From report at bugs.python.org  Mon Feb 14 16:31:15 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 15:31:15 +0000
Subject: [New-bugs-announce] [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

On AIX, executables are compiled by default so that they cannot allocate more than 256MB of memory.

This is not enough in some cases; for example this is not enough to get the Python test suite to run completely.

As explained in IBM documentation:

By default each program gets one segment register (see 2.24) for its
data segment. As each segment register covers 256 MB, any calls to
malloc more will fail. Also programs that declare large global or static
arrays may fail to load. To allocate more segment registers to your
program, use the linker option -bmaxdata to specify the number of bytes
you need in the data segment as follows:

cc -o myprog -bmaxdata:0x20000000 myprog.c

The example above would allocate an additional segment register to allow
for 512MB of data.

export LDR_CNTRL=MAXDATA=0x20000000
start_process
unset LDR_CNTRL

Marking An Executable For Large Page Use
The XCOFF header in an executable file contains a new flag to indicate that the program wants to use
large pages to back its data and heap segments. This flag can be set when the application is linked by
specifying the -blpdata option on the ld command. The flag can also be set or cleared using the ldedit
command. The "ldedit -blpdata filename" command sets the large page data/heap flag in the specified
file. The "ldedit -bnolpdata filename" clears the large page flag. The ldedit command may also be used
to set an executable's maxdata value

----------
components: Build
messages: 128553
nosy: sable
priority: normal
severity: normal
status: open
title: Python memory limit on AIX
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 14 18:12:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:12:56 +0000
Subject: [New-bugs-announce] [issue11213] distutils2 test issue
In-Reply-To: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>
Message-ID: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>


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

Just to test that auto-nosy works.

----------
assignee: tarek
components: Distutils2
messages: 128559
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: distutils2 test issue
versions: 3rd party

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

From report at bugs.python.org  Mon Feb 14 18:36:09 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 17:36:09 +0000
Subject: [New-bugs-announce] [issue11214] test_asyncore fails on AIX
In-Reply-To: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>
Message-ID: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

When running test_asyncore on AIX, I get the following error:

[122/337] test_asyncore
test test_asyncore failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_asyncore.py", line 332, in test_strerror
    self.assertIn("unknown error", err.lower())
AssertionError: 'unknown error' not found in 'error -1 occurred.'

I haven't investigated yet.

----------
messages: 128563
nosy: sable
priority: normal
severity: normal
status: open
title: test_asyncore fails on AIX
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 14 18:39:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 17:39:10 +0000
Subject: [New-bugs-announce] [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error when running test_fileio on AIX:

======================================================================
FAIL: testAbles (test.test_fileio.OtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_fileio.py", line 269, in testAbles
    self.assertEqual(f.seekable(), False)
AssertionError: True != False

----------------------------------------------------------------------
Ran 34 tests in 0.032s

FAILED (failures=1)

I haven't investigated yet.

----------
messages: 128564
nosy: sable
priority: normal
severity: normal
status: open
title: test_fileio error on AIX
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 14 21:26:19 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Mon, 14 Feb 2011 20:26:19 +0000
Subject: [New-bugs-announce] [issue11216] email.message.Message set_charset
	does not encode	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>


New submission from Shay Rojansky <roji at roji.org>:

This may be my misunderstanding of the correct behavior, thanks in advance for your patience...

The issue happens when calling set_charset (or set_payload charset) after a Message has already been created and contains a Content-Transfer-Encoding header. Here's an example:

>>> from email.mime.text import MIMEText
>>> 
>>> part = MIMEText('Some stuff a????a', 'plain', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:17 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

U29tZSBzdHVmZiBhw6nDoMOnw6dh

>>> part.set_payload('Other stuff a????a', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:25 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

Other stuff a????a
>>> 
>>> del part['Content-Transfer-Encoding']
>>> part.set_payload('Still some other stuff a????a', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:40 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

U3RpbGwgc29tZSBvdGhlciBzdHVmZiBhw6nDoMOnw6dh

First the text part is created with charset UTF-8, a dump shows a properly-encoded base64 UTF-8 part.

Then an attempt is made to modify the payload. The set_charset documentation clearly states that the message will be properly encoded/converted, but we get a malformed part with Content-Transfer-Endogin=base64 but without a base64-encoded payload.

Finally, as a workaround, I delete the Content-Transfer-Encoding header and try again, at which point the new payload is properly encoded.

Again, I'm sure there are reasons for this behavior, which nevertheless seems like a bug to me (shouldn't set_charset perform base64 and change the Content-Transfer-Encoding if necessary regardless of previous headers?). Maybe a documentation update would help people with this.

Thank you very much!

----------
components: Library (Lib)
messages: 128573
nosy: Shay.Rojansky
priority: normal
severity: normal
status: open
title: email.message.Message set_charset does not encode properly?
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Feb 15 06:59:09 2011
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 15 Feb 2011 05:59:09 +0000
Subject: [New-bugs-announce] [issue11217] python-32 not linked in
	/usr/local/bin in framework	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>


New submission from Tom Loredo <loredo at astro.cornell.edu>:

When building a universal framework Python-2.7.1 with homebrew on 10.6.6, python-32 (and its target, python2.7-32) are built and installed in the framework executable path, but they are not linked in /usr/local/bin.  msg101156 in Issue 8089 recognized this as a general MacPython problem in a 2.6.5 release candidate but deferred a fix for 2.6.6.  Apparently the fix was never implemented, or perhaps it was decided the link was not appropriate.  It seems to me it *is* appropriate (framework users don't currently have easy command-line access to python-32), but I defer to the experts!

----------
assignee: ronaldoussoren
components: Macintosh
messages: 128578
nosy: ronaldoussoren, tloredo
priority: normal
severity: normal
status: open
title: python-32 not linked in /usr/local/bin in framework builds
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 15 09:33:27 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Tue, 15 Feb 2011 08:33:27 +0000
Subject: [New-bugs-announce] [issue11218] pattern=None when following
	documentation for load_tests	and unittest.main()
In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>
Message-ID: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>


New submission from Martin von Gagern <Martin.vGagern at gmx.net>:

If I follow the documentation at http://docs.python.org/library/unittest.html#unittest.main by putting the following two snippets of code in my module file:

def load_tests(loader, standard_tests, pattern='test*.py'):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

if __name__ == "__main__":
    unittest.main()

then the application will fail with an obscure error message:

======================================================================
ERROR: __main__ (unittest.loader.LoadTestsFailure)
----------------------------------------------------------------------
TypeError: object of type 'NoneType' has no len()

----------------------------------------------------------------------
Ran 1 test in 0.000s

Monkeypatching unittest.loader._make_failed_load_tests to display a stack trace, I got this:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 71, in loadTestsFromModule
    return load_tests(self, tests, None)
  File "tester.py", line 15, in load_tests
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
  File "/usr/lib64/python2.7/unittest/loader.py", line 204, in discover
    tests = list(self._find_tests(start_dir, pattern))
  File "/usr/lib64/python2.7/unittest/loader.py", line 247, in _find_tests
    if not self._match_path(path, full_path, pattern):
  File "/usr/lib64/python2.7/unittest/loader.py", line 235, in _match_path
    return fnmatch(path, pattern)
  File "/usr/lib64/python2.7/fnmatch.py", line 43, in fnmatch
    return fnmatchcase(name, pat)
  File "/usr/lib64/python2.7/fnmatch.py", line 75, in fnmatchcase
    res = translate(pat)
  File "/usr/lib64/python2.7/fnmatch.py", line 87, in translate
    i, n = 0, len(pat)
TypeError: object of type 'NoneType' has no len()

The error is due to the fact that pattern is passed as None to load_tests, but apparently loader.discover doesn't loke a None pattern.

I would suggest that
a) discover internally translates None to the default of 'test*.py' or
b) the documentation is changed to cater for this common use case, i.e. by including a "pattern is None" case distinction in its load_tests snippet.

In case b) is implemented but not a), it would be nice to have a more expressive error message by catching the error somewhat sooner.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: tester.py
messages: 128579
nosy: docs at python, gagern
priority: normal
severity: normal
status: open
title: pattern=None when following documentation for load_tests and unittest.main()
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file20763/tester.py

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

From report at bugs.python.org  Wed Feb 16 04:22:49 2011
From: report at bugs.python.org (Kelsey)
Date: Wed, 16 Feb 2011 03:22:49 +0000
Subject: [New-bugs-announce] [issue11219] Produce a warning when the license
	is specified in both	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>


New submission from Kelsey <kelsey.hightower at gmail.com>:

Distutils2 should produce a warning when the license is specified in both the License and Classifier metadata fields

----------
assignee: tarek
components: Distutils2
messages: 128624
nosy: alexis, eric.araujo, kelseyhightower, tarek
priority: normal
severity: normal
status: open
title: Produce a warning when the license is specified in both the License and Classifier metadata fields
type: feature request
versions: 3rd party

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

From report at bugs.python.org  Wed Feb 16 05:15:42 2011
From: report at bugs.python.org (Ian Wetherbee)
Date: Wed, 16 Feb 2011 04:15:42 +0000
Subject: [New-bugs-announce] [issue11220] https sslv3 error 14077417:
	illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>


New submission from Ian Wetherbee <ian.wetherbee at gmail.com>:

Certain https urls do not open using urllib2 (py2.6) and urllib(py3.1), but they open using the latest version of curl and firefox.

To reproduce:
>>> import urllib.request
>>> urllib.request.urlopen("https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse")
Traceback (most recent call last):
  File "/usr/lib64/python3.1/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/usr/lib64/python3.1/http/client.py", line 932, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python3.1/http/client.py", line 970, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python3.1/http/client.py", line 928, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python3.1/http/client.py", line 782, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.1/http/client.py", line 723, in send
    self.connect()
  File "/usr/lib64/python3.1/http/client.py", line 1055, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/lib64/python3.1/ssl.py", line 381, in wrap_socket
    suppress_ragged_eofs=suppress_ragged_eofs)
  File "/usr/lib64/python3.1/ssl.py", line 135, in __init__
    raise x
  File "/usr/lib64/python3.1/ssl.py", line 131, in __init__
    self.do_handshake()
  File "/usr/lib64/python3.1/ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:488: error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.1/urllib/request.py", line 121, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib64/python3.1/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/usr/lib64/python3.1/urllib/request.py", line 367, in _open
    '_open', req)
  File "/usr/lib64/python3.1/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.1/urllib/request.py", line 1098, in https_open
    return self.do_open(http.client.HTTPSConnection, req)
  File "/usr/lib64/python3.1/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 1] _ssl.c:488: error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter>

Curl request:
$ curl https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="https://apps.uillinois.edu/selfservice/error/">here</A>.<P>
<HR>
<ADDRESS>Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server Server at ui2web1a.admin.uillinois.edu Port 443</ADDRESS>
</BODY></HTML>

----------
components: None
messages: 128626
nosy: Ian.Wetherbee
priority: normal
severity: normal
status: open
title: https sslv3 error 14077417: illegal parameter
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Feb 16 09:31:39 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 08:31:39 +0000
Subject: [New-bugs-announce] [issue11221] all() returns wrong result when
	the parameters are	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>


New submission from Jonathan Livni <jonathan.livni at gmail.com>:

all( (x<=y) for x,y in zip(L, L[1:]) )
all([(x<=y) for x,y in zip(L, L[1:])])

Both lines of code above check if L is a non-decreasing list. Both should return the same results. But under some conditions, they don't. I've encountered this with a list of Decimal numbers.
This is 100% reproducible on my Win7 64bit vanilla Python 2.6.6 32bit setup, alas I cannot share the specific code that generates this difference.
See attached screenshot from Eclipse Pydev debugger.

----------
components: Windows
files: Eclipse.JPG
messages: 128628
nosy: Jonathan.Livni
priority: normal
severity: normal
status: open
title: all() returns wrong result when the parameters are non-encapsulated list-comprehension
versions: Python 2.6
Added file: http://bugs.python.org/file20766/Eclipse.JPG

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

From report at bugs.python.org  Wed Feb 16 11:54:07 2011
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 16 Feb 2011 10:54:07 +0000
Subject: [New-bugs-announce] [issue11222] Python3.2rc3 fails to build on Mac
	OS X with a	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>


New submission from John Szakmeister <john at szakmeister.net>:

I configured the build:
    ./configure --with-system-ffi --enable-shared --with-computed-gotos --prefix=$HOME/.local/python3 

Ran make with 4 jobs (make -j4), and got:
    make: *** No rule to make target `libpython3.2m.dylib', needed by `python.exe'.  Stop.
    make: *** Waiting for unfinished jobs....

It seems there might be a $(VERSION)/$(LDVERSION) problem somewhere in the Makefile, but I'm uncertain where the issue is exactly.  Looks like using --enable-framework instead of --enable-shared works, but I'd rather not have the framework right now.

----------
components: Build
messages: 128647
nosy: jszakmeister
priority: normal
severity: normal
status: open
title: Python3.2rc3 fails to build on Mac OS X with a non-framework build
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 16 15:25:41 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 14:25:41 +0000
Subject: [New-bugs-announce] [issue11223] test_threadsignals.py hanging on
	AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

The test test_lock_acquire_interruption in test_threadsignals.py will lock forever on AIX 5.3.
It works fine on 6.1.

truss shows it is stuck in thread_tsleep:
$ truss -p 1404986
thread_tsleep(0, 0x00000000, 0x00000000, 0x00000000) (sleeping...)

----------
messages: 128668
nosy: sable
priority: normal
severity: normal
status: open
title: test_threadsignals.py hanging on AIX
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 16 19:12:26 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 16 Feb 2011 18:12:26 +0000
Subject: [New-bugs-announce] [issue11224] 3.2: tarfile.getmembers causes
	100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

tarfile.getmembers has become extremely slow on Windows. This was triggered in r85916 by Lars Gustaebel on Oct 29, 2010 to "add read support for all missing variants of the GNU sparse extensions".

To reproduce, use this "tgz" file:

  http://pypm-free.activestate.com/3.2/win32-x86/pool/a/as/as.mklruntime-1.2_win32-x86_3.2_1.pypm

It contains another tgz file called "data.tar.gz". Run `.getmembers()` on data.tar.gz.

...

This invokes tarfile._FileInFile.read(...) that seems to be cause of slowness (or rather a hang). 

I had to workaround this issue by monkey-patching the above `read` function to revert the change:

+if sys.version_info[:2] >= (3,2):
+    import tarfile
+    class _FileInFileNoSparse(tarfile._FileInFile):
+        def read(self, size):
+            if size is None:
+                size = self.size - self.position
+            else:
+                size = min(size, self.size - self.position)
+            self.fileobj.seek(self.offset + self.position)
+            self.position += size
+            return self.fileobj.read(size)
+    tarfile._FileInFile = _FileInFileNoSparse
+    LOG.info('Monkey patching `tarfile.py` to disable part of r85916 (py3k)')

We caught this bug as part of testing ActiveState PyPM on Python 3.2
http://bugs.activestate.com/show_bug.cgi?id=89376#c3

If you want the easiest way to reproduce this, I can send you (in private) an internal build of ActivePython-3.2 containing PyPM. Running "pypm install numpy" (with breakpoints in tarfile.py) is all that is required to reproduce.

----------
components: Library (Lib), Windows
messages: 128685
nosy: lars.gustaebel, srid
priority: normal
severity: normal
status: open
title: 3.2: tarfile.getmembers causes 100% cpu usage on Windows
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 16 23:18:08 2011
From: report at bugs.python.org (Nicolas Joly)
Date: Wed, 16 Feb 2011 22:18:08 +0000
Subject: [New-bugs-announce] [issue11225] getcwd fix for NetBSD to handle
	ERANGE errno
In-Reply-To: <1297894688.76.0.163416819421.issue11225@psf.upfronthosting.co.za>
Message-ID: <1297894688.76.0.163416819421.issue11225@psf.upfronthosting.co.za>


New submission from Nicolas Joly <njoly at pasteur.fr>:

NetBSD do require the very same fix from issue 9185, to handle ERANGE errno returned when the size argument is greater than zero but smaller
than the length of the pathname plus 1.

Without it, the testsuite do indeed loops indefinitely.

Thanks.

----------
components: Interpreter Core
files: python-getcwd.diff
keywords: patch
messages: 128698
nosy: njoly
priority: normal
severity: normal
status: open
title: getcwd fix for NetBSD to handle ERANGE errno
versions: Python 2.7
Added file: http://bugs.python.org/file20773/python-getcwd.diff

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

From report at bugs.python.org  Thu Feb 17 00:04:12 2011
From: report at bugs.python.org (Yang Zhang)
Date: Wed, 16 Feb 2011 23:04:12 +0000
Subject: [New-bugs-announce] [issue11226] subprocesses experience mysterious
	delay in receiving	stdin EOF
In-Reply-To: <1297897452.24.0.902821859924.issue11226@psf.upfronthosting.co.za>
Message-ID: <1297897452.24.0.902821859924.issue11226@psf.upfronthosting.co.za>


New submission from Yang Zhang <yang.pythonbugs at mailnull.com>:

I'm seeing this issue on all the multiple Ubuntu 10.04 boxes I've tried.

I reduced a problem I was seeing in my application down into the following test case. In this code, a parent process concurrently spawns 2 (you can spawn more) subprocesses that read a big message from the parent over stdin, sleep for 5 seconds, and write something back. However, there's unexpected waiting happening somewhere, causing the code to complete in 10 seconds instead of the expected 5.

If you set verbose=True, you can see that the straggling subprocess is receiving most of the messages, then waiting for the last chunk of 3 chars---it's not detecting that the pipe has been closed. Furthermore, if I simply don't do anything with the second process (doreturn=True), the first process will never see the EOF.

Further down is some example output. When trying this out, you may need to increase the message size to see the behavior occur.

from subprocess import *
from threading import *
from time import *
from traceback import *
import sys
verbose = False
doreturn = False
msg = (20*4096+3)*'a'
def elapsed(): return '%7.3f' % (time() - start)
if sys.argv[1:]:
  start = float(sys.argv[2])
  if verbose:
    for chunk in iter(lambda: sys.stdin.read(4096), ''):
      print >> sys.stderr, '..', time(), sys.argv[1], 'read', len(chunk)
  else:
    sys.stdin.read()
  print >> sys.stderr, elapsed(), '..', sys.argv[1], 'done reading'
  sleep(5)
  print msg
else:
  start = time()
  def go(i):
    print elapsed(), i, 'starting'
    p = Popen(['python','stuckproc.py',str(i), str(start)], stdin=PIPE, stdout=PIPE)
    if doreturn and i == 1: return
    print elapsed(), i, 'writing'
    p.stdin.write(msg)
    print elapsed(), i, 'closing'
    p.stdin.close()
    print elapsed(), i, 'reading'
    p.stdout.read()
    print elapsed(), i, 'done'
  ts = [Thread(target=go, args=(i,)) for i in xrange(2)]
  for t in ts: t.start()
  for t in ts: t.join()

Example output:

  0.001 0 starting
  0.003 1 starting
  0.005 0 writing
  0.016 1 writing
  0.093 0 closing
  0.093 0 reading
  0.094 1 closing
  0.094 1 reading
  0.098 .. 1 done reading
  5.103 1 done
  5.108 .. 0 done reading
 10.113 0 done

----------
components: Library (Lib)
messages: 128699
nosy: yaaang
priority: normal
severity: normal
status: open
title: subprocesses experience mysterious delay in receiving stdin EOF
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 17 00:26:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 16 Feb 2011 23:26:29 +0000
Subject: [New-bugs-announce] [issue11227] [DOC] asyncore - use 'Host' header
	in HTTP example
In-Reply-To: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>
Message-ID: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003096.html I wrote a patch to introduce the 'Host' header in the HTTP example of asyncore doc. I've also fixed an indentation error with the last 2 lines of the same example (simple cut&paste would fail with "unexpected intentantion").

Given it's a doc issue, and it quite easy, I think it should be backported to the current on-maintainence releases (the example fails on all of them).

----------
assignee: sandro.tosi
components: Documentation
files: asyncore-use-host-header-py3k.patch
keywords: patch
messages: 128700
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: [DOC] asyncore - use 'Host' header in HTTP example
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20774/asyncore-use-host-header-py3k.patch

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

From report at bugs.python.org  Thu Feb 17 00:29:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 23:29:26 +0000
Subject: [New-bugs-announce] [issue11228] raw unicode strings interpret \u
	and \U (but not \n, \xHH, ...)
In-Reply-To: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>
Message-ID: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>


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

len(ur'\u0000') == len(u'\u0000') == 1
len(ur'\U0010FFFF') == len(u'\U0010FFFF') == 1

but

>>> len(ur'\n'), len(u'\n')
(2, 1)
>>> len(ur'\x00'), len(u'\x00')
(4, 1)

\u and \U should not be interpreted in raw Unicode strings.

----------
messages: 128701
nosy: haypo
priority: normal
severity: normal
status: open
title: raw unicode strings interpret \u and \U (but not \n, \xHH, ...)
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb 17 00:34:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Feb 2011 23:34:42 +0000
Subject: [New-bugs-announce] [issue11229] Make the Mac installer more like
	the Windows installer
In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>
Message-ID: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>


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

The Windows installer gives a choice of two install locations, for all users and for the current user; the latter does not require admin rights.  

It lists optional components, giving the size of each:
- Register Extensions 2kb
- Tcl/Tk 13mb (includes IDLE)
- Documentation 5Mb
- Utility Scripts 632kb
- Test Suite 9.7Mb.  
The default is to install all of those.

The installer removes any previous versions before installing (including wiping their __pycache__ directories).

With the full install, the listing in All Programs (the windows parallel to the Application Folder) includes five entries:
- IDLE (gui)
- Module Docs (via pydoc)
- Python (command-line terminal)
- Python Manuals (points to a chm file)
- Uninstall Python.

In addition to what is offered on Windows, I think there should be an addition entry in the Application Folder for running the test suite so that some one can validate their install without going to the command-line.

----------
components: Installation
messages: 128702
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make the Mac installer more like the Windows installer
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 17 08:10:35 2011
From: report at bugs.python.org (John)
Date: Thu, 17 Feb 2011 07:10:35 +0000
Subject: [New-bugs-announce] [issue11230] "Full unicode import system" not
	in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

A few months ago I read that in 3.2 it will be possible to import modules that are located on paths containing any unicode character. (more precisely, with chars not in the local code page)

After an hour or two trying to get this to work in 3.2rc3, I went looking for clues, and found these 2 messages in which Victor Stinner says this feature is delayed until Python 3.3:
http://bugs.python.org/issue3080#msg126514
http://bugs.python.org/issue10828#msg125787

Could you please make it clear in documentation and web pages, that this feature is not working yet. 

The Python 3.2 download page includes this:
"countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables)"
and I guessed this must cover importing from any unicode path, as there was no mention that such importing had been abandoned for this version.

-- jh

----------
assignee: docs at python
components: Documentation
messages: 128711
nosy: docs at python, jh45
priority: normal
severity: normal
status: open
title: "Full unicode import system" not in 3.2
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 17 17:46:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 16:46:44 +0000
Subject: [New-bugs-announce] [issue11231] bytes() constructor is not
	correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>


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

There are 5 different usages of the bytes() constructor:

1) bytes(iterable_of_ints) -> bytes
2) bytes(string, encoding[, errors]) -> bytes
3) bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer
4) bytes(memory_view) -> bytes
5) bytes(int) <=> b'\0' * size

The docstring describes the four first usages, the documentation only (3).
http://docs.python.org/dev/library/functions.html#bytes

Note: bytes(3) accepts 2 other arguments, but I don't think that they are used: bytes(3, 'unused encoding', 'unused errors').

----------
assignee: docs at python
components: Documentation
messages: 128739
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: bytes() constructor is not correctly documented
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 17 19:22:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 18:22:42 +0000
Subject: [New-bugs-announce] [issue11232] asyncore - don't throw a traceback
	when a client	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003095.html I'm attaching a simple patch to avoid a traceback similar to this when a client disconnects:

error: uncaptured python exception, closing channel <__main__.EchoHandler 127.0.0.1:41884 at 0x150ae60> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/home/morph/python-dev/py3k/Lib/asyncore.py|read|81] [/home/morph/python-dev/py3k/Lib/asyncore.py|handle_read_event|440] [<stdin>|handle_read|4] [/home/morph/python-dev/py3k/Lib/asyncore.py|send|550] [/home/morph/python-dev/py3k/Lib/asyncore.py|initiate_send|537] [/home/morph/python-dev/py3k/Lib/asyncore.py|send|367])

----------
assignee: sandro.tosi
files: asyncore-notraceback-py3k.patch
keywords: patch
messages: 128744
nosy: giampaolo.rodola, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: asyncore - don't throw a traceback when a client disconnects in echo server example
Added file: http://bugs.python.org/file20778/asyncore-notraceback-py3k.patch

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

From report at bugs.python.org  Thu Feb 17 20:03:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 19:03:19 +0000
Subject: [New-bugs-announce] [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003083.html we have a chat on #python-dev on the topic, the situation is

- all started with os.lchmod() and as.lchflags() methods not available on a Debian system
- that's because POSIX does not require those functions and then Linux systems don't provide them 
- so we then thought about clarifying, only for those 2 methods, that they might not be available with a format like "availability: some unix systems"
- then we noticed that on top of os doc there's a notice "An ?Availability: Unix? note means that this function is commonly found on Unix systems. It does not make any claims about its existence on a specific operating system." and so we thought about linking every 'Availability: Unix' to that note
- or transform that not in a footnote and link every 'Availability: Unix' for functions that might not be present to that footnote.

It's enough for the conversation dump: ideas/suggestions? :)

----------
assignee: docs at python
components: Documentation
messages: 128746
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
status: open
title: clarifying Availability: Unix

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

From report at bugs.python.org  Thu Feb 17 20:22:35 2011
From: report at bugs.python.org (Carl Chenet)
Date: Thu, 17 Feb 2011 19:22:35 +0000
Subject: [New-bugs-announce] [issue11234] Possible error in What's new
	Python3.2(rc3)	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>


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

Hi,

It seems a mistake could be in the "What's new in Python 3.2" (rc3) documentation in the sysconfig.get_config_var('SO') example :

>>> sysconfig.get_config_var('SO')       # find the full filename extension
'cpython-32mu.so'

On my system (Debian GNU/Linux, Python3.2rc3), the same command gives :
 
>>> sysconfig.get_config_var('SO')
'.cpython-32m.so'

A dot at the beginning of the string could be missing in the example of the current documentation. This dot also appears in the example of the PEP 3149.

Regards,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 128747
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: Possible error in What's new Python3.2(rc3) documentation (sysconfig.get_config_var)
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 17 21:20:58 2011
From: report at bugs.python.org (Guy Kisel)
Date: Thu, 17 Feb 2011 20:20:58 +0000
Subject: [New-bugs-announce] [issue11235] Source files with date modifed in
	2106 cause	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>


New submission from Guy Kisel <guy.kisel at gmail.com>:

Tested in Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

Exception thrown: OverflowError: modification time overflows a 4 byte field

Steps to reproduce:
1. Set system time to 2/8/2106 or later and modify a .py file (or use a utility to change the date modified directly).
2. Try to run or import the .py file.

This date is 2^32 seconds after the Unix epoch.

----------
components: None
messages: 128753
nosy: Guy.Kisel
priority: normal
severity: normal
status: open
title: Source files with date modifed in 2106 cause OverflowError
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 17 21:56:28 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Thu, 17 Feb 2011 20:56:28 +0000
Subject: [New-bugs-announce] [issue11236] getpass.getpass does not respond
	to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

In python 2.5, entering ^C in a getpass prompt yields a KeyboardInterrupt. In later versions, nothing happens, and '\x03' is returned after pressing return.
In python 2.5, entering ^Z in a getpass prompt suspends the process. In later versions, nothing happens, and '\x1a' is returned after pressing return.

Pressing ctrl-C or ctrl-Z multiple times returns '\x03'/'\x1a' multiple times.

Tested versions:
Python 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.3.3] on linux2 (OK)
  getpass.py is http://svn.python.org/view/python/trunk/Lib/getpass.py?revision=43495&view=markup
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 (BAD)
  getpass.py is r76000 with the following diff:
54c54
<         except (AttributeError, ValueError):
---
>         except:
 (so it doesn't implement r74860)
Python 2.7.1 (r271:86832, Jan  4 2011, 13:57:14) [GCC 4.5.2] on sunos5 (BAD)
Python 3.1.2 (r312:79147, Sep 27 2010, 09:45:41) [GCC 4.4.3] on linux2 (BAD)
Python 3.1.3 (r313:86834, Dec  1 2010, 20:16:39) [GCC 4.5.1] on sunos5 (BAD)

Steps to reproduce:
1) import getpass
2) getpass.getpass('-> ')
3) press ctrl-C or ctrl-Z
- nothing happens
4) press return
- '\x03'/'\x1a' is returned

----------
components: Library (Lib)
messages: 128754
nosy: valhallasw
priority: normal
severity: normal
status: open
title: getpass.getpass does not respond to ctrl-c or ctrl-z
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Feb 17 22:25:59 2011
From: report at bugs.python.org (Maurice Maneschi)
Date: Thu, 17 Feb 2011 21:25:59 +0000
Subject: [New-bugs-announce] [issue11237] odbc module crashes Python
	interpretter
In-Reply-To: <1297977959.44.0.182816269103.issue11237@psf.upfronthosting.co.za>
Message-ID: <1297977959.44.0.182816269103.issue11237@psf.upfronthosting.co.za>


New submission from Maurice Maneschi <mamaneschi at gmail.com>:

In Python 3.1.3 under Windows XP sp3, I enter the following under the interpretter:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\MauriceM>c:\Python31\python.exe
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import odbc
>>> c = odbc.odbc('Quantum/Quantum/Quantum3')
>>> dir(c)

C:\Documents and Settings\MauriceM>

At that point, Windows pops up a crash notification and asked if MS should be informed.

Questions
=========
1) Is ODBC no longer supported?

----------
components: Windows
messages: 128756
nosy: Maurice.Maneschi
priority: normal
severity: normal
status: open
title: odbc module crashes Python interpretter
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Feb 17 22:27:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 21:27:35 +0000
Subject: [New-bugs-announce] [issue11238] sets - refer to sets/frozenset in
	stdtypes
In-Reply-To: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>
Message-ID: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003088.html, here's a patch to make sets.html big red notice :) refer to set/frozenset into stdtypes page with a couple of links.

----------
assignee: sandro.tosi
components: Documentation
files: sets_refers_to_stdtypes-rel2.7.patch
keywords: patch
messages: 128757
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: sets - refer to sets/frozenset in stdtypes
versions: Python 2.7
Added file: http://bugs.python.org/file20780/sets_refers_to_stdtypes-rel2.7.patch

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

From report at bugs.python.org  Fri Feb 18 00:08:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 23:08:31 +0000
Subject: [New-bugs-announce] [issue11239] regexp-howto - add missing } to
	metachars
In-Reply-To: <1297984111.53.0.588454087377.issue11239@psf.upfronthosting.co.za>
Message-ID: <1297984111.53.0.588454087377.issue11239@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

hi, following up http://mail.python.org/pipermail/docs/2011-February/003099.html, here's a patch to add '}' to metachars, currently missing.

----------
assignee: sandro.tosi
components: Documentation
files: regex-howto-add-missin-metachar-py3k.patch
keywords: patch
messages: 128767
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: regexp-howto - add missing } to metachars
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20781/regex-howto-add-missin-metachar-py3k.patch

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

From report at bugs.python.org  Fri Feb 18 00:57:00 2011
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 17 Feb 2011 23:57:00 +0000
Subject: [New-bugs-announce] [issue11240] Running unit tests in a command
	line tool leads to	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>


New submission from Matt Chaput <matt at whoosh.ca>:

If you start unit tests with a command line such as "python setup.py test" or "nosetests", if the tested code starts a multiprocessing.Process on Windows, each new process will act as if it was started as "python setup.py test"/"nosetests", leading to an infinite explosion of processes that eventually locks up the entire machine.

----------
components: Windows
messages: 128768
nosy: mattchaput
priority: normal
severity: normal
status: open
title: Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 18 00:59:27 2011
From: report at bugs.python.org (Steve Thompson)
Date: Thu, 17 Feb 2011 23:59:27 +0000
Subject: [New-bugs-announce] [issue11241] ctypes: subclassing an already
	subclassed ArrayType	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

Consider the following:
python code:
class my_array( ctypes.Array ):
    _type_    = ctypes.c_uint8
    _length_  = 256

class my_array2( my_array ):
    pass

Output:
class my_array2( my_array ):
AttributeError: class must define a '_length_' attribute, which must be a positive integer


This is analogous to the C code
typedef char my_array[ 256 ];
typedef my_array my_array2;

However, the python code raises exceptions claiming _type_ and _length_ have not been defined.  This seems like a bug.  I shouldn't need to redefine _type_ and _length_, otherwise there was no point in subclassing my_array.

I tried to step into this using pdb but didn't have any luck.

----------
assignee: theller
components: ctypes
messages: 128769
nosy: Steve.Thompson, theller
priority: normal
severity: normal
status: open
title: ctypes: subclassing an already subclassed ArrayType generates AttributeError
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 18 12:41:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 11:41:58 +0000
Subject: [New-bugs-announce] [issue11242] urllib.request.url_open() doesn't
	support SSLContext
In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>
Message-ID: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>


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

Issue?#9003 added cafile and capath arguments to url_open(), but it is not possible to reuse a SSLContext object (which would avoid to reload certificates, CRL, etc.).

----------
components: Library (Lib)
messages: 128779
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: urllib.request.url_open() doesn't support SSLContext
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 18 15:53:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 18 Feb 2011 14:53:20 +0000
Subject: [New-bugs-announce] [issue11243] email/message.py str conversion
	[patch]
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Hy David, while hacking a bit on my thing i've found two places where header.Header needs to be explicitely converted via str().
Have a nice weekend.

----------
files: email_message.patch
keywords: patch
messages: 128782
nosy: r.david.murray, sdaoden
priority: normal
severity: normal
status: open
title: email/message.py str conversion [patch]
Added file: http://bugs.python.org/file20784/email_message.patch

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

From report at bugs.python.org  Fri Feb 18 18:41:05 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Fri, 18 Feb 2011 17:41:05 +0000
Subject: [New-bugs-announce] [issue11244] Negative tuple elements produce
	inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jharper at yapdc.com>:

In Python 3.2, a tuple like (1,-2,3) will not be optimized into a constants at compile time.  The tuple is built at run-time.  Earlier versions of Python optimized these tuples at compile time.

Here's an example program.

# test.py
from dis import dis

def x(): return (1,2,3)
def y(): return (1,-2,3)

print ("dis x:")
dis(x)
print()

print("dis y:")
dis(y)

The compiler in 3.2rc3 produces code for function y() that builds the tuple at run-time while the tuple in x() is optimized at compile time.

C:\tmp>c:\python32\python --version
Python 3.2rc3

C:\tmp>c:\python32\python test.py
dis x:
  3           0 LOAD_CONST               4 ((1, 2, 3))
              3 RETURN_VALUE

dis y:
  4           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               4 (-2)
              6 LOAD_CONST               3 (3)
              9 BUILD_TUPLE              3
             12 RETURN_VALUE

However, under 3.1.3, the tuples in both functions are optimized at compile time.

C:\tmp>c:\python31\python test.py
dis x:
  3           0 LOAD_CONST               4 ((1, 2, 3))
              3 RETURN_VALUE

dis y:
  4           0 LOAD_CONST               4 ((1, -2, 3))
              3 RETURN_VALUE

Although the compiled code produced 3.2rc3 is correct, it is much slower than the code generated by 3.1.3.

----------
messages: 128795
nosy: jdharper
priority: normal
severity: normal
status: open
title: Negative tuple elements produce inefficient code.
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 18 21:36:11 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Fri, 18 Feb 2011 20:36:11 +0000
Subject: [New-bugs-announce] [issue11245] Implementation of IMAP IDLE in
	imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>


New submission from Shay Rojansky <roji at roji.org>:

IMAP IDLE support is not implemented in the current imaplib. A "drop-in" replacement called imaplib2 exists (), but uses internally managed threads - a heavy solution that is not always appropriate (e.g. when handling many IMAP accounts an asynchronous approach would be more efficient)

I am about to start implementation of an asynchronous select()-compatible approach, and was wondering if there has been any discussion over IDLE, any specific reasons it hasn't been implemented and if eventual integration into imaplib would be a desirable thing.

Proposed approach:
* Addition of a new state 'IDLE'
* Addition of an idle() method to class IMAP4, which issues the IDLE command to the server and returns immediately. At this point we enter the IDLE state, in which no normal IMAP commands may be issued.
* Users can now select() or poll() the socket as they wish
* A method can be called to retrieve any untagged responses (e.g. EXISTS) that have arrived since entering the IDLE state. The function returns immediately and does not modify the state.
* To end the IDLE state, the user calls a method (done()?) which resumes the previous state.

Would appreciate any sort of feedback...

----------
components: Library (Lib)
messages: 128814
nosy: Shay.Rojansky
priority: normal
severity: normal
status: open
title: Implementation of IMAP IDLE in imaplib?
type: feature request

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

From report at bugs.python.org  Fri Feb 18 23:12:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 22:12:14 +0000
Subject: [New-bugs-announce] [issue11246] PyUnicode_FromFormat("%V") decodes
	the byte string from	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>


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

While testing a patch fixing issue #7330, I found a bug in PyUnicode_FromFormat() in the %V format: it decodes the byte string from ISO-8859-1, whereas I would expect that the string is decodes from UTF-8, as the "%s" format.

----------
messages: 128816
nosy: haypo, ysj.ray
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormat("%V") decodes the byte string from ISO-8859-1
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 19 04:54:55 2011
From: report at bugs.python.org (Dan Mahn)
Date: Sat, 19 Feb 2011 03:54:55 +0000
Subject: [New-bugs-announce] [issue11247] e
Message-ID: <1298087695.27.0.0995068900859.issue11247@psf.upfronthosting.co.za>


Changes by Dan Mahn <dan.mahn at digidescorp.com>:


----------
nosy: dmahn
priority: normal
severity: normal
status: open
title: e

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

From report at bugs.python.org  Sat Feb 19 11:50:45 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 19 Feb 2011 10:50:45 +0000
Subject: [New-bugs-announce] [issue11248] Tails of generator get lost under
	zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>


New submission from Greg Kochanski <gpk at kochanski.org>:

When you have a generator as an argument to zip(), code after the last yield statement may not get executed.  The problem is that zip() stops after it gets _one_ exception, i.e. when just one of the generators has finished.

As a result, if there were any important clean-up code at the end of a generator, it will not be executed.   Caches may not get flushed, et cetera.

At the least, this is a documentation bug that needs to be pointed out in both zip() and the definition of a generator().  More realistically, it is a severe wart on the language, because it violates the programmer's reasonable expectation that a generator executes until it falls off the end of the function.  It means that a generator becomes conceptually nasty: you cannot predict what it will do based just on an inspection of the code and the code it calls.

Likely, the same behavior happens in itertools, too.

----------
components: None
files: bug312.py
messages: 128842
nosy: gpk-kochanski
priority: normal
severity: normal
status: open
title: Tails of generator get lost under zip()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20794/bug312.py

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

From report at bugs.python.org  Sat Feb 19 17:38:32 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 16:38:32 +0000
Subject: [New-bugs-announce] [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Currently, memory management for the Py_tp_doc slot in PyType_FromSpec is ill-defined. The doc string being passed is stored in the type object as-is, but later released with PyObject_Free. To make this consistent, PyType_FromSpec should copy the string, so that it's guaranteed that relasing the memory matches allocation.

Without this patch, users will have to hold onto the type objects they get from PyType_FromSpec "forever".

----------
files: tp_doc.diff
keywords: patch
messages: 128857
nosy: loewis
priority: release blocker
severity: normal
status: open
title: Memory mismanagement with Py_tp_doc
Added file: http://bugs.python.org/file20797/tp_doc.diff

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

From report at bugs.python.org  Sun Feb 20 00:57:25 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 19 Feb 2011 23:57:25 +0000
Subject: [New-bugs-announce] [issue11250] 2to3 truncates files at formfeed
	character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

Running Tools/Scripts/2to3.py on Python 3.2rc3 or 2.7.1 for Windows on a file that contains a formfeed character (0x0C, <FF>) results in a truncated file. 

E.g. a file (attached) with the content

print 1
<FF>
print 2

is incorrectly refactored:

@@ -1,4 +1,1 @@
-print 1
-
-
-print 2
+print(1)


Python 2.6.6 and 3.1.3 correctly refactor the file:

-print 1
+print(1)
 <FF>
-print 2
+print(2)

----------
files: formfeedbug.py
messages: 128885
nosy: cgohlke
priority: normal
severity: normal
status: open
title: 2to3 truncates files at formfeed character
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20800/formfeedbug.py

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

From report at bugs.python.org  Sun Feb 20 01:37:08 2011
From: report at bugs.python.org (Jon McKenzie)
Date: Sun, 20 Feb 2011 00:37:08 +0000
Subject: [New-bugs-announce] [issue11251] cmd.Cmd tab completion treats
	dashes as spaces
In-Reply-To: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>
Message-ID: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>


New submission from Jon McKenzie <jcmcken at gmail.com>:

I'm writing a cmd.Cmd module that operates on filenames. As such, I'm attempting to write tab completions that operate similar to bash. However, files that contain dashes (hyphens) appear to exhibit unexpected behavior.

It appears that somewhere along the line, dashes are converted into spaces for the purposes of tab completion.

So, for example..

(Cmd) edit blah-<tab><tab>

Should print..

blah-1.0.0.txt  blah-2.0.0.txt

And..

(Cmd) edit blah-1<tab><tab>

Should autocomplete to..

(Cmd) edit blah-1.0.0.txt

Instead, the following behavior occurs:

(Cmd) edit blah-<tab><tab>

..becomes...

(Cmd) edit blah-blah

..and thus..

(Cmd) edit blah-blah-<tab><tab>

..becomes, in turn..

(Cmd) edit blah-blah-blah

My completion function is absolutely standard, as far as I'm able to tell from looking at other examples (see attached)

----------
files: completion.snip
messages: 128888
nosy: Jon.McKenzie
priority: normal
severity: normal
status: open
title: cmd.Cmd tab completion treats dashes as spaces
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20801/completion.snip

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

From report at bugs.python.org  Sun Feb 20 04:40:07 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Sun, 20 Feb 2011 03:40:07 +0000
Subject: [New-bugs-announce] [issue11252] Handling statement OR assignment
	continuation '\' on	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>


New submission from Suresh Kalkunte <sskalkunte at gmail.com>:

Referring to URL for files used to build the Apache Portable Runtime Utilities library using Python 2.7.1(AMD64) or 2.6.5(Cygwin) on a Win32 system (Windows 7), when apr/build/gen-build.py (http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/build/gen-build.py?revision=886996&view=markup) parses '\' on line 96 and 97 in apr-util/build.conf (http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/build.conf?revision=886996&view=markup), it recognizes them as separate tokens causing the script to fail on line 168 "assert file[-2:] == '.c'". If the line continuation notation ('\') is removed from build.conf, gen-build.py performs without errors. 

On a Redhat Linux, I have verified Python 2.5.5 (and trust 2.7.1 to provide the same behavior on Linux) handles '\' without errors leading me to believe that if this is a bug, it is only on Win32 platform (and instances where '\' is used for directory path separation).

I am new to Python, from searching the python bug database, I have not been able to find the above condition covered. If this bug has already been identified, please disregard.

----------
components: Interpreter Core, Windows
messages: 128890
nosy: Suresh.Kalkunte
priority: normal
severity: normal
status: open
title: Handling statement OR assignment continuation '\' on Win32 platform
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Feb 20 07:13:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Feb 2011 06:13:46 +0000
Subject: [New-bugs-announce] [issue11253] autodocument first appearance of
	ctypes.wintypes	constants
In-Reply-To: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
Message-ID: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I've just noticed that my application is incompatible with Python 2.5, because ctypes.wintypes is missing SHORT constants. However, I can't find the information when these symbols were introduced first. To prevent such confusion in future it would be nice to extract symbol information for each Python release and automatically include the version of the first appearance in documentation.

----------
assignee: docs at python
components: Documentation
messages: 128893
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: autodocument first appearance of ctypes.wintypes constants
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 20 10:54:58 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Feb 2011 09:54:58 +0000
Subject: [New-bugs-announce] [issue11254] distutils doesn't byte-compile .py
	files to __pycache__	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>


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

During installation of Python packages (setup.py install or bdist), distutils puts .pyc files into the installed source directory, instead of moving them into __pycache__. This may mean that they are not getting used after installation (with potentially no way of getting updated due to lack of write access by users), and that source files that get imported during installation may end up with .pyc files in both the source directory and the __pycache__ directory in the installed package.

The relevant python-dev thread is here:

http://thread.gmane.org/gmane.comp.python.devel/121248/

----------
assignee: tarek
components: Distutils
messages: 128897
nosy: eric.araujo, scoder, tarek
priority: normal
severity: normal
status: open
title: distutils doesn't byte-compile .py files to __pycache__ during installation
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb 20 11:28:07 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Feb 2011 10:28:07 +0000
Subject: [New-bugs-announce] [issue11255] 2to3 throws AttributeError during
	distutils installation	with -O
In-Reply-To: <1298197687.53.0.332108526066.issue11255@psf.upfronthosting.co.za>
Message-ID: <1298197687.53.0.332108526066.issue11255@psf.upfronthosting.co.za>


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

When running a distutils installation of Cython (which uses lib2to3) as "python3.2 -O setup.py bdist", I get this:

Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "setup.py", line 319, in <module>
    **setup_args
  File "/opt/python3.2-opt/lib/python3.2/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/bdist.py", line 132, in run
    self.run_command(cmd_name)
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/bdist_dumb.py", line 74, in run
    self.run_command('build')
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/build.py", line 128, in run
    self.run_command(cmd_name)
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/build_py.py", line 404, in run
    self.run_2to3(self.updated_files)
  File "/opt/python3.2-opt/lib/python3.2/distutils/util.py", line 649, in run_2to3
    return run_2to3(files, self.fixer_names, self.options, self.explicit)
  File "/opt/python3.2-opt/lib/python3.2/distutils/util.py", line 597, in run_2to3
    r.refactor(files, write=True)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 296, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 349, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 381, in refactor_string
    self.refactor_tree(tree, name)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 442, in refactor_tree
    find_root(node)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128900
nosy: scoder
priority: normal
severity: normal
status: open
title: 2to3 throws AttributeError during distutils installation with -O
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb 20 13:11:10 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 20 Feb 2011 12:11:10 +0000
Subject: [New-bugs-announce] [issue11256] inspect.getcallargs raises
	TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

inspect.getcallargs raises TypeError if given a function with only **kwargs, and some keyword arguments:

Python 3.3a0 (py3k:88451, Feb 20 2011, 12:37:22) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> from inspect import getcallargs
>>> 
>>> def f(**kwargs): pass
... 
>>> f(a=1, b=2)
>>> 
>>> getcallargs(f, a=1, b=2)
Traceback (most recent call last):
    ...
TypeError: f() takes no arguments (2 given)


In line 946 of inspect.py the "num_args == 0 and num_total" condition is true: the function expects 0 positional arguments and got more than zero arguments, but in this case these are keyword arguments, so it shouldn't raise TypeError.

----------
components: Library (Lib)
messages: 128902
nosy: benjamin.peterson, durban, gsakkis
priority: normal
severity: normal
status: open
title: inspect.getcallargs raises TypeError on valid arguments
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 20 16:44:06 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 20 Feb 2011 15:44:06 +0000
Subject: [New-bugs-announce] [issue11257] asyncore stores unnecessary object
	references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asyncore.py:
-----------
    def add_channel(self, map=None):
        #self.log_info('adding channel %s' % self)
        if map is None:
            map = self._map
        map[self._fileno] = self
---------

As we see, it add itself to a map, creating unnecessary refences to 'self'.

Such code should be rewritten via weakref. Now it's unknown when object will garbage collected. For example, if someone forget to call close(), object will stuck, eating file descriptor and memory... 

When using weakref, we may guarantee (via callback fcuntion), that we call close() when last reference to object has been lost. Also, such behaviour guarantee, that object will be garbage collected when last user's reference has gone.

To approve my thoughts, see code:
------------------------------
class MyServer(asyncore.dispatcher):
    def __init__(self, listenaddr):
        asyncore.dispatcher.__init__(self)
        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
        self.set_reuse_addr()
        self.bind(listenaddr)
        self.listen(5)
    def handle_accept(self):
        while 1:
            r=self.accept()
            if r is None:
                break
            my_conn_handler(r[0])
------------
As we see, we create a new instance via my_conn_handler(), and we do not store reference to it, but object will not be garbage collected. It's unexpected behaviour.

----------
components: Library (Lib)
messages: 128909
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore stores unnecessary object references
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 20 17:03:59 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 20 Feb 2011 16:03:59 +0000
Subject: [New-bugs-announce] [issue11258] ctypes: Speed up find_library() on
	Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

(This applies to all versions of Python I investigated, although the attached patch is for Python 2.7)

I wondered why `import uuid` took so long, so I did some profiling.

It turns out that `find_library` wastes at lot of time because of this crazy regular expression in `_findSoname_ldconfig`.

A quick look at the ldconfig source (namely, the print_cache routine which is invoked when you call `ldconfig -p`, http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/cache.c#l127) confirmed my suspicion that the ldconfig's output could easily be parsed without such a regex monster.

I attached two patches that fix this problem. Choose one! ;-)

The ctypes tests pass with my fixes, and here comes some benchmarking:

$ cat benchmark_ctypes.py 
from ctypes.util import find_library
for i in xrange(10):
  for lib in ['mm', 'c', 'bz2', 'uuid']:
    find_library(lib)

# Current implementation
$ time python benchmark_ctypes.py 
real    0m11.813s
...
$ time python -c 'import uuid'
real    0m0.625s
...

# With my patch applied
$ cp /tmp/ctypesutil.py ctypes/util.py
$ time python benchmark_ctypes.py 
real    0m1.785s
...
$ time python -c 'import uuid'
real    0m0.182s
...

----------
assignee: theller
components: ctypes
files: faster-find-library1.diff
keywords: patch
messages: 128910
nosy: jonash, theller
priority: normal
severity: normal
status: open
title: ctypes: Speed up find_library() on Linux by 500%
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20808/faster-find-library1.diff

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

From report at bugs.python.org  Sun Feb 20 17:40:02 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 20 Feb 2011 16:40:02 +0000
Subject: [New-bugs-announce] [issue11259] asynchat
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asynchat does not check if terminator is negative integer. so constructions like self.ac_in_buffer[:n] will lead to misbehaviour.

When that integer goes from net, attack can be crafted. For example, on Content-Length field.

----------
components: Library (Lib)
messages: 128914
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asynchat
type: security

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

From report at bugs.python.org  Sun Feb 20 21:03:51 2011
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 20 Feb 2011 20:03:51 +0000
Subject: [New-bugs-announce] [issue11260] smtpd-as-a-script feature should
	be documented and	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

argparse has been merged to the standard library in 3.2, and (tell me if I'm wrong) would therefore be the "best-practices" way to parse command-line arguments.

Numerous stdlib modules can be used as scripts, but they tend to have ad-hoc documentation (if they are at all documented) and arguments parsing (using any of the 4 available methods in Python: straight from sys.argv, getopt, optparse and argparse).

I picked smtpd as a first shot since it does something useful (SMTP proxy) and has a pretty good (if ad-hoc) command-line documentation.

smtpd is currently using getopt for its options parsing and the argument parsing is very cleanly factored: the port only had to replace the implementation of the `parseargs` function (and add and remove some helpers).

* The port keeps the existing arguments semantics (including the mandatory host:port syntax for the local and remote specs if overridden)

* The port tries to maintain the old error messages, but due to the way argparse works (or the way I used it for the specs) the parity is not perfect when providing incorrect specs

* The CLI help uses argparse's formatting, and the documentation for the local and remote specs was set on these arguments rather than as an epilog. The version string was also removed from the help screen

* Because they are set by argparse's arguments validation, the status codes on incorrect arguments are slightly different:
  - running smtpd.py as a regular user without the `--nosetuid` flag still exits with status 1
  - providing incorrect spec formats (missing or non-int port) or providing too many positional arguments (3 or more) now exits with status 2 (formerly 1)

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: smtpd-to-argparse.diff
keywords: patch
messages: 128917
nosy: barry, docs at python, xmorel
priority: normal
severity: normal
status: open
title: smtpd-as-a-script feature should be documented and should use argparse
versions: Python 3.3
Added file: http://bugs.python.org/file20812/smtpd-to-argparse.diff

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

From report at bugs.python.org  Sun Feb 20 23:07:31 2011
From: report at bugs.python.org (David Phillips)
Date: Sun, 20 Feb 2011 22:07:31 +0000
Subject: [New-bugs-announce] [issue11261] urlopen breaks when data parameter
	is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>


New submission from David Phillips <david.193.phillips at gmail.com>:

The following code works on python 3.1.3 but fails on Python 3.2rc2 (r32rc2:88269, Jan 30 2011, 14:30:28). (I run Mac OS X, version 10.6.6.)

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

import urllib, urllib.request, urllib.error, urllib.parse

form = urllib.parse.urlencode({'field1':'Log in'})
try:
	response = urllib.request.urlopen('http://www.google.com/', form)
except urllib.error.HTTPError as exception:
	print (exception)

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

When loaded, the following error messages are generated:

---------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 1057, in do_request_
    mv = memoryview(data)
TypeError: cannot make memory view because object does not have the buffer interface

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 364, in open
    req = meth(req)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 1062, in do_request_
    data))
ValueError: Content-Length should be specified                                 for iterable data of type <class 'str'> 'field1=Log+in'

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

----------
components: Library (Lib)
messages: 128922
nosy: david193
priority: normal
severity: normal
status: open
title: urlopen breaks when data parameter is used.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb 20 23:28:13 2011
From: report at bugs.python.org (Eugene Morozov)
Date: Sun, 20 Feb 2011 22:28:13 +0000
Subject: [New-bugs-announce] [issue11262] re.sub replaces only first 32
	matches with re.U flag
In-Reply-To: <1298240893.99.0.359755744829.issue11262@psf.upfronthosting.co.za>
Message-ID: <1298240893.99.0.359755744829.issue11262@psf.upfronthosting.co.za>


New submission from Eugene Morozov <eugene.morozov at gmail.com>:

There's a peculiar and difficult to find bug in the re.sub method. Try following example:
>>> text = 'X'*4096
>>> nt = re.sub(u"XX", u".", text, re.U)
>>> nt
u'............XXXXXXXXXXXXXXXXXXX' (only 32 dots, the rest of the string is not changed).

If I first compile regexp, and then perform compiled_regexp.sub, everything seems to work correctly.

----------
components: Regular Expressions
messages: 128923
nosy: Eugene.Morozov
priority: normal
severity: normal
status: open
title: re.sub replaces only first 32 matches with re.U flag
type: security
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 21 00:02:10 2011
From: report at bugs.python.org (Reiner Gerecke)
Date: Sun, 20 Feb 2011 23:02:10 +0000
Subject: [New-bugs-announce] [issue11263] Wrong link to source code of ftplib
In-Reply-To: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>
Message-ID: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>


New submission from Reiner Gerecke <mr.squidd at gmail.com>:

The link to the source code of the ftp module at the top of the documentation (http://docs.python.org/release/3.2/library/ftplib.html) points to a non-existant page.

  **Source code:** :source:`Lib/ftp.py`

It is referencing ftp.py, but needs to be ftplib.py.

----------
assignee: docs at python
components: Documentation
messages: 128926
nosy: Reiner.Gerecke, docs at python
priority: normal
severity: normal
status: open
title: Wrong link to source code of ftplib
versions: Python 3.2, Python 3.3

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

From orsenthil at gmail.com  Mon Feb 21 02:50:54 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 21 Feb 2011 08:50:54 +0700
Subject: [New-bugs-announce] [issue11261] urlopen breaks when data
 parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
References: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
	<1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <20110221015054.GA4234@kevin>

On Sun, Feb 20, 2011 at 10:07:31PM +0000, David Phillips wrote:

> The following code works on python 3.1.3 but fails on Python 3.2rc2
> (r32rc2:88269, Jan 30 2011, 14:30:28). (I run Mac OS X, version
> 10.6.6.)

Is that a real world code? (As in used in production)?  Because,
things have been a bit tightened in 3.2 and it expects data to be
bytes and throws an exception if it is not bytes.

urlencode will output str and you have explicitly encode it to bytes
(Using the value Accept-Encoding response header) before you send the
data to urlopen. The updated docs reflect this change.

From report at bugs.python.org  Mon Feb 21 05:21:12 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 21 Feb 2011 04:21:12 +0000
Subject: [New-bugs-announce] [issue11264] Format Specification Mini-Language
	missing type 'i'?
In-Reply-To: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>
Message-ID: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

The Format Specification Mini-Language is missing type 'i', generally the same as 'd', and ubiquitous in the libraries from which the specification is derived. See the 'd,i' conversion specifier in C: http://linux.die.net/man/3/printf, and the Old String Formatting Operations: http://docs.python.org/dev/py3k/library/stdtypes.html#old-string-formatting-operations.

>>> '{:d}'.format(3)
'3'
>>> '{:i}'.format(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'i' for object of type 'int'

----------
components: Interpreter Core
messages: 128934
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Format Specification Mini-Language missing type 'i'?
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 06:18:52 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:18:52 +0000
Subject: [New-bugs-announce] [issue11265] asyncore does not check for EAGAIN
	errno
In-Reply-To: <1298265532.74.0.854480048578.issue11265@psf.upfronthosting.co.za>
Message-ID: <1298265532.74.0.854480048578.issue11265@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

According to man:
----------------------
ERRORS
       EAGAIN or EWOULDBLOCK
The socket is marked nonblocking and no connections are present to be accepted.  POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities.
-----------------

patch included

----------
components: Library (Lib)
files: z.patch
keywords: patch
messages: 128939
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not check for EAGAIN errno
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20817/z.patch

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

From report at bugs.python.org  Mon Feb 21 06:31:30 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:31:30 +0000
Subject: [New-bugs-announce] [issue11266] asyncore does not handle EINTR in
	recv, send, connect, accept, 
In-Reply-To: <1298266290.98.0.867769013141.issue11266@psf.upfronthosting.co.za>
Message-ID: <1298266290.98.0.867769013141.issue11266@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

in spite of usage of non-blocking IO, syscalls may return EINTR if signal arrive during some syscalls.

It is desirable to re-call syscall after receiving EINTR. Trivial loops should be implemented around (recv, send, connect, accept)

----------
components: Library (Lib)
messages: 128940
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not handle EINTR in recv, send, connect, accept,
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 06:54:32 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:54:32 +0000
Subject: [New-bugs-announce] [issue11267] asyncore does not check for
	POLLERR and POLLHUP if	neither readable nor writable
In-Reply-To: <1298267672.06.0.624805045141.issue11267@psf.upfronthosting.co.za>
Message-ID: <1298267672.06.0.624805045141.issue11267@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asyncore.py: poll2() :
--------------------
if flags:
    # Only check for exceptions if object was either readable
    # or writable.
    flags |= select.POLLERR | select.POLLHUP | select.POLLNVAL
    pollster.register(fd, flags)
--------------------

This is unexpected behaviour. Why descriptor does not get polled if neither read nor write selected ? So I can not track dropping of connection if I do not want neither read nor write. I think "if flags:" should be removed.

----------
components: IO, Library (Lib)
messages: 128941
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not check for POLLERR and POLLHUP if neither readable nor writable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 07:36:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 06:36:03 +0000
Subject: [New-bugs-announce] [issue11268] Mac OS/X installer fails if
	documentation was previously	installed.
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>


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

The 3.2.0 install failed at the documentation step.  I believe this happened because I had already install the release candidate beforehand, so it looks like on of the steps is not checking for existing files.

----------
assignee: ned.deily
components: Installation
messages: 128942
nosy: ned.deily, rhettinger
priority: normal
severity: normal
status: open
title: Mac OS/X installer fails if documentation was previously installed.
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 11:18:23 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Mon, 21 Feb 2011 10:18:23 +0000
Subject: [New-bugs-announce] [issue11269] cgi.FieldStorage forgets to
	unquote field names when	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>


New submission from Sergey Schetinin <sergey at maluke.com>:

Tested on Python 2.7, but probably affects all versions. Test case is attached.

The reason this went unnoticed until now is that browsers are very conservative when quoting field names, so most field names are the same after their quoting.

Related bug in WebOb: https://bitbucket.org/ianb/webob/issue/2

----------
components: Library (Lib)
files: tcgi.py
messages: 128950
nosy: mlk
priority: normal
severity: normal
status: open
title: cgi.FieldStorage forgets to unquote field names when parsing multipart/form-data
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20819/tcgi.py

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

From report at bugs.python.org  Mon Feb 21 14:20:18 2011
From: report at bugs.python.org (Andreas Sauer)
Date: Mon, 21 Feb 2011 13:20:18 +0000
Subject: [New-bugs-announce] [issue11270] logging: RotatingFileHandler crash
	when opening the	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>


New submission from Andreas Sauer <sauerandreas at gmx.de>:

Module: logging
OS: Windows XP

When using the RotatingFileHandler, the logging cras when i open the Logfile in an Texteditor.

I think there is a Problem in renaming the Files, while it's open in the Texteditor.

Traceback (most recent call last):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 76, in emit
    if self.shouldRollover(record):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 150, in shouldRollo
ver
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file

----------
components: Extension Modules
messages: 128960
nosy: RockstarVC
priority: normal
severity: normal
status: open
title: logging: RotatingFileHandler crash when opening the Logfile in an Texteditor
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb 21 16:04:49 2011
From: report at bugs.python.org (Tobias Brink)
Date: Mon, 21 Feb 2011 15:04:49 +0000
Subject: [New-bugs-announce] [issue11271]
	concurrent.futures.ProcessPoolExecutor.map() slower
	than	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>


New submission from Tobias Brink <tobias.brink at gmail.com>:

I tested the new concurrent.futures.ProcessPoolExecutor.map() in 3.2 with the is_prime() function from the documentation example. This was significantly slower than using multiprocessing.Pool.map(). Quick look at the source showed that multiprocessing sends the iterable in chunks to the worker process while futures sends always only one entry of the iterable to the worker.

Functions like is_prime() which finish relatively fast make the communication overhead (at least I guess that is the culprit) very big in comparison.

Attached is a file which demonstrates the problem and a quick workaround.  The workaround uses the chunk idea from multiprocessing.  The problem is that it requires the iterables passed to map() to have a length and be indexable with a slice.  I believe this limitation could be worked around.

----------
components: Library (Lib)
files: map_comparison.py
messages: 128963
nosy: tbrink
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file20825/map_comparison.py

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

From report at bugs.python.org  Mon Feb 21 16:48:24 2011
From: report at bugs.python.org (Duncan Booth)
Date: Mon, 21 Feb 2011 15:48:24 +0000
Subject: [New-bugs-announce] [issue11272] input() has trailing carriage
	return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>


New submission from Duncan Booth <kupuguy at gmail.com>:

In Python 3.2, the builtin function `input()` returns a string with a trailing '\r' on windows:

    C:\Python32>python
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(repr(input()))
    test
    'test\r'
    >>>

This breaks code that expects the string to be stripped, e.g. 'pydoc.py -b' doesn't recognise its commands:

    C:\Python32>python lib\pydoc.py -b
    Server ready at http://localhost:4680/
    Server commands: [b]rowser, [q]uit
    server> q
    Server commands: [b]rowser, [q]uit
    server> b
    Server commands: [b]rowser, [q]uit
    server>

----------
components: Interpreter Core, Windows
messages: 128964
nosy: duncanb
priority: normal
severity: normal
status: open
title: input() has trailing carriage return on windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 21 16:49:23 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 15:49:23 +0000
Subject: [New-bugs-announce] [issue11273] asyncore creates selec (or poll)
	on every iteration
In-Reply-To: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za>
Message-ID: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

select.poll() object or r,w,e arrays for select() should not be built from the start in each iteration.

For performance issue, such objects should be created in loop() function and modified in add_channel/del_channel. As we do not know, what type of event loop (select or poll) will be choosed, we must either build both (bad performance anyway) or create new class:

1. new class a-la "poller" should be created, accepting "map" and "use_poll" parameters. poll() should be moved to poller.poll()
2. The "dispatcher" class should accept "poller" as parameter (not just "map")
3. "add_channel" and "del_channel" should add/remove items in "poller" (select.poll.modify or list.remove for r,w,e)
4. "poller" should have weakref to each controlled "dispatcher" just for unregistering dead dispatchers via weakref callback.

I can create a patch, but will not start until someone approve my idea.

----------
components: Library (Lib)
messages: 128965
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore creates selec (or poll) on every iteration
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 16:50:44 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 15:50:44 +0000
Subject: [New-bugs-announce] [issue11274] asyncore does not support epoll
In-Reply-To: <1298303444.27.0.804622018325.issue11274@psf.upfronthosting.co.za>
Message-ID: <1298303444.27.0.804622018325.issue11274@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

epoll support should be added. Big performance boost on large number of sockets.

----------
components: Library (Lib)
messages: 128966
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not support epoll
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 18:54:39 2011
From: report at bugs.python.org (Hoyt Koepke)
Date: Mon, 21 Feb 2011 17:54:39 +0000
Subject: [New-bugs-announce] [issue11275] Linking to gcc's gomp causes crash
	later.
In-Reply-To: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>
Message-ID: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>


New submission from Hoyt Koepke <hoytak at gmail.com>:

Hello,

I've encountered a strange bug that appears to be either in gcc's gomp
implementation or in how python loads extension modules linked against
gomp.  Here's the error:

Using gcc (multiple versions) on linux, I compile an empty c extension
module and pass -lgomp as a linker arg.  If I import it, running a
simple script in matplotlib causes a segfault.  Not passing -lgomp or
not loading the empty module makes the code works fine.  More
specifically, if I compile:

#include "Python.h"
static struct PyMethodDef methods[] = {
 {0, 0, 0, 0}
};
PyMODINIT_FUNC initempty(void) {
 Py_InitModule4("empty", methods, 0, 0, PYTHON_API_VERSION);
}

using ``ext_modules = [Extension("empty", ["empty.c"], extra_link_args
= ["-lgomp"])]``, then

import empty
import matplotlib.pylab as plt

plt.figure()
plt.plot([0,1], [0,1], '-b')
plt.show()


causes the program to segfault (removing ``import empty`` makes it
fine).  Looking at a traceback:

#0  0x00f78bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x008f51f2 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2  0x008fdd73 in _path_module::update_path_extents (this=0x8e45f90,
args=...) at src/path.cpp:378
#3  0x009048bd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8e9ae30, args=...) at
./CXX/Python2/ExtensionModule.hxx:184
#4  0x008f0d96 in method_varargs_call_handler
(_self_and_name_tuple=0x8e6eeac, _args=0x94e683c) at
CXX/Python2/cxx_extensions.cxx:1714
#5  0x080dc0d0 in PyEval_EvalFrameEx ()
#6  0x080dddf2 in PyEval_EvalCodeEx ()

While occurring in some of matplotlib's extension code (and I haven't
found another library that crashes it), the fact that the deciding
factor is whether I link against gomp indicates the it's probably
upstream somewhere.

I encountered this error a year ago and asked about it on the
matplotlib mailing list, but found a quick workaround then, and with
deadline pressure I forgot about it.  However, it's come up again, and
then I was asked to bump it to python-dev, which is why I'm posting it
here.

I can reproduce it on the following systems.  In all cases, matplotlib
is compiled from source on the development branch (r8969) and uses
QT4Agg as the backend, as is numpy, scipy, etc.  If needed, I can
track down more versions.

gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.4, 64bit, Python 2.6.6, ubuntu 10.10
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64bit, Python 2.6.5, ubuntu 10.04
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, 32bit, Python 2.6.4, ubuntu 9.10

gcc 4.5.2 (source build), Python 2.6.5, ubuntu 10.04.  On this build,
the given source example does not produce the result, and I haven't
been able to tweak it so it does.  However, linking to a much larger
extension library that uses many different parts of openmp causes
exactly the same crash.  If I recompile that library without openmp
support, then everything works fine; with openmp support it corrupts
something and matplotlib crashes in exactly the same way.

gcc 4.3.2, Python 2.6.2, ubuntu 9.04 (I don't have access to this
system any more, since it got upgraded, but it had the same problem a
year ago).

I attached example code that reproduces it.  

Thanks,

--Hoyt

----------
components: Extension Modules
files: python-gomp-bug.tar.gz
messages: 128974
nosy: hoytak
priority: normal
severity: normal
status: open
title: Linking to gcc's gomp causes crash later.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file20827/python-gomp-bug.tar.gz

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

From report at bugs.python.org  Mon Feb 21 21:32:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Feb 2011 20:32:50 +0000
Subject: [New-bugs-announce] [issue11276] 2to3: imports fixer doesn't update
	references to modules	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ cat test.py
import cPickle
cPickle
cPickle.load
$ 2to3 -f imports test.py
RefactoringTool: Refactored test.py
--- test.py     (original)
+++ test.py     (refactored)
@@ -1,3 +1,3 @@
-import cPickle
+import pickle
 cPickle
-cPickle.load
+pickle.load
RefactoringTool: Files that need to be modified:
RefactoringTool: test.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128991
nosy: Arfrever
priority: normal
severity: normal
status: open
title: 2to3: imports fixer doesn't update references to modules specified without attributes
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 21 23:13:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 22:13:15 +0000
Subject: [New-bugs-announce] [issue11277] test_zlib crashes under Snow
	Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>


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

Following r88460 (issue10276), test_zlib crashes on the Snow Leopard buildbot (apparently in the new "test_big_buffer" test case).

----------
messages: 129002
nosy: ixokai, ned.deily, pitrou
priority: critical
severity: normal
status: open
title: test_zlib crashes under Snow Leopard buildbot
type: crash
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Feb 22 01:47:04 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Tue, 22 Feb 2011 00:47:04 +0000
Subject: [New-bugs-announce] [issue11278] raw_input() and input() not
	stripping EOL on win32
In-Reply-To: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>
Message-ID: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>


New submission from Dave Flogeras <dflogeras2 at gmail.com>:

>From the python prompt, raw_input() (2.7.1) and input (3.2.0) behave as documented (they strip the trailing EOL chars)

However the two line test program:
x = raw_input() # or input() in 3.2.x
print( repr( x ))

And then run from the command line prompt, .\test.py, shows 'mytest\r' including the EOL char.

----------
messages: 129017
nosy: Dave.Flogeras
priority: normal
severity: normal
status: open
title: raw_input() and input() not stripping EOL on win32
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb 22 01:55:44 2011
From: report at bugs.python.org (Peter Bray)
Date: Tue, 22 Feb 2011 00:55:44 +0000
Subject: [New-bugs-announce] [issue11279] test_posix and lack of "id -G"
	support - less noise	required?
In-Reply-To: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>
Message-ID: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>


New submission from Peter Bray <pdb_ml at yahoo.com.au>:

Solaris 10's id(1M) does not support the "-G" option, so we get the following:

% ./python -m test test_posix 
[1/1] test_posix
id: illegal option -- G
Usage: id [-ap] [user]
1 test OK.

The code already tests that id -G (std) output, and assumes that id -G is not supported if the output is empty. 

QUESTION: Does the user compiling the code need to see the stderr output of id? After all the test is correctly skipped.

Fix:
% diff ./Lib/test/test_posix.py.FCS ./Lib/test/test_posix.py
378c378
<         with os.popen('id -G') as idg:
---
>         with os.popen('id -G 2> /dev/null') as idg:

Consideration: Lib/platform.py has introduced DEV_NULL but it does not seem to be used in other code or tests (beside platform.py).

Regards,

Peter

----------
components: Tests
messages: 129021
nosy: illumino
priority: normal
severity: normal
status: open
title: test_posix and lack of "id -G" support - less noise required?
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 22 03:22:29 2011
From: report at bugs.python.org (Andres Riancho)
Date: Tue, 22 Feb 2011 02:22:29 +0000
Subject: [New-bugs-announce] [issue11280] urllib2 http_error_302 calls
	undefined "getheaders"	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>


New submission from Andres Riancho <andres.riancho at gmail.com>:

Buggy Code:

"""
    def http_error_302(self, req, fp, code, msg, headers):
        # Some servers (incorrectly) return multiple Location headers
        # (so probably same goes for URI).  Use first header.
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return
"""

The getheaders method is not be defined for the headers parameter, which is a dict object. This seems to be a mistake with the HTTPResponse.  getheaders function that's defined in httplib.py


Fixed Code:

"""
    def http_error_302(self, req, fp, code, msg, headers):
        # Some servers (incorrectly) return multiple Location headers
        # (so probably same goes for URI).  Use first header.
        if 'location' in headers:
            newurl = headers.get('location')
        elif 'uri' in headers:
            newurl = headers.get('uri')
        else:
            return
"""

----------
components: Extension Modules
messages: 129026
nosy: Andres.Riancho
priority: normal
severity: normal
status: open
title: urllib2 http_error_302 calls undefined "getheaders" method
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb 22 05:10:55 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 04:10:55 +0000
Subject: [New-bugs-announce] [issue11281] smtplib: add ability to bind to
	specific source IP	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>


New submission from Paulo Scardine <paulo at scardine.com.br>:

In smtplib there is now way to bind to an specific source address on a machine with multiple interfaces; also, there no way to control the source port for the connection.

Since 2.7, socket.create_connection accepts a source_address parameter, a (host, port) tuple for the socket to bind to as its source address before connecting. If host or port are '' or 0 respectively the OS default behavior will be used.

I would like to add source_ip and source_port parameters to smtplib.SMTP, default to '' and 0 respectively.

It is a small change with no impact over existing code. Should I submit a patch?

----------
components: Library (Lib)
messages: 129035
nosy: paulos
priority: normal
severity: normal
status: open
title: smtplib: add ability to bind to specific source IP address/port
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 22 07:09:59 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 06:09:59 +0000
Subject: [New-bugs-announce] [issue11282] unittest document not keep consist
	with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

r88451:
Remove unittest methods scheduled for removal in 3.3

This commit remove assertSameElements() and assertDictContainsSubset(). But shouldn't some modification be done in the unittest library documentation? I wonder if we should remove the docs about the two methods. Now the doc only said "Deprecated since version 3.2."

----------
assignee: docs at python
components: Documentation
messages: 129036
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: unittest document not keep consist with code
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 22 09:48:20 2011
From: report at bugs.python.org (wesley chun)
Date: Tue, 22 Feb 2011 08:48:20 +0000
Subject: [New-bugs-announce] [issue11283] incorrect pattern in the re module
	docs for conditional	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>


New submission from wesley chun <wescpy at gmail.com>:

In the re docs, it states the following for the conditional regular expression syntax:

(?(id/name)yes-pattern|no-pattern)
Will try to match with yes-pattern if the group with given id or name exists, and with no-pattern if it doesn?t. no-pattern is optional and can be omitted. For example, (<)?(\w+@\w+(?:\.\w+)+)(?(1)>) is a poor email matching pattern, which will match with '<user at host.com>' as well as 'user at host.com', but not with '<user at host.com'.

this regex is incomplete as it allows for 'user at host.com>':

>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', '<user at host.com>'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', 'user at host.com'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', '<user at host.com'))
False
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', 'user at host.com>'))
True

This error has existed since this feature was added in 2.4...
http://docs.python.org/release/2.4.4/lib/re-syntax.html

... through the 3.3. docs...
http://docs.python.org/dev/py3k/library/re.html#regular-expression-syntax

The fix is to add the end char '$' to the regex to get all 4 working:


>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', '<user at host.com>'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', 'user at host.com'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', '<user at host.com'))
False
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', 'user at host.com>'))
False

If accepted, I propose this patch (also attached):

$ svn diff re.rst
Index: re.rst
===================================================================
--- re.rst      (revision 88499)
+++ re.rst      (working copy)
@@ -297,9 +297,9 @@
 ``(?(id/name)yes-pattern|no-pattern)``
    Will try to match with ``yes-pattern`` if the group with given *id* or *name*
    exists, and with ``no-pattern`` if it doesn't. ``no-pattern`` is optional and
-   can be omitted. For example,  ``(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)`` is a poor email
+   can be omitted. For example,  ``(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)`` is a poor email
    matching pattern, which will match with ``'<user at host.com>'`` as well as
-   ``'user at host.com'``, but not with ``'<user at host.com'``.
+   ``'user at host.com'``, but not with ``'<user at host.com'`` nor ``'user at host.com>'`` .

----------
assignee: docs at python
components: Documentation, Regular Expressions
files: re.rst
messages: 129041
nosy: docs at python, wesley.chun
priority: normal
severity: normal
status: open
title: incorrect pattern in the re module docs for conditional regex
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20833/re.rst

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

From report at bugs.python.org  Tue Feb 22 10:38:11 2011
From: report at bugs.python.org (s7v7nislands)
Date: Tue, 22 Feb 2011 09:38:11 +0000
Subject: [New-bugs-announce] [issue11284] slow close file descriptors in
	subprocess, popen2, os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>


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

when use popen*() and close_fds is True, python will close unused fds. but the MAXFD is not the real max. especially in freebsd, subprocess.MAXFD=655000. so python will try to close to many fd, it's too slow, in my test on freebsd, using about 3 seconds.

poor english.

patch for 2.7 trunck:
jiangxiaobing at s7v7nislands ~/source/svn/python27 $ svn diff
Index: Lib/subprocess.py
===================================================================
--- Lib/subprocess.py	(revision 88499)
+++ Lib/subprocess.py	(working copy)
@@ -1065,11 +1065,16 @@
 
 
         def _close_fds(self, but):
+            maxfd = MAX_FD
+            try:
+                maxfd = os.dup(0) + 1
+            except:
+                pass
             if hasattr(os, 'closerange'):
                 os.closerange(3, but)
-                os.closerange(but + 1, MAXFD)
+                os.closerange(but + 1, maxfd)
             else:
-                for i in xrange(3, MAXFD):
+                for i in xrange(3, maxfd):
                     if i == but:
                         continue
                     try:
Index: Lib/popen2.py
===================================================================
--- Lib/popen2.py	(revision 88499)
+++ Lib/popen2.py	(working copy)
@@ -82,8 +82,13 @@
     def _run_child(self, cmd):
         if isinstance(cmd, basestring):
             cmd = ['/bin/sh', '-c', cmd]
-        os.closerange(3, MAXFD)
+        maxfd = MAXFD
         try:
+            maxfd = os.dup(0) + 1
+        except:
+            pass
+        os.closerange(3, maxfd)
+        try:
             os.execvp(cmd[0], cmd)
         finally:
             os._exit(1)



patch for 3.3 truck:
diff --git a/Lib/subprocess.py b/Lib/subprocess.py
index c02fb52..98a25b3 100644
--- a/Lib/subprocess.py
+++ b/Lib/subprocess.py
@@ -1112,8 +1112,14 @@ class Popen(object):
                 if fd >= start_fd:
                     os.closerange(start_fd, fd)
                     start_fd = fd + 1
-            if start_fd <= MAXFD:
-                os.closerange(start_fd, MAXFD)
+            maxfd = MAXFD
+            try:
+                maxfd = os.dup(0) + 1
+            except:
+                pass
+
+            if start_fd <= maxfd:
+                os.closerange(start_fd, maxfd)
 
 
         def _execute_child(self, args, executable, preexec_fn, close_fds,

----------
components: Library (Lib)
files: py3k.patch
keywords: patch
messages: 129043
nosy: s7v7nislands
priority: normal
severity: normal
status: open
title: slow close file descriptors in subprocess, popen2, os.pepen*
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20834/py3k.patch

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

From report at bugs.python.org  Tue Feb 22 13:49:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:49:08 +0000
Subject: [New-bugs-announce] [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Just pulled 64380ee4bbc5 (r88500) and compiled, Python's busted:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/io.py", line 60, in <module>
Abort trap

----------
components: IO
messages: 129065
nosy: sdaoden
priority: normal
severity: normal
status: open
title: io.py standart stream setup crash
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 22 14:56:10 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Feb 2011 13:56:10 +0000
Subject: [New-bugs-announce] [issue11286] Some "trivial" python 2.x pickles
	fails to load in	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

I have 10MB pickled structure generated in Python 2.7. I only use basic
types (no clases) like sets, dictionaries, lists, strings, etc.

The pickle stores a lot of strings. Some of them should be "bytes",
while other should be "unicode". My idea is to import ALL the strings as
bytes in Python 3.2 and navigate the data structure to convert the
appropiate values to unicode, in a one-time operation (I version the
structure, so I can know if this conversion is already done, simply
storing a new version value).

But I get this error:

"""
Python 3.2 (r32:88445, Feb 21 2011, 13:34:07)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> >>> f=open("file.pickle", mode="rb").read()
>>> >>> len(f)
9847316
>>> >>> b=pickle.loads(f,encoding="latin1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object
"""

I use the encoding "latin1" for transparent byte/unicode conversion (do
not touch the values!).

This seems to be a bug in Python 3.2. Any suggestion?.

The bytestream is protocol 2.


PYTHON 3.1.3 loads the pickle just fine.

Trying to generate a testcase. I can't upload the pickle, because it contains propietary information.

----------
components: Library (Lib)
messages: 129075
nosy: georg.brandl, jcea
priority: release blocker
severity: normal
stage: test needed
status: open
title: Some "trivial" python 2.x pickles fails to load in Python 3.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 22 14:58:26 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 13:58:26 +0000
Subject: [New-bugs-announce] [issue11287] Add context manager support to dbm
	modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

dbm objects, including gdbm, ndbm, dumb, should support context manager. That is, can be used with 'with' keyword, just like regular file objects.

I'm working out a patch for this.

----------
components: Extension Modules
messages: 129076
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: Add context manager support to dbm modules
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 22 16:41:58 2011
From: report at bugs.python.org (Matthew Funke)
Date: Tue, 22 Feb 2011 15:41:58 +0000
Subject: [New-bugs-announce] [issue11288] Python installed from MSI doesn't
	work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>


New submission from Matthew Funke <go4tli at gmail.com>:

I uninstalled Python 3.1.3 and installed the 32-bit version of Python 3.2 on my 64-bit Win7 box.  (My favorite IDE requires the 32-bit version.)  trying to run IDLE crashes; running C:\python32\python.exe returns this error:

Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I tried Googling the error, but couldn't find much help for it.  Thoughts?

----------
components: IDLE, Windows
messages: 129088
nosy: Matthew.Funke
priority: normal
severity: normal
status: open
title: Python installed from MSI doesn't work
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 22 18:05:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:05:06 +0000
Subject: [New-bugs-announce] [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment provides a context manager for SMTP class so that it can be used with the "with" statement.

----------
messages: 129096
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: smtplib context manager
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 22 18:05:25 2011
From: report at bugs.python.org (Clayton Darwin)
Date: Tue, 22 Feb 2011 17:05:25 +0000
Subject: [New-bugs-announce] [issue11290] ttk.Combobox['values'] String
	Conversion to Tcl
In-Reply-To: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>
Message-ID: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>


New submission from Clayton Darwin <claytondarwin at gmail.com>:

In working with the ttk.Combobox (Windows XP, Python 3.1), I have found that setting the values for the popdown using ttk.Combobox['values'] has an problem converting the string to the proper Tcl value when (and this is the only instance I have found) there is a backslash in the string but no spaces.  In this case, the string will translate if it is enclosed in curly brackets '{'+mystring+'}', which I believe is the Tcl syntax to not make substitutions.

I have attached a short script that illustrates this issue.

Clayton

----------
components: Tkinter
files: tcl_string_test.py
messages: 129097
nosy: claytondarwin
priority: normal
severity: normal
status: open
title: ttk.Combobox['values'] String Conversion to Tcl
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file20843/tcl_string_test.py

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

From report at bugs.python.org  Tue Feb 22 20:52:41 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 19:52:41 +0000
Subject: [New-bugs-announce] [issue11291] poplib suppresses exception on QUIT
In-Reply-To: <1298404361.7.0.353311049952.issue11291@psf.upfronthosting.co.za>
Message-ID: <1298404361.7.0.353311049952.issue11291@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Unlike ftplib, smtplib and probably others, poplib suppresses error_proto exceptions on quit().
I'm not sure in what circumstances a POP3 server can return a negative response on QUIT but if this happens poplib should raise an exception.
Users who don't care about QUIT response can use the new close() method.
For backward compatibility patch should only be applied to Python 3.3 .

----------
files: poplib_quit.patch
keywords: patch
messages: 129114
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib suppresses exception on QUIT
versions: Python 3.3
Added file: http://bugs.python.org/file20846/poplib_quit.patch

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

From report at bugs.python.org  Tue Feb 22 21:25:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 20:25:50 +0000
Subject: [New-bugs-announce] [issue11292] Curses - add A_REVERSE to
	attributes table
In-Reply-To: <1298406350.63.0.533877508283.issue11292@psf.upfronthosting.co.za>
Message-ID: <1298406350.63.0.533877508283.issue11292@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003142.html here's a patch to add A_REVERSE attribute to attribs table.

----------
assignee: sandro.tosi
components: Documentation
files: add-a_reverse-py3k.patch
keywords: patch
messages: 129121
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Curses - add A_REVERSE to attributes table
versions: Python 3.3
Added file: http://bugs.python.org/file20849/add-a_reverse-py3k.patch

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

From report at bugs.python.org  Tue Feb 22 21:57:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 20:57:42 +0000
Subject: [New-bugs-announce] [issue11293] Distutils - read the file when
	using it in	long_description
In-Reply-To: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>
Message-ID: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003087.html here's a patch to read the contents of the file for long_description.

----------
assignee: sandro.tosi
components: Documentation
files: distutils-read-longdescr-file-py3k.patch
keywords: patch
messages: 129127
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Distutils - read the file when using it in long_description
versions: Python 3.3
Added file: http://bugs.python.org/file20850/distutils-read-longdescr-file-py3k.patch

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

From report at bugs.python.org  Tue Feb 22 23:20:44 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 22:20:44 +0000
Subject: [New-bugs-announce] [issue11294] Locale - update & uniform
	ERA_*_FMT doc
In-Reply-To: <1298413244.48.0.422350536879.issue11294@psf.upfronthosting.co.za>
Message-ID: <1298413244.48.0.422350536879.issue11294@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003004.html here's a patch to:

- clarify ERA_D_FMT is for date
- uniform the way {ERA_}<tag> descriptions are written (are not a native to know if it's better 'a date' or 'dates' (same goes for 'time'))
- add ERA_T_FMT

----------
assignee: sandro.tosi
components: Documentation
files: locale_era_dt-py3k.patch
keywords: patch
messages: 129139
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Locale - update & uniform ERA_*_FMT doc
versions: Python 3.3
Added file: http://bugs.python.org/file20851/locale_era_dt-py3k.patch

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

From report at bugs.python.org  Wed Feb 23 01:22:26 2011
From: report at bugs.python.org (Jonathan Hayward)
Date: Wed, 23 Feb 2011 00:22:26 +0000
Subject: [New-bugs-announce] [issue11295] On Windows,
	Python crashes on ANSI / Windows-formatted source files
In-Reply-To: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>
Message-ID: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>


New submission from Jonathan Hayward <jonathan.hayward at pobox.com>:

So far as I can tell, Python 2.7 crashes on at least some ANSI / Windows \r\n-delimited source files. More specifically, as invoked by Apache as a CGI script, the source file line:

import cgi

generated an error logged by Apache, complaining that the module "cgi\r" couldn't be imported.

Email sent as follows:

--

Today I was visiting with a friend and installing OSS on his computer. On an x86_64 Windows 7 box, he had already installed Apache, and I installed Python with a python.org installer. I opened up Notepad and created a "Hello world" Python CGI script, put it in the cgi-bin directory, saw it crash, and looked in the logs.

The log message complained that I had tried to "import cgi\r": in other words, Python on Windows was choking because the file I made in Notepad used "\r\n" for line breaks. (The equivalent script made with vim, and presumably "\n" for line breaks worked predictably.)

Isn't it a defect/design flaw for Python on Windows to choke on "\r\n"-separated files? Should I file a bug, or is this a side effect of decisions that are now non-negotiable? (I wasn't thrilled, after trying to sell my friend on the idea that Python is a good language with a low barrier to entry, to find that it choked on a Notepad-edited "Hello world!" CGI script.)

----------
components: Interpreter Core
messages: 129142
nosy: JonathanHayward
priority: normal
severity: normal
status: open
title: On Windows, Python crashes on ANSI / Windows-formatted source files
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 23 02:10:29 2011
From: report at bugs.python.org (Carl Chenet)
Date: Wed, 23 Feb 2011 01:10:29 +0000
Subject: [New-bugs-announce] [issue11296] Possible error in What's new in
	Python 3.2 : duplication	of rsplit() mention
In-Reply-To: <1298423429.64.0.239185638784.issue11296@psf.upfronthosting.co.za>
Message-ID: <1298423429.64.0.239185638784.issue11296@psf.upfronthosting.co.za>


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

Hi,

Could the rsplit() method be mentioned mistakenly two times in the following sentence of the current What's new in Python 3.2 ?

"The fast-search algorithm in stringlib is now used by the split(), rsplit(), splitlines() and replace() methods on bytes, bytearray and str objects. Likewise, the algorithm is also used by rfind(), rindex(), rsplit() and rpartition()."

Regards,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 129146
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: Possible error in What's new in Python 3.2 : duplication of rsplit() mention
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 23 11:22:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2011 10:22:36 +0000
Subject: [New-bugs-announce] [issue11297] Make ChainMap() public in the
	collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>


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

Attaching a documentation patch.

----------
assignee: rhettinger
files: chainmap.diff
keywords: patch
messages: 129161
nosy: rhettinger
priority: low
severity: normal
status: open
title: Make ChainMap() public in the collections module.
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20858/chainmap.diff

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

From report at bugs.python.org  Wed Feb 23 12:42:53 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 11:42:53 +0000
Subject: [New-bugs-announce] [issue11298] unittest discovery needs better
	explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>


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

`python -m unittest discover` caught me out. 

I had a test module called `test-foo.py` and no test was loaded.

When I renamed to `test_foo.py` it worked.

The documentation says "For a project?s tests to be compatible with test discovery they must all be importable".

I didn't realise that test-foo would not be importable. Could the documentation say "For a project?s tests to be compatible with test discovery they must all be importable, so ensure that the module names are valid Python identifiers."

Stackoverflow question is here: http://stackoverflow.com/questions/5088960/python-unittest-discovery-does-not-discover-tests

----------
assignee: docs at python
components: Documentation
messages: 129176
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: unittest discovery needs better explanation
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb 23 17:15:39 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 16:15:39 +0000
Subject: [New-bugs-announce] [issue11299] Allow deepcopying and pickling
	paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Please allow to deepcopy and to pickle paused generators, including all their state.

This is implemented in Pypy:

	Python 2.5.2 (335e875cb0fe, Dec 28 2010, 20:31:56)
	[PyPy 1.4.1] on win32
	Type "copyright", "credits" or "license()" for more information.
	DreamPie 1.1.1
	>>> import pickle, copy
	>>> def next(thing): # For compatibility
	...     return thing.next()
	>>> def g():
	...     for i in range(4):
	...         yield i
	>>> list(g())
	[0, 1, 2, 3]
	>>> live_generator = g()
	>>> next(live_generator)
	0
	>>> next(live_generator)
	1
	
Now `live_generator` holds a generator which is in the middle of its operation. It went through 0 and 1, and it still has 2 and 3 to yield.

We deepcopy it:	
	
	>>> live_generator_deepcopy = copy.deepcopy(live_generator)
	
The deepcopied generator assumes the same state of the original one. Let's exhaust it:	
	
	>>> list(live_generator_deepcopy)
	[2, 3]
	>>> list(live_generator_deepcopy)
	[]
	
Pypy also lets us pickle and unpickle the live generator:
	
	>>> live_generator_pickled = pickle.dumps(live_generator)
	>>> live_generator_unpickled = pickle.loads(live_generator_pickled)
	>>> list(live_generator_unpickled)
	[2, 3]
	>>> list(live_generator_unpickled)
	[]
	
And the original live generator was unchanged by all these operations:
	
	>>> list(live_generator)
	[2, 3]
	>>> list(live_generator)
	[]
	
All the above was demonstrated in Pypy. In Python 3.2, trying to pickle a live generator raises this exception:

	>>> pickle.dumps(live_generator)
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	_pickle.PicklingError: Can't pickle <class 'generator'>: attribute lookup builtins.generator failed

And trying to deepcopy one raises this exception:
	
	>>> copy.deepcopy(live_generator)
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	  File "c:\Python32\lib\copy.py", line 174, in deepcopy
		y = _reconstruct(x, rv, 1, memo)
	  File "c:\Python32\lib\copy.py", line 285, in _reconstruct
		y = callable(*args)
	  File "c:\Python32\lib\copyreg.py", line 88, in __newobj__
		return cls.__new__(cls, *args)
	TypeError: object.__new__(generator) is not safe, use generator.__new__()

It would be nice if Python 3.2 could pickle and deepcopy live generators.

----------
components: Library (Lib)
messages: 129213
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow deepcopying and pickling paused generators
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 23 21:34:52 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 20:34:52 +0000
Subject: [New-bugs-announce] [issue11300] mmap() large file failures on Mac
	OS X docfix
In-Reply-To: <1298493292.2.0.2203680343.issue11300@psf.upfronthosting.co.za>
Message-ID: <1298493292.2.0.2203680343.issue11300@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Issue 11277 was closed upon the generally accepted conclusion that the failure is that mmap(2) on Mac OS X has a long time known bug (see msg129107, or directly http://lists.apple.com/archives/darwin-development/2003/Jun/msg00141.html).

Issue 11277 fixed the problem in the test suite, but it does give end-users no hint that such a problem exists (on the documentation side).  And it's my believe that a beginner or even a non-low-level programmer may be lost in an equal situation.  (Though one could argue that such a HE should not use mmap(2), but everyone has a first-time somewhen, say.)

In addition, there are many people who don't have the chance to work/test on multiple operating systems and/or hardware, and who need the hand of people who are experienced and can give hints on stupidiness or however this word is correctly spelled.  (Am i preaching already?)

Because Python is expected to be a user-friendly language i do request a documentation patch which gives a hint.  I'll apply a patch, but i'm somewhat new to Python and rST etc., so it surely needs a hand.  (Maybe even its speech is too aggressive??)

----------
assignee: docs at python
components: Documentation
files: doc_lib_mmap.patch
keywords: patch
messages: 129221
nosy: docs at python, sdaoden
priority: normal
severity: normal
status: open
title: mmap() large file failures on Mac OS X docfix
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20867/doc_lib_mmap.patch

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

From report at bugs.python.org  Wed Feb 23 21:50:27 2011
From: report at bugs.python.org (Mike Cencula)
Date: Wed, 23 Feb 2011 20:50:27 +0000
Subject: [New-bugs-announce] [issue11301] cookielib.LWPCookieJar.save()
	doesn't save cookies
In-Reply-To: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>
Message-ID: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>


New submission from Mike Cencula <mike at cencula.com>:

I'm trying to use cookielib.LWPCookieJar.save() to save cookies from a website.  The cookie file is created with a header line, but the cookies are not stored.  Example program attached.

Python version:
2.5.2 (r252:60911, Jan 24 2010, 14:53:14)

Running on Debian lenny as a guest on Virtualbox

Output from the attached file pasted below:
------------
mike at debian:~$ python cookieexample2.py
Here are the headers of the page :
Server: none
Content-Type: text/html
Pragma: no-cache
Cache-Control: no-cache
Expires: Tue, 04 Dec 1993 21:29:02 GMT
Vary: Accept-Encoding
Date: Wed, 23 Feb 2011 20:43:55 GMT
Transfer-Encoding:  chunked
Connection: close
Connection: Transfer-Encoding


These are the cookies we have received so far :
0   :   <Cookie BIGipServerdiy_pool=604317450.20480.0000 for www.diy.co.uk/>
1   :   <Cookie BIGipServerdiy_pool=637871882.20480.0000 for www.diy.com/>
2   :   <Cookie DYN_USER_CONFIRM=1ab776eae0bf5661a2955c6ec7858439 for www.diy.com/>
3   :   <Cookie DYN_USER_ID=1619150879 for www.diy.com/>
4   :   <Cookie JSESSIONID=OVHJMMEHW4LOQCRHAWVCFFIKE2C0YIV0 for www.diy.com/>
mike at debian:~$

Contents of cookie.lwp afterward:
------------
mike at debian:~$ cat cookies.lwp
#LWP-Cookies-2.0
mike at debian:~$

Behavior is nearly identical using cookielib.MozillaCookieJar except the headers are different in the saved cookie file.  Cookies themselves are not saved.

I am new to Python, so I hope this is not user error.

----------
components: Library (Lib)
files: cookieexample2.py
messages: 129223
nosy: mcencula
priority: normal
severity: normal
status: open
title: cookielib.LWPCookieJar.save() doesn't save cookies
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file20868/cookieexample2.py

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

From report at bugs.python.org  Wed Feb 23 22:27:37 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Wed, 23 Feb 2011 21:27:37 +0000
Subject: [New-bugs-announce] [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

While working to improve pypy's compliance with cpython2.7
I added more tests to the ast module test suite.

They may be of interest here too...

----------
components: Tests
files: add-more-tests-for-ast_py.patch
keywords: patch
messages: 129225
nosy: vincele
priority: normal
severity: normal
status: open
title: Add more tests to test_ast.py
versions: Python 2.7
Added file: http://bugs.python.org/file20869/add-more-tests-for-ast_py.patch

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

From report at bugs.python.org  Wed Feb 23 23:34:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 22:34:58 +0000
Subject: [New-bugs-announce] [issue11303] b'x'.decode('latin1') is much
	slower than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ ./python.exe -m timeit "b'x'.decode('latin1')"
100000 loops, best of 3: 2.57 usec per loop
$ ./python.exe -m timeit "b'x'.decode('latin-1')"
1000000 loops, best of 3: 0.336 usec per loop

The reason for this behavior is that 'latin-1' is short-circuited in C code while 'latin1' has to be looked up in aliases.py.  Attached patch fixes this issue.

----------
files: latin1.diff
keywords: patch
messages: 129227
nosy: belopolsky, lemburg
priority: normal
severity: normal
status: open
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')
type: performance
Added file: http://bugs.python.org/file20871/latin1.diff

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

From report at bugs.python.org  Wed Feb 23 23:58:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 22:58:11 +0000
Subject: [New-bugs-announce] [issue11304] Input/output tutorial - PI is
	rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-January/002974.html here's a patch to fix it.

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 129228
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Input/output tutorial - PI is rounded not truncated
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 24 03:19:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Feb 2011 02:19:52 +0000
Subject: [New-bugs-announce] [issue11305] TextIOWrapper.readline and
	str.splitlines have different	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>


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

For example:
>>> 'print 1\n\x0cprint 2\n\n'.splitlines()
['print 1\n', '\x0cprint 2\n', '\n']
>>> list(io.StringIO('print 1\n\x0cprint 2\n\n'))


I'm not sure which is preferable.

----------
components: IO, Interpreter Core
messages: 129240
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: TextIOWrapper.readline and str.splitlines have different behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 24 08:03:32 2011
From: report at bugs.python.org (Matt Johnston)
Date: Thu, 24 Feb 2011 07:03:32 +0000
Subject: [New-bugs-announce] [issue11306] mailbox should test for errno.EROFS
In-Reply-To: <1298531012.94.0.719284706533.issue11306@psf.upfronthosting.co.za>
Message-ID: <1298531012.94.0.719284706533.issue11306@psf.upfronthosting.co.za>


New submission from Matt Johnston <matt at ucc.asn.au>:

When opening mailboxes the module checks for errno.EACCES. This doesn't help if the location is mounted read-only. Something like the following (against Python 2.6) would fix it, there are a few other checks in mailbox.py for EACCES too.

--- mailbox.py.orig	2011-02-24 15:02:22.000000000 +0800
+++ mailbox.py	2011-02-24 15:02:05.000000000 +0800
@@ -512,7 +512,7 @@ class _singlefileMailbox(Mailbox):
                     f = open(self._path, 'wb+')
                 else:
                     raise NoSuchMailboxError(self._path)
-            elif e.errno == errno.EACCES:
+            elif e.errno == errno.EACCES or e.errno == errno.EROFS:
                 f = open(self._path, 'rb')
             else:
                 raise

----------
components: Library (Lib)
messages: 129252
nosy: matt
priority: normal
severity: normal
status: open
title: mailbox should test for errno.EROFS
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 24 13:57:47 2011
From: report at bugs.python.org (Niko Matsakis)
Date: Thu, 24 Feb 2011 12:57:47 +0000
Subject: [New-bugs-announce] [issue11307] re engine exhaustively explores
	more than necessary
In-Reply-To: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>
Message-ID: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>


New submission from Niko Matsakis <niko at alum.mit.edu>:

Executing code like this:

>>> r = re.compile(r'(\w+)*=.*')
>>> r.match("abcdefghijklmnopqrstuvwxyz")

takes a long time (around 12 seconds, on my machine).  Presumably this is because it is enumerating all the various ways to divvy up the alphabet for (\w+), even though there is no "=" sign to be found.  In contrast, in perl a regular expression like that seems to run instantly.

This could be optimized by recognizing that no "=" sign was found, and thus it does not matter how the first part of the regular expression matches, so there is no need to try additional possibilities.  To some extent, of course, the answer is just "don't write regular expressions like that."  This example is reduced down from a real regexp where the potential inefficiency was less obvious.  Nonetheless the general optimization of recognizing when further re-enumeration is not necessary makes sense more generally.

In any case, I am submitting the bug report merely to raise the issue as a possible future optimization, not to suggest that it must be addressed immediately (or even at all).

----------
components: Regular Expressions
messages: 129262
nosy: nikomatsakis
priority: normal
severity: normal
status: open
title: re engine exhaustively explores more than necessary
type: performance
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Feb 24 15:42:44 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Feb 2011 14:42:44 +0000
Subject: [New-bugs-announce] [issue11308] extraneous link getit in the main
	website sidebar
In-Reply-To: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>
Message-ID: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

There is an extraneous entry in sidebar of the www.python.org
It has some two chinese characters and leads to download page.

----------
messages: 129264
nosy: SilentGhost
priority: normal
severity: normal
status: open
title: extraneous link getit in the main website sidebar

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

From report at bugs.python.org  Thu Feb 24 15:51:44 2011
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Thu, 24 Feb 2011 14:51:44 +0000
Subject: [New-bugs-announce] [issue11309] #include <wctype.h> in
	Objects/unicodetype_db.h and	Objects/unicodectype.c
In-Reply-To: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>
Message-ID: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

As of python 2.7.1 configured with "--enable-ipv6 --enable-unicode --with-system-expat --with-system-ffi --with-signal-module --with-threads --with-wctype-functions --enable-shared":

Please #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c

compilation produces the warnings:

In file included from Objects/unicodectype.c:34:0:
Objects/unicodetype_db.h: In function '_PyUnicodeUCS2_IsWhitespace':
Objects/unicodetype_db.h:3277:5: warning: implicit declaration of function 'iswspace'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsLowercase':
Objects/unicodectype.c:192:5: warning: implicit declaration of function 'iswlower'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsUppercase':
Objects/unicodectype.c:197:5: warning: implicit declaration of function 'iswupper'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToLowercase':
Objects/unicodectype.c:202:5: warning: implicit declaration of function 'towlower'
Objects/unicodectype.c:202:12: warning: incompatible implicit declaration of built-in function 'towlower'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToUppercase':
Objects/unicodectype.c:207:5: warning: implicit declaration of function 'towupper'
Objects/unicodectype.c:207:12: warning: incompatible implicit declaration of built-in function 'towupper'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsAlpha':
Objects/unicodectype.c:212:5: warning: implicit declaration of function 'iswalpha'

----------
components: Build
messages: 129266
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 24 19:28:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Feb 2011 18:28:59 +0000
Subject: [New-bugs-announce] [issue11310] Document byte[s|array]() and
	byte[s|array](count) in	docstrings
In-Reply-To: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>
Message-ID: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>


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

The entry for bytearray(source...) says
"
The optional source parameter can be used to initialize the array in a few different ways:
...
If it is an integer, the array will have that size and will be initialized with null bytes. 
...
Without an argument, an array of size 0 is created.
"
[integer must be non-negative -- patch adds this]
The entry for bytes(source...) refers back to the bytearray entry.

The docstrings for bytes and bytearray omit both possibilities.
Attached is a possible patch to include them.

----------
assignee: docs at python
components: Documentation
files: zbytes.diff
keywords: patch
messages: 129299
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Document byte[s|array]() and byte[s|array](count) in docstrings
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20877/zbytes.diff

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

From report at bugs.python.org  Thu Feb 24 22:32:22 2011
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 24 Feb 2011 21:32:22 +0000
Subject: [New-bugs-announce] [issue11311] StringIO.readline(0) returns
	incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO
>>> StringIO.StringIO("foo").readline(0)
'foo'

I don't think this is the correct behavior, or at least it is not consistent with other file objects' readline() which return an empty string with .readline(0).

For example:

>>> import cStringIO
>>> cStringIO.StringIO("foo").readline(0)
''

...or:

>>> file("/usr/bin/python").readline(0)
''

----------
components: Library (Lib)
messages: 129314
nosy: scop
priority: normal
severity: normal
status: open
title: StringIO.readline(0) returns incorrect results
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 24 22:41:48 2011
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 24 Feb 2011 21:41:48 +0000
Subject: [New-bugs-announce] [issue11312] Confusing sentence in
	file.readline() doc
In-Reply-To: <1298583708.57.0.612051612173.issue11312@psf.upfronthosting.co.za>
Message-ID: <1298583708.57.0.612051612173.issue11312@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

http://docs.python.org/library/stdtypes.html#file.readline

"An empty string is returned only when EOF is encountered immediately."

I think this sentence is misleading especially because the word "only" in it is emphasized, because an empty string is also returned when the size argument is 0 (except for StringIO but I think that's a bug, see #11311).  I suggest rephrasing it as:

"An empty string is returned only when EOF is encountered immediately or the size argument is zero."

...or just removing the sentence altogether.  Text before it already covers the size=0 case.

----------
assignee: docs at python
components: Documentation
messages: 129316
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Confusing sentence in file.readline() doc
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 24 23:29:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 22:29:49 +0000
Subject: [New-bugs-announce] [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

In Python 3.x default encoding is always utf-8, but encode()/decode() still try to look it up.  Attached patch eliminates a call to normalize_encoding and several strcmp() calls.

----------
files: default-encode.diff
keywords: patch
messages: 129318
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Speed up default encode()/decode()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file20879/default-encode.diff

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

From report at bugs.python.org  Fri Feb 25 00:22:44 2011
From: report at bugs.python.org (Aaron Sherman)
Date: Thu, 24 Feb 2011 23:22:44 +0000
Subject: [New-bugs-announce] [issue11314] Subprocess suffers 40% process
	creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>


New submission from Aaron Sherman <ajs at ajs.com>:

I wrote some code a while back which used os.popen. I recently got a warning about popen being deprecated so I tried a test with the new subprocess module. In that test, subprocess.Popen appears to have a 40% process creation overhead penalty over os.popen, which really isn't small. It seems that the difference may be made up of some heavy mmap-related work that's happening in my version of python, and that might be highly platform specific, but the mmap/mremap/munmap calls being made in my sample subprocess code aren't being made at all in the os.popen equivalent.

Now, before someone says, "process creation is trivial, so a 40% hit is acceptable because it's 40% of a trivial part of your execution time," keep in mind that many Python applications are heavily process-creation focused. In my case that means monitoring, but I could also imagine this having a substantial impact on Web services and other applications that spend almost all of their time creating child processes. For a trivial script, subprocess is fine as is, but for these demanding applications, subprocess represents a significant source of pain.

Anyway my testing, results and conclusions are written up here:

http://essays.ajs.com/2011/02/python-subprocess-vs-ospopen-overhead.html

----------
components: Library (Lib)
messages: 129319
nosy: Aaron.Sherman
priority: normal
severity: normal
status: open
title: Subprocess suffers 40% process creation overhead penalty
type: resource usage
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Feb 25 05:05:03 2011
From: report at bugs.python.org (Alexander Tsepkov)
Date: Fri, 25 Feb 2011 04:05:03 +0000
Subject: [New-bugs-announce] [issue11315] Cookie.py breaks when passed
	unicode, fix included
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>


New submission from Alexander Tsepkov <atsepkov at gmail.com>:

in Lib/Cookie.py, BaseCookie load() method performs the following comparison on line 624:

str(rawdata) == str("")

This breaks when a unicode string is passed in for rawdata. I've included a patch that fixes this issue by using isinstance(rawdata, basestring) comparison instead. Additionally the patch encodes rawdata in ascii before sending it to __ParseString() since that method does not support unicode.

----------
components: Unicode
files: cookie_patch.patch
keywords: patch
messages: 129330
nosy: Alexander.Tsepkov
priority: normal
severity: normal
status: open
title: Cookie.py breaks when passed unicode, fix included
versions: Python 2.6
Added file: http://bugs.python.org/file20883/cookie_patch.patch

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

From report at bugs.python.org  Fri Feb 25 11:37:52 2011
From: report at bugs.python.org (Georges Martin)
Date: Fri, 25 Feb 2011 10:37:52 +0000
Subject: [New-bugs-announce] [issue11316] RFC822 header parsing API
	inconsistencies between	httplib.HTTPMessage and
	email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>


New submission from Georges Martin <jrjsmrtn at gmail.com>:

Both httplib.HTTPMessage and email.message.Message classes[1] implements methods for RFC822 headers parsing. Unfortunately, they have different implementations and they do not provide the same level of functionality.

One example that is bugging me is that:

* httplib.HTTPMessage is missing the get_filename method present in email.message.Message, that allows you to easily retrieve the filename from a 'Content-disposition: attachment; filename="fghi.xyz"' header;

* httplib.HTTPMessage has getparam, getplist and parseplist methods but AFAIK, they are not and cannot be used outside of the 'content-type' header parsing;

* email.message.Message has a generic get_param method to parse any RFC822 header with parameters, such as 'content-disposition' or 'content-type'.

The workaround I'm using is to decorate an httplib.HTTPMessage with the missing methods from email.message.Message:

    def monkeypatch_http_message(obj):
        """ Decorate an httplib.HTTPMessage instance's class 
            with the RFC822 header parameters parsing methods 
            from email.message.Message. (thanks to ncoghlan)
        """
        import httplib
        assert isinstance(obj, httplib.HTTPMessage)
        cls = obj.__class__
    
        from email import utils
        from email.message import (
            _parseparam, 
            _unquotevalue, 
            Message
        )
        funcnames = (
            '_get_params_preserve', 
            'get_params', 
            'get_param',
            'get_filename'
        )
        for funcname in funcnames:
            cls.__dict__[funcname] = Message.__dict__[funcname]

So I can do:

    import mechanize
    from some.module import monkeypatch_http_message
    browser = mechanize.Browser()
    
    # in that form, browser.retrieve returns a temporary filename 
    # and an httplib.HTTPMessage instance
    (tmp_filename, headers) = browser.retrieve(someurl) 

    # monkeypatch the httplib.HTTPMessage instance
    monkeypatch_http_message(headers)

    # yeah... my original filename, finally
    filename = headers.get_filename()

----------
components: Library (Lib)
messages: 129348
nosy: jrjsmrtn
priority: normal
severity: normal
status: open
title: RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 25 12:14:02 2011
From: report at bugs.python.org (Laurence Rowe)
Date: Fri, 25 Feb 2011 11:14:02 +0000
Subject: [New-bugs-announce] [issue11317] Documentation not updated to show
	string exceptions have	been deprecated
In-Reply-To: <1298632442.51.0.260664855458.issue11317@psf.upfronthosting.co.za>
Message-ID: <1298632442.51.0.260664855458.issue11317@psf.upfronthosting.co.za>


New submission from Laurence Rowe <l at lrowe.co.uk>:

The documentation at http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions states that "String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release." String exceptions were removed in 2.6.

----------
assignee: docs at python
components: Documentation
messages: 129353
nosy: docs at python, lrowe
priority: normal
severity: normal
status: open
title: Documentation not updated to show string exceptions have been deprecated
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Feb 25 13:25:15 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 12:25:15 +0000
Subject: [New-bugs-announce] [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

I have found a possible typo in an example code of Python 3.2. It's located on page 32 in the PDF version of the FAQ document. The code is:

class C:
    count = 0 # number of times C.__init__ called

def __init__(self):
    C.count = C.count + 1

def getcount(self):
    return C.count # or return self.count

The code block of the __init__ method is the thing that has the typo. Shouldn't  C.count = C.count + 1  be  c.count = C.count + 1 ?  Because the text after this code example says:

c.count also refers to C.count for any c such that isinstance(c, C) holds /.../.

How can c.count also refer to C.count if there is no c.count in the present code example in the FAQ of Python 3.2?

If this is a typo, please fix it for Python 3.2 and also for other Python versions with the same typo.

Else if this is not a typo, explain how can c.count refer to C.count if there is no c.count in the code example.

----------
assignee: docs at python
components: Documentation
messages: 129357
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python 3.2 FAQ example code typo?
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 25 15:00:59 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWUgUmFkaXg=?=)
Date: Fri, 25 Feb 2011 14:00:59 +0000
Subject: [New-bugs-announce] [issue11319] Command line option -t (and -tt)
	does not work for a	particular case
In-Reply-To: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>
Message-ID: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>


New submission from J?r?me Radix <jerome.radix at gmail.com>:

The attached example mixes tabs and spaces but python does not report any warning when used with -t.

Line 4 contains 1 tab. Lines after line 4 contains spaces.

Tested using :
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32

C:\>python -t test_tt.py

C:\>

----------
components: Interpreter Core
files: test_tt.py
messages: 129368
nosy: jerome.radix
priority: normal
severity: normal
status: open
title: Command line option -t (and -tt) does not work for a particular case
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20889/test_tt.py

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

From report at bugs.python.org  Fri Feb 25 15:32:03 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 14:32:03 +0000
Subject: [New-bugs-announce] [issue11320] Usage of API method Py_SetPath
	causes errors in	Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>


New submission from Palm Kevin <kevin.palm at labsolution.lu>:

The new API method Py_SetPath seems bugged. When executing the following code, then the application crashes on Py_Initialize()-call:
#include "Python.h"

main(int argc, char **argv)
{
  Py_SetPath(Py_GetPath());
  printf("Init\n");
  Py_Initialize();
  printf("-- END\n");
}

The raised exception is the following:

Traceback (most recent call last):
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 'lib/python3.2/config-3.2m/Makefile'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 529, in <module>
    main()
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 517, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 263, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 238, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 228, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 590, in get_config_var
    return get_config_vars().get(name)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 487, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 337, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open lib/python3.2/config-3.2m/Makefile (No such file or directory)

(perhaps linked to issue #10743 ?!)

----------
components: Interpreter Core
messages: 129372
nosy: palm.kevin
priority: normal
severity: normal
status: open
title: Usage of API method Py_SetPath causes errors in Py_Initialize() (Posix ony))
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 25 16:51:21 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 15:51:21 +0000
Subject: [New-bugs-announce] [issue11321] 9th import of module _pickle
	always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>


New submission from Palm Kevin <kevin.palm at labsolution.lu>:

Please have a look to the following app:

#include "Python.h"

main(int argc, char **argv)
{
  int i;
  printf("START\n");
  for(i = 0; i < 20; i++){
    Py_Initialize();

    printf("Try import #%i ...", i);
    PyRun_SimpleString("import _pickle\n");

    printf("SUCCESS\n");
    Py_Finalize();
  }
  printf("END\n");
}


If I run that app (Linux), then I get the following output:

START
Try import #0 ...SUCCESS
Try import #1 ...SUCCESS
Try import #2 ...SUCCESS
Try import #3 ...SUCCESS
Try import #4 ...SUCCESS
Try import #5 ...SUCCESS
Try import #6 ...SUCCESS
Try import #7 ...SUCCESS
Segmentation fault


It systematically crashes on the 9th call ...
Does anybody know the reason of this segmentation fault problem??

----------
components: Interpreter Core
messages: 129384
nosy: palm.kevin
priority: normal
severity: normal
status: open
title: 9th import of module _pickle always crashes
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 25 16:55:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 15:55:32 +0000
Subject: [New-bugs-announce] [issue11322] encoding package's
	normalize_encoding() function is too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation.

The original version used the .translate() method which is a lot faster and can be adapted to work with the Unicode variant of the .translate() method just as well.

_norm_encoding_map = ('                                              . '
                      '0123456789       ABCDEFGHIJKLMNOPQRSTUVWXYZ     '
                      ' abcdefghijklmnopqrstuvwxyz                     '
                      '                                                '
                      '                                                '
                      '                ')

def normalize_encoding(encoding):

    """ Normalize an encoding name.

        Normalization works as follows: all non-alphanumeric
        characters except the dot used for Python package names are
        collapsed and replaced with a single underscore, e.g. '  -;#'
        becomes '_'. Leading and trailing underscores are removed.

        Note that encoding names should be ASCII only; if they do use
        non-ASCII characters, these must be Latin-1 compatible.

    """
    # Make sure we have an 8-bit string, because .translate() works
    # differently for Unicode strings.
    if hasattr(__builtin__, "unicode") and isinstance(encoding, unicode):
        # Note that .encode('latin-1') does *not* use the codec
        # registry, so this call doesn't recurse. (See unicodeobject.c
        # PyUnicode_AsEncodedString() for details)
        encoding = encoding.encode('latin-1')
    return '_'.join(encoding.translate(_norm_encoding_map).split())

----------
components: Unicode
messages: 129386
nosy: lemburg
priority: normal
severity: normal
status: open
title: encoding package's normalize_encoding() function is too slow
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 25 21:03:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 20:03:18 +0000
Subject: [New-bugs-announce] [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2658/steps/test/logs/stdio

Patch in attachment.

----------
files: sendfile-test.patch
keywords: patch
messages: 129411
nosy: giampaolo.rodola, loewis
priority: normal
severity: normal
status: open
title: os.sendfile() bo failure on solaris
versions: Python 3.3
Added file: http://bugs.python.org/file20892/sendfile-test.patch

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

From report at bugs.python.org  Fri Feb 25 21:37:08 2011
From: report at bugs.python.org (Tobias Brink)
Date: Fri, 25 Feb 2011 20:37:08 +0000
Subject: [New-bugs-announce] [issue11324] ConfigParser(interpolation=None)
	doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>


New submission from Tobias Brink <tobias.brink at gmail.com>:

The docs for Python 3.2 say that p = configparser.ConfigParser(interpolation=None) disables interpolation.  Instead it gives this traceback when calling p.read():

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/configparser.py", line 688, in read
    self._read(fp, filename)
  File "/usr/lib/python3.2/configparser.py", line 1081, in _read
    self._join_multiline_values()
  File "/usr/lib/python3.2/configparser.py", line 1091, in _join_multiline_values
    options[name] = self._interpolation.before_read(self,
AttributeError: 'NoneType' object has no attribute 'before_read'

The attached patch should fix it.

----------
components: Library (Lib)
files: configparser_interpolation.patch
keywords: patch
messages: 129421
nosy: tbrink
priority: normal
severity: normal
status: open
title: ConfigParser(interpolation=None) doesn't work
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20895/configparser_interpolation.patch

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

From report at bugs.python.org  Sat Feb 26 00:39:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:39:29 +0000
Subject: [New-bugs-announce] [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>


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

$ make
gcc -pthread  -g -O0 -Wall -Wstrict-prototypes    -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ?posix_sendfile?:
./Modules/posixmodule.c:6025: attention : implicit declaration of function ?sendfile?

----------
assignee: giampaolo.rodola
components: Extension Modules
messages: 129470
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: compilation warning with sendfile
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 26 01:31:13 2011
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 26 Feb 2011 00:31:13 +0000
Subject: [New-bugs-announce] [issue11326] Asynchronous ssl handshakes fails
	for asynchronously	connected sockets.
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

The asynchronous do_handshakes fails for sockets that were connected asynchronously. Tested on 2.6, 3.1 and 3.2.

Traceback (most recent call last):
  File "handshake.py", line 17, in <module>
    s.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 279, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

----------
components: Library (Lib)
files: handshake.py
messages: 129477
nosy: segfaulthunter
priority: normal
severity: normal
status: open
title: Asynchronous ssl handshakes fails for asynchronously connected sockets.
type: behavior
versions: Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20899/handshake.py

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

From report at bugs.python.org  Sat Feb 26 07:37:38 2011
From: report at bugs.python.org (Anthony Long)
Date: Sat, 26 Feb 2011 06:37:38 +0000
Subject: [New-bugs-announce] [issue11327] Running test_time.py in python27
	caused python to	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

I ran 

python test_time.py 

and python immediately crashed.

This is the trace from mac's error reporter: 

http://dpaste.de/Jsw7/

----------
components: Tests
messages: 129502
nosy: antlong
priority: normal
severity: normal
status: open
title: Running test_time.py in python27 caused python to unexpectedly quit
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 26 08:58:41 2011
From: report at bugs.python.org (Dmitry Negius)
Date: Sat, 26 Feb 2011 07:58:41 +0000
Subject: [New-bugs-announce] [issue11328] NESTED WHILE CYCLES ERROR
In-Reply-To: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>
Message-ID: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>


New submission from Dmitry Negius <dmitrygenius6 at gmail.com>:

Nested "while" cycles does not work. This make impossible to write a class of programs with nested while cycles.

----------
components: Interpreter Core
files: bug.py
messages: 129506
nosy: negius
priority: normal
severity: normal
status: open
title: NESTED WHILE CYCLES ERROR
type: compile error
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20903/bug.py

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

From report at bugs.python.org  Sat Feb 26 10:50:07 2011
From: report at bugs.python.org (Juraj Ivancic)
Date: Sat, 26 Feb 2011 09:50:07 +0000
Subject: [New-bugs-announce] [issue11329] PyEval_InitThreads() not safe
	before Py_Initialize()
In-Reply-To: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>
Message-ID: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>


New submission from Juraj Ivancic <juraj.ivancic at gmail.com>:

It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation

http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads

Minimal repro:

#include "Python.h"
int main()
{
     PyEval_InitThreads();
     return 0;
}

Everything works if Py_Initialize() is called first.

----------
components: Interpreter Core
messages: 129515
nosy: Juraj.Ivancic
priority: normal
severity: normal
status: open
title: PyEval_InitThreads() not safe before Py_Initialize()
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 26 11:52:27 2011
From: report at bugs.python.org (akira)
Date: Sat, 26 Feb 2011 10:52:27 +0000
Subject: [New-bugs-announce] [issue11330] logging doesn't support format
	flags for asctime keyword, but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

Since Python 3.2 logging package doesn't support formatting flags for the `asctime` keyword, but the documentation uses them. For example in Doc/library/logging.rst:

  FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'

should be replaced by:

  FORMAT = '%(asctime)s %(clientip)s %(user)-8s %(message)s'

The attached file 'doc-logging-asctime-r88640.patch' contains necessary changes.

An alternative solution would be to fix the logging package to restore the support.

----------
assignee: docs at python
components: Documentation
files: doc-logging-asctime-r88640.patch
keywords: patch
messages: 129524
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: logging doesn't support format flags for asctime keyword, but the docs use them
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20906/doc-logging-asctime-r88640.patch

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

From report at bugs.python.org  Sat Feb 26 12:06:14 2011
From: report at bugs.python.org (akira)
Date: Sat, 26 Feb 2011 11:06:14 +0000
Subject: [New-bugs-announce] [issue11331] unused line in the
	logging-cookbook example
In-Reply-To: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>
Message-ID: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

The line with `LoggerAdapter` is not used in http://docs.python.org/dev/howto/logging-cookbook.html#using-filters-to-impart-contextual-information

Here's a patch for Doc/howto/logging-cookbook.rst: doc-logging-cookbook-unused-line-r88640.patch

----------
assignee: docs at python
components: Documentation
files: doc-logging-cookbook-unused-line-r88640.patch
keywords: patch
messages: 129527
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: unused line in the logging-cookbook example
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20907/doc-logging-cookbook-unused-line-r88640.patch

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

From report at bugs.python.org  Sat Feb 26 12:18:04 2011
From: report at bugs.python.org (Oliver Drake)
Date: Sat, 26 Feb 2011 11:18:04 +0000
Subject: [New-bugs-announce] [issue11332] Increase logging/__init__.py
	coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>


New submission from Oliver Drake <obdrake11 at gmail.com>:

Purely a modification to test_logging.py with the focus being to increase coverage. coverage.py now measures 97% (when running test_logging.py by itself). I'm not sure if I've followed py-dev unit test conventions exactly, I've created quite a few new test case classes, going by the model of having one unittest test case class for each class defined in the module under test. Comments welcome :)

----------
components: Tests
files: test_logging.diff
keywords: patch
messages: 129530
nosy: drakeol
priority: normal
severity: normal
status: open
title: Increase logging/__init__.py coverage to 97%
versions: Python 3.2
Added file: http://bugs.python.org/file20908/test_logging.diff

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

From report at bugs.python.org  Sat Feb 26 13:24:34 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 26 Feb 2011 12:24:34 +0000
Subject: [New-bugs-announce] [issue11333] Add empty __slots__ to
	collections.abc abstract base	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

Currently instances of classes which inherit an ABC in collections.abc will have a __dict__.  This can be a problem for example a tree-like data structure. It would make sense to inherit for example MutableMapping, but that would possibly mean, that every node in the tree would have a __dict__, which is probably a waste of memory.

A workaround for this problem is not inheriting the ABC, and using ABCMeta.register (and optionally adding the mixin methods explicitly), but this feels like a hack.

The attached patch adds an empty __slots__ to the ABCs in collections.abc.  I excluded the mapping views (MappingView, KeysView, ItemsView and ValuesView), because they can't have an empty __slots__, and I think using a nonempty __slots__ possibly can cause problems in some cases with multiple inheritance.

----------
components: Library (Lib)
files: collections_abc_slots.diff
keywords: patch
messages: 129534
nosy: durban, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: Add empty __slots__ to collections.abc abstract base classes
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20910/collections_abc_slots.diff

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

From report at bugs.python.org  Sat Feb 26 17:53:01 2011
From: report at bugs.python.org (dave)
Date: Sat, 26 Feb 2011 16:53:01 +0000
Subject: [New-bugs-announce] [issue11334] Failed to build _multiprocessing
	on Mac OS X
In-Reply-To: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>
Message-ID: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>


New submission from dave <dev66 at gmx.de>:

hi community,

i cannot import multiprocessing since it fails(?) during build.
could someone point out a solution for me?

thanks a lot in advance.
dave



$ python
Python 2.7.1 (r271:86832, Feb 26 2011, 17:19:29) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> import multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tools/python/lib/python2.7/multiprocessing/__init__.py", line 83, in <module>
    import _multiprocessing
ImportError: No module named _multiprocessing




This is what i did to compile python 2.7:

export MACOSX_DEPLOYMENT_TARGET=10.6
export ARCHFLAGS="-arch i386"
export CXXFLAGS="-arch i386"
export CFLAGS="-arch i386"
export FFLAGS="-arch i386"
export LDFLAGS="-Wall -undefined dynamic_lookup -arch i386"

./configure
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... darwin
checking EXTRAPLATDIR... $(PLATMACDIRS)
checking machine type as reported by uname -m... i386
checking for --without-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for --with-cxx-main=<compiler>... no
checking for g++... g++
[...]
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile


make -j 4
[...]
/private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c: In function 'semlock_acquire':
/private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c:314: warning: implicit declaration of function 'sem_timedwait'
*** WARNING: renaming "_multiprocessing" since importing it failed: dlopen(build/lib.macosx-10.6-i386-2.7/_multiprocessing.so, 2): Symbol not found: _sem_timedwait
  Referenced from: /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so
  Expected in: flat namespace
 in /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so
[...]
ranlib libpython2.7.a
gcc -Wall -undefined dynamic_lookup -arch i386 -u _PyMac_Error -o python.exe \
                        Modules/python.o \
                        libpython2.7.a -ldl  -framework CoreFoundation     
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             gdbm               linuxaudiodev   
ossaudiodev        sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_multiprocessing   spwd

----------
assignee: ronaldoussoren
components: Macintosh
messages: 129573
nosy: dev66, ronaldoussoren
priority: normal
severity: normal
status: open
title: Failed to build _multiprocessing on Mac OS X
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 26 18:02:25 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 17:02:25 +0000
Subject: [New-bugs-announce] [issue11335] Memory leak after key function
	failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

In list.sort, if a key function throws an exception, the memory to store the keys is never freed.  I introduced the bug in r86937.  I'll upload a patch for review shortly.

----------
assignee: stutzbach
components: Interpreter Core
messages: 129574
nosy: pitrou, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak after key function failure in sort
type: resource usage
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Feb 26 19:35:16 2011
From: report at bugs.python.org (blokeley)
Date: Sat, 26 Feb 2011 18:35:16 +0000
Subject: [New-bugs-announce] [issue11336] Typo in patch.rst
In-Reply-To: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>
Message-ID: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>


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

I think that a typographical error was made in patch.rst.

Should "(do not that not all checks apply to non-core developers)"
read "(note that not all checks apply to non-core developers)"?

Patch attached.

----------
assignee: docs at python
components: Documentation
files: grammar_fix.patch
keywords: patch
messages: 129583
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: Typo in patch.rst
type: behavior
Added file: http://bugs.python.org/file20921/grammar_fix.patch

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

From report at bugs.python.org  Sat Feb 26 19:37:39 2011
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 26 Feb 2011 18:37:39 +0000
Subject: [New-bugs-announce] [issue11337] Nothing refers to footnote [1] on
	page "6. Simple	Statements" in Language Reference
In-Reply-To: <1298745459.54.0.732710965592.issue11337@psf.upfronthosting.co.za>
Message-ID: <1298745459.54.0.732710965592.issue11337@psf.upfronthosting.co.za>


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

I can't find a reference to footnote [1] on page "6. Simple Statements" in Language Reference. Either the footnote should be removed or a [1] link to it should appear on the page.

----------
assignee: docs at python
components: Documentation
messages: 129584
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: Nothing refers to footnote [1] on page "6. Simple Statements" in Language Reference
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb 26 20:13:47 2011
From: report at bugs.python.org (blokeley)
Date: Sat, 26 Feb 2011 19:13:47 +0000
Subject: [New-bugs-announce] [issue11338] No list of Python hg repositories
In-Reply-To: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>
Message-ID: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>


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

Recently, I've logged a few issues on http://bugs.python.org/ and tried to submit patches where possible.

However, I have not been able to find any documentation that states where the hg repositories are. There are some under http://hg.python.org/ and some under http://code.python.org/hg

Please could the documentation somewhere list the official repos and what they are used for.

I have attached a patch to the devguide repo which probably has:
 * The wrong list of repos (I still don't know what the correct list is); and
 * The list in the wrong part of the documentation.

Nevertheless, I hope this helps.

----------
assignee: docs at python
components: Documentation
files: repo_locations.patch
keywords: patch
messages: 129585
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: No list of Python hg repositories
type: behavior
Added file: http://bugs.python.org/file20922/repo_locations.patch

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

From report at bugs.python.org  Sat Feb 26 21:23:40 2011
From: report at bugs.python.org (Andy Harrington)
Date: Sat, 26 Feb 2011 20:23:40 +0000
Subject: [New-bugs-announce] [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

You cannot make a self-referential annotation like

class Graph:
    def reverse(self) -> Graph:
       # ...

This corresponds to a common coding situation.

----------
components: Interpreter Core
messages: 129587
nosy: andyharrington
priority: normal
severity: normal
status: open
title: annotation for class being defined
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 26 21:30:00 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 20:30:00 +0000
Subject: [New-bugs-announce] [issue11340] test_distutils fails
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>


New submission from Westley Mart?nez <anikom15 at gmail.com>:

test_compressed_deprecated failed

----------
components: Tests
files: test_distutils
messages: 129588
nosy: anikom15
priority: normal
severity: normal
status: open
title: test_distutils fails
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20923/test_distutils

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

From report at bugs.python.org  Sat Feb 26 21:31:33 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 20:31:33 +0000
Subject: [New-bugs-announce] [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>


New submission from Westley Mart?nez <anikom15 at gmail.com>:

test_invalid_offset failed on linux2.

----------
components: Tests
files: test_os
messages: 129589
nosy: anikom15
priority: normal
severity: normal
status: open
title: test_os fails
versions: Python 3.3
Added file: http://bugs.python.org/file20924/test_os

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

From report at bugs.python.org  Sat Feb 26 22:39:02 2011
From: report at bugs.python.org (LW)
Date: Sat, 26 Feb 2011 21:39:02 +0000
Subject: [New-bugs-announce] [issue11342] ResourceWarning: unclosed file
	<_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>


New submission from LW <cjejuni2000 at yahoo.com>:

1 test failed:
    test_urllib2_localnet
1 test altered the execution environment:
    test_urllib2
21 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_gdb
    test_kqueue test_ossaudiodev test_smtpnet test_socketserver
    test_startfile test_timeout test_tk test_ttk_guionly
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64
1 skip unexpected on linux2:
    test_ttk_guionly
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='UTF-8'>
make: *** [test] Error 1

----------
components: IO
messages: 129598
nosy: cjejuni2000
priority: normal
severity: normal
status: open
title: ResourceWarning: unclosed file <_io.TextIOWrapper
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 26 23:39:51 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 26 Feb 2011 22:39:51 +0000
Subject: [New-bugs-announce] [issue11343] Make errors due to full parser
	stack identifiable
In-Reply-To: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>
Message-ID: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Currently, if the parser's internal stack is full (as it happens when
the parser tries to parse a deeply nested structure), the parser
writes an error message to stderr and a bare MemoryError is
raised. That way, it is really hard for REPLs do handle input that
causes the parser to exhaust its stack correctly (see e.g. ``python -c
"print '(' * 100 + ')' * 100" | python -c "import code;
code.interact()"``).

In my opinion, a SyntaxError would be great because that way one can
easily see where in the source code the error is caused. One reason
against that (stated by MvL in msg1687) is that it's really
syntactically correct Python and only the parser can't parse it. But
then, the same is also true when there are too many indentation levels
in which case an `IndentationError` is raised (which is a subclass of
`SyntaxError`).

I have attached two patches: The first still raises a `MemoryError`
(for the sake of backward compatibility) but adds a message ("too many
opening parens") to it. The second raises a `SyntaxError` instead.

----------
components: Interpreter Core
files: parser_nested_MemoryError.patch
keywords: patch
messages: 129604
nosy: Trundle, marienz
priority: normal
severity: normal
status: open
title: Make errors due to full parser stack identifiable
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20925/parser_nested_MemoryError.patch

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

From report at bugs.python.org  Sun Feb 27 09:26:48 2011
From: report at bugs.python.org (blokeley)
Date: Sun, 27 Feb 2011 08:26:48 +0000
Subject: [New-bugs-announce] [issue11344] Add height argument to
	os.path.dirname()
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>


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

It is a common need to find the grandparent or great-grandparent (etc.) of a given directory, which results in this:

>>> from os.path import dirname
>>> mydir = dirname(dirname(dirname(path)))

Could a "height" parameter be added to os.path.dirname so it becomes:

>>> def dirname(path, height=1):

Then we could have usage like:

>>> path = '/ggparent/gparent/parent/myfile.txt'
>>> from os.path import dirname

>>> dirname(path)
/ggparent/gparent/parent

>>> dirname(path, 2)
/ggparent/gparent

>>> dirname(path, 3)
/ggparent

Perhaps we should throw ValueErrors for invalid height values:

>>> dirname(path, 10)
ValueError

>>> dirname(path, -1)
ValueError

Perhaps a height of 0 should do nothing:

>>> dirname(path, 0)
/ggparent/gparent/parent/myfile.txt

I can supply patches, unit tests and docs if you like.

----------
components: Library (Lib)
messages: 129616
nosy: blokeley
priority: normal
severity: normal
status: open
title: Add height argument to os.path.dirname()
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 27 15:54:40 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 27 Feb 2011 14:54:40 +0000
Subject: [New-bugs-announce] [issue11345] Fix a link in library/json docs
In-Reply-To: <1298818480.03.0.395520184392.issue11345@psf.upfronthosting.co.za>
Message-ID: <1298818480.03.0.395520184392.issue11345@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

I guess this should be a link.

----------
assignee: docs at python
components: Documentation
files: fix-json-link.diff
keywords: patch
messages: 129629
nosy: docs at python, jonash
priority: normal
severity: normal
status: open
title: Fix a link in library/json docs
versions: Python 3.3
Added file: http://bugs.python.org/file20932/fix-json-link.diff

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

From report at bugs.python.org  Sun Feb 27 16:03:13 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sun, 27 Feb 2011 15:03:13 +0000
Subject: [New-bugs-announce] [issue11346] Generator object should be
	mentioned in gc module	document
In-Reply-To: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>
Message-ID: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

In the gc.garbage of the library ref of gc module, 
  
  ... this list contains only objects with __del__() methods.

This is not true, since gc.garbage will contain generator object with try-finally block.

----------
assignee: docs at python
components: Documentation
messages: 129631
nosy: docs at python, ishimoto
priority: normal
severity: normal
status: open
title: Generator object should be mentioned in gc module document

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

From report at bugs.python.org  Sun Feb 27 21:26:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 20:26:28 +0000
Subject: [New-bugs-announce] [issue11347] libpython3.so: Broken soname and
	linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

1. libpython3.so has soname "llibpython3.so" due to needless "l" in "-Wl,-hl$@".
2. libpython3.so is not linked against libpython$(LDVERSION).so when -Wl,--as-needed flag is used. -Wl,--as-needed flag is used by default in Gentoo due to major benefits.
>From `info ld`:
`--as-needed'
`--no-as-needed'
     This option affects ELF DT_NEEDED tags for dynamic libraries
     mentioned on the command line after the `--as-needed' option.
     Normally the linker will add a DT_NEEDED tag for each dynamic
     library mentioned on the command line, regardless of whether the
     library is actually needed or not.  `--as-needed' causes a
     DT_NEEDED tag to only be emitted for a library that satisfies an
     undefined symbol reference from a regular object file or, if the
     library is not found in the DT_NEEDED lists of other libraries
     linked up to that point, an undefined symbol reference from
     another dynamic library.  `--no-as-needed' restores the default
     behaviour.

I'm attaching the patch.

----------
components: Build
files: libpython3.so.patch
keywords: patch
messages: 129649
nosy: Arfrever, loewis
priority: normal
severity: normal
status: open
title: libpython3.so: Broken soname and linking
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20939/libpython3.so.patch

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

From report at bugs.python.org  Sun Feb 27 22:20:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 21:20:21 +0000
Subject: [New-bugs-announce] [issue11348] test_os: test_set_get_priority()
	fails when high	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ nice -n20 python3.3 -m test.test_os
...
test_set_get_priority (__main__.ProgramPriorityTests) ... FAIL

======================================================================
FAIL: test_set_get_priority (__main__.ProgramPriorityTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_os.py", line 1280, in test_set_get_priority
    self.assertEqual(os.getpriority(os.PRIO_PROCESS, os.getpid()), base + 1)
AssertionError: 19 != 20

----------
components: Tests
messages: 129654
nosy: Arfrever, giampaolo.rodola
priority: normal
severity: normal
status: open
title: test_os: test_set_get_priority() fails when high niceness is set
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 28 02:29:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 01:29:11 +0000
Subject: [New-bugs-announce] [issue11349] _pickle should implement the
	module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>


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

As discussed in issue11321, _pickle allocates a number of module level objects, but doesn't use the appropriate PEP 3121 mechanisms to manage their lifecycle.

It should be updated to follow the relevant development guidelines in the documentation.

----------
components: Extension Modules
messages: 129677
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: _pickle should implement the module finalisation protocol
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 28 10:53:06 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 28 Feb 2011 09:53:06 +0000
Subject: [New-bugs-announce] [issue11350] __setitem__()'s problem of
	dbm.dumb object pointed out	by comments
In-Reply-To: <1298886786.25.0.421725723062.issue11350@psf.upfronthosting.co.za>
Message-ID: <1298886786.25.0.421725723062.issue11350@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

By reading the Lib/dbm/dumb.py source, there seems to be an distinct problem which is pointed out in comments: the __setitem__() should call self._commit() in order to keep .dat file and .dir file consist.

Here is a piece of comment found at the end of __setitem__():

# Note that _index may be out of synch with the directory
# file now:  _setval() and _addval() don't update the directory
# file.  This also means that the on-disk directory and data
# files are in a mutually inconsistent state, and they'll
# remain that way until _commit() is called.  Note that this
# is a disaster (for the database) if the program crashes
# (so that _commit() never gets called).


And another piece found in __delitem__():

# XXX It's unclear why we do a _commit() here (the code always
# XXX has, so I'm not changing it).  __setitem__ doesn't try to
# XXX keep the directory file in synch.  Why should we?  Or
# XXX why shouldn't __setitem__?


One probable reason I guess is that the self._commit() method which writes the keys information to .dir file is regarded as a slow process, and the __setitem__() is called frequently at most cases while __deltiem__ is not, so calling self._commit() at each __setitem__ could make the program very slow.

But based on the fact that "The dbm.dumb module is not written for speed and is not nearly as heavily used as the other database modules."(found on dbm's library document), maybe correctness is more important than speed.

So I think it should be fixed:

Index: Lib/dbm/dumb.py
===================================================================
--- Lib/dbm/dumb.py	(revision 88674)
+++ Lib/dbm/dumb.py	(working copy)
@@ -196,6 +196,7 @@
             # remain that way until _commit() is called.  Note that this
             # is a disaster (for the database) if the program crashes
             # (so that _commit() never gets called).
+            self._commit()
 
     def __delitem__(self, key):
         if isinstance(key, str):

And the remaining comments can be deleted.

----------
components: Library (Lib)
messages: 129688
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: __setitem__()'s problem of dbm.dumb object pointed out by comments
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 28 13:03:59 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 12:03:59 +0000
Subject: [New-bugs-announce] [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Antoine, i made you noisy because you took care about Issue11323.
I'm at r88671 (271057c7c6f3).
I'm opening this because the buildbot URL (thanks) doesn't show
anything about sendfile(2).

12:47 ~/arena/code.extern.repos/py3k.hg $ ./python.exe -Wd -m test.test_os -r -w -v

...
test_headers (__main__.TestSendfile) ... FAIL
test_invalid_offset (__main__.TestSendfile) ... ok
test_offset_overflow (__main__.TestSendfile) ... ok
test_send_at_certain_offset (__main__.TestSendfile) ... ok
test_send_whole_file (__main__.TestSendfile) ... ok
test_trailers (__main__.TestSendfile) ... /Users/steffen/arena/code.extern.repos/py3k.hg/Lib/unittest/case.py:387: ResourceWarning: unclosed file <_io.BufferedReader name='@test_28253_tmp2'>
  function()
ok
test_set_get_priority (__main__.ProgramPriorityTests) ... ok

======================================================================
FAIL: test_headers (__main__.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1517, in test_headers
    self.assertEqual(total_sent, len(expected_data))
AssertionError: 163840 != 164352

----------------------------------------------------------------------
Ran 92 tests in 0.447s

FAILED (failures=1, skipped=10)
Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1573, in <module>
    test_main()
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1569, in test_main
    ProgramPriorityTests,
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/support.py", line 1187, in run_unittest
    _run_suite(suite)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/support.py", line 1170, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1517, in test_headers
    self.assertEqual(total_send, len(expected_data))
AssertionError: 163840 != 164352

----------
components: Library (Lib)
messages: 129689
nosy: pitrou, sdaoden
priority: normal
severity: normal
status: open
title: (test_os) os.sendfile() error
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 28 13:14:21 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 28 Feb 2011 12:14:21 +0000
Subject: [New-bugs-announce] [issue11352] Buf in cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

Hi,

I wrote a patch for the cgi module in version 3.2rc1 (#4953). Small changes should be done to the documentation of this module to reflect the changes in the module API :

- in section "20.2.2. Using the cgi module"

original text :
"If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as a string. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute:"

proposed new text (for files, value is bytes, not string, and the read() method on file also returns bytes) :
"If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as bytes. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute (the read() and readline() methods will return bytes) :"

- version 3.2 introduced a parameter "encoding" for the FieldStorage constructor, used to decode the bytes received on the HTTP connection for fields other than files. This encoding must the one defined in the HTML document holding the form submitted to the CGI script ; it is usually defined by a meta tag :
<meta http-equiv="Content-type" content="text/html;charset=latin-1">
or by the Content-Type header for this document

I'm not sure where this should be mentioned in the module documentation. Maybe in "20.2.9. Common problems and solutions" for the moment. But there are plans (#11066) to introduce another interface to change the encoding of sys.stdout in the CGI script itself, so another option would be to open a specific section about encodings

Hope it's clear enough
Pierre

----------
assignee: docs at python
components: Documentation
messages: 129691
nosy: docs at python, quentel
priority: normal
severity: normal
status: open
title: Buf in cgi module doc
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 28 17:31:58 2011
From: report at bugs.python.org (David)
Date: Mon, 28 Feb 2011 16:31:58 +0000
Subject: [New-bugs-announce] [issue11353] Python 2.7.1 cannot be built by
	2.x baselines of Python
In-Reply-To: <1298910718.29.0.514753176943.issue11353@psf.upfronthosting.co.za>
Message-ID: <1298910718.29.0.514753176943.issue11353@psf.upfronthosting.co.za>


New submission from David <w004dal at xsmail.com>:

I tried to download and install the latest Python tarball (2.7.1) and use Python 2.6 to execute "setup.py".

I got the error "No module named sysconfig" when running setup.py. "sysconfig" was introduced with Python 3.2 (per http://docs.python.org/dev/library/sysconfig.html).

I am running Ubuntu 10.04.2 LTS and Python 2.6 trying to update to 2.7.x since Django does not support Python 3.x. It seems like a lot of trouble to install Python 3.x to downgrade to the Python version I need.

Recommend providing deb source packages that can be built on Ubuntu 10.04 and 10.10, or fixing this bug.

----------
components: Build
messages: 129712
nosy: w004dal
priority: normal
severity: normal
status: open
title: Python 2.7.1 cannot be built by 2.x baselines of Python
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb 28 17:51:35 2011
From: report at bugs.python.org (=?utf-8?q?Wojciech_Mu=C5=82a?=)
Date: Mon, 28 Feb 2011 16:51:35 +0000
Subject: [New-bugs-announce] [issue11354] argparse: nargs could accept range
	of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>


New submission from Wojciech Mu?a <wojciech_mula at poczta.onet.pl>:

Hi, sometimes it is needed to grab variable, but limited, number of options.
For example --point could accept 2, 3 or 4 values: (x,y) or (x,y,z) or
(x,y,z,w). Current version of argparse requires postprocessing:

	parser.add_argument('--point', action='append', default=[])
	nmps = parser.parse_args()
	if not (2 <= len(nmsp.point) <= 4):
		raise argparse.ArgumentTypeError("--point expects 2, 3 or 4 values")

I propose to allow pass range of options count to nargs, including
lower/upper bound. For example:
	
	parser.add_argument('--point', nargs=(2,4) )	# from 2 to 4
	parser.add_argument('--foo', nargs=(9, None) )	# at least 9
	parser.add_argument('--bar', nargs=(None, 7) )	# at most 7
	nmsp = parser.parse_args()

I've attached tests and patch made against Python3.2 lib from Debian.

w.

----------
components: Library (Lib)
files: argparse-nargs.patch
keywords: patch
messages: 129714
nosy: wm
priority: normal
severity: normal
status: open
title: argparse: nargs could accept range of options count
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20947/argparse-nargs.patch

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

From report at bugs.python.org  Mon Feb 28 20:40:38 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 19:40:38 +0000
Subject: [New-bugs-announce] [issue11355] os.mkdir() and os.mkdirat() don't
	apply SUID/SGID	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

os.mkdir() and os.mkdirat() use libc's mkdir() and mkdirat(), which can ignore SUID/SGID permissions. This problem occurs at least on systems using glibc. The solution is to call chmod() / fchmodat() to ensure that given directory has been created with requested permissions. I'm attaching the patch.

----------
files: python-mkdir.patch
keywords: patch
messages: 129720
nosy: Arfrever
priority: normal
severity: normal
status: open
title: os.mkdir() and os.mkdirat() don't apply SUID/SGID permissions
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20950/python-mkdir.patch

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

From report at bugs.python.org  Mon Feb 28 23:30:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 22:30:45 +0000
Subject: [New-bugs-announce] [issue11356] Include module name on ImportError
In-Reply-To: <1298932245.21.0.726100579882.issue11356@psf.upfronthosting.co.za>
Message-ID: <1298932245.21.0.726100579882.issue11356@psf.upfronthosting.co.za>


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

Catching ImportError in order to switch to an alternate implementation can mask real failures in imported modules. Attaching the module name as an attribute would allow this to be handled correctly by doing something like:

try:
 import simplejson
except ImportError as err:
 if err.module_name != 'simplejson':
   raise
 <backup plan>

See http://mail.python.org/pipermail/python-ideas/2011-February/009209.html

----------
components: Interpreter Core
messages: 129729
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Include module name on ImportError
type: feature request
versions: Python 3.3

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